Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Opinion: Agile Adoption is Distinct from Agile Practices
Posted by Amr Elssamadisy on Feb 19, 2008
Using Agile practices effectively is not as easy as knowing what Agile practices are. To use test driven development effectively is different than knowing that you should follow the red-green-refactor loop. How does one get from: Agile seems like a good idea, to: We have used Agile practices to significantly improve the value we deliver to our organization?
Success stories abound in the literature of Agile, but so do failures - there is no silver bullet. So whether you can follow another team's example is based on context - is your context the same? If not, then you probably won't get the same benefits.
To start things off, Carel Lotz reports his organization's difficulties in getting real value from adopting Scrum:
I'm currently part of a team that needs to re-define our company's SDLC methodology. I'm all for using a more agile SDLC (Scrum, Open UP etc.) as the current SDLC methodology is based on a Waterfall model of software development. In the past 2 years, a few projects have attempted to use a more Agile SDLC, but they either failed miserably in their attempt or only succeeded in implementing some of the technical aspects of agile development like Continuous Integration (CI) and Test Driven Development (TDD).
What is really interesting, is his analysis (hindsight is 20/20) on why these failures probably occurred:
I read an interesting article on InfoQ this morning that highlights one of the primary reasons why the transitioning to Agile has not yet been successful in our environment. [this is a reference to last week's personal agility article on InfoQ]
We currently don't have enough of these key individuals who actually understand and have adopted the correct agile mindset (i.e. not Scrummerfall). The result - without enough correct guidance and a strong believe in the benefits of agile development, a team quickly becomes disillusioned and reverts to the "known" waters of a Waterfall approach.
Over the next several months I will report exclusively on issues of Agile adoption. The promised benefits are great, and the pitfalls are plentiful - tune in to InfoQ's Agile Queue on Tuesday for a weekly update on how people are adopting and adapting Agile practices!
If you think the focus on adoption has merit, then please let us know what you think here and send us emails about your thoughts, interesting blogs, and useful news that pertains to this topic.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Agile Maturity Model Applied to Building and Releasing Software
Improving Software Delivery Cycles: Pre-requisites and Inhibitors
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Re: Agile Adoption
by
Dave Rooney
Posted
Re: Agile Adoption
by
Amr Elssamadisy
Posted
Agile Adoption is Distinct from Agile ENGINEERING Practices
by
Deborah Hartmann
Posted
Re: Agile Adoption is Distinct from Agile ENGINEERING Practices
by
Amr Elssamadisy
Posted
Re: Agile Adoption is Distinct from Agile ENGINEERING Practices
by
Deborah Hartmann
Posted
-
Has anyone ever written about how virtually all organizations that have attempted to adopt the 'waterfall' model have failed to do so properly (at least according to how Royce defined it)?
How about the multitude of failures of implementing the RUP? RAD? (Insert acronym or buzzword here)?
Perhaps the focus shouldn't be on failures of adopting Agile, but rather failure of adopting any process. If an organization has been struggling in their software development efforts using other processes, why would anyone think that they would be successful at adopting a method that requires more discipline, interaction and transparency?
Dave Rooney
Mayford Technologies -
Perhaps the focus shouldn't be on failures of adopting Agile, but rather failure of adopting any process.
I believe that you mistook my intention Dave. I will be focusing on all of Agile adoption - both successes and failures. It just happens that my first example was a negative one. I'll try for a positive story next time :)
Now, if it turns out that Agile has nothing to do with success and failure of change - that would be very noteworthy.
Amr Elssamadisy
Gemba Systems -
I do think that the discipline of Agile Adoption Practices is emerging. It's just different than the better-established Agile Engineering Practices.
Imo, Agile Adoption Practices includes things like: retrospectives to set the stage for change, coaching and mentoring to help with the stress of change, and transparent dissemination of development metrics (rolled up to a meaningful level) to build communication with the organization. -
I respectfully disagree....
Adopting Retrospectives, Iterations, Demos and getting value from them is distinct from what a Retrospective is.
For example, we can read "Agile Retrospectives" and know the toolset that can be used to perform a retrospective.
But what about actually practicing it and getting real value from a retrospective? How do you know you are getting it right? What does it look like when a retrospective goes wrong? When are you just 'going through the motions'?
These set of questions are valid for all practices - technical and people practices. -
Ah, we are talking apples and oranges, perhaps.
I am thinking of a retrospective run by (whoever is leading adoption), and run well, at the beginning of an adoption effort. It serves to help the broader team understand "where are we now" and "where do we want to go," to provide perspective and motivation to (hopefully) "pull" change from the team, rather than "pushing" it on them.
Retrospectives for iterations are of smaller granularity and I'd agree they are a team practice. But what I'm talking about is a change-agent practice directly related to making an adoption successful.
5 comments
Watch Thread Reply