After over a dozen years of training and coaching in multiple Agile methods, we've seen how useful it is not to be attached to any one of them. Knowing a variety of methods helps you match the method to the need at hand. It also helps in its implementation. And it gives you the breadth of experience required to keep you from becoming dogmatic.
It is easy to forget that just because something has worked in one case it does not follow that it should always be used. Using the same approach again and again is like eating soup with a fork: even though you can, a spoon might be better! (thanks to Jaime Lopez Jr. for telling me this simile) Everyone says there is no silver bullet so, it is sad that so many consultants seem to advocate only one approach and so many soon-to-be practitioners only investigate one approach. All methods have places where they work best and if someone knows only one, it is very likely it will not be the best for their situation.
Of course, choosing software development methods isn't really like picking the right piece of silverware; that is a gross over-simplification of the different methods. They are not mere tools where you pick one and use it. There are attitudes and mindsets to be considered. For example, there is a great deal of disagreement in the Agile community on the following questions:
Do we start an Agile transition at the team level or with a holistic view?
Is it even correct to talk about a “transition” to Agile or do you just jump in and remove the impediments you experience?
Should you base your approach on practices or on principles? That is, do you start by just following a few practices, or is it better to learn some basics of why Agile works?
Does having explicit policies improve communication or make it difficult for the team to adjust their methods?
Is it possible to define your workflow?
The mindset that defines the answers to these questions will shape the course of your Agile adoption considerably, even more than the method you chose. One common mindset in the Agile community now is that you should start with the team, take a minimalist approach to what knowledge they start with, begin with a few prescribed practices, and have them figure the rest out. Then, spread Agile team by team. Another mindset, being lead with Lean-Thinking (and admittedly ours), suggests you consider the entire value stream to decide where to start. This may be at the team level, but may begin higher up. You select based on who the sponsor of the transition is as well as what is causing challenges to the delivery of business value. You also consider whether teams should just jump in or transition to Agile methods using continuous improvement methods.
If you can form a co-located, self-organizing, cross-functional team, you will likely get a 2-3 times improvement regardless of which method they use. The question is how far throughout the organization will this be possible? And, there are also dangers in how this was achieved (see How Successful Pilots Often Actually Hurt an Organization).
Our experience is that there are many factors in deciding how to improve you development process. These include project selection methods, corporate structure and culture. It requires taking a holistic view. It is unfortunate that these are not always considered in all methods. Some methods are team-centric, others more holistic. It's important to know more than one.
It is for this reason we developed a course that combines the best of Scrum, Kanban and XP. We call it the Lean-Agile Project Manager. Participants learn how to effectively implement Lean practices, Scrum, Enterprise Scrum, Kanban, and hybrids driven by lean thinking 1. The course epitomizes the elimination of the silver bullet approach. It focuses on teaching people how to apply the latest methods to fit their situation.
The bottom line is that software development is a complex undertaking. Improving it is even more complex. We believe one should take advantage of what has been learned from several methods.
BTW: If you are interested in the Lean-Agile PM course mentioned, it is currently scheduled around the US at about 1/2 price - we feel so strongly that people need to take advantage of the bigger picture approach it provides. See the full list of offerings. And, of course, we're always happy to present this class on-site.
Bottom-Up? Top-Down? Optimize the Whole? – The Importance of Perspective April 3, 2011
The Importance of Mindset July 26, 2011
A Massive Transformation Begins With a Small Change February 9, 2011
The Case Against Minimalism November 5, 2010
1 We called it this because Scrum Master is a method-centric term. We also think that although self-organizing teams is critical, most projects require more than one team. We have found that self-organization across teams doesn’t always work well and that someone needs to consider this bigger picture. Of course, we don’t mean micro-management.