Scrum, Extreme Programming, and Kanban are Agile’s Big Three, but which is better?
All have been demonstrated to work, yet all can fail.
The reality is that all of the challenges of today aren’t going to be solved by any one approach. There is no single, silver bullet that is going to work for everyone, everywhere, in every situation.
Failures will occur, despite the fact that the foundation of Agile is strong, built upon the knowledge and experience of others: Joint Application Development, Complexity Theory, Lean production, and many years of hard experience in the field of software development, to name a few. The approaches of Scrum, Extreme Programming, and Kanban reflect tremendous insight and each provide a solid framework to work from.
Early adoptions of Agile have proven to be successful, but there have been Agile project failures. There are too many variables in play – existing skill sets and knowledge, the amount of time and budget available for training, management support, the willingness of the workers to accept working in new ways, etc. – that influence success.
Call me crazy, but…
Agile should be MAD: Mixed Agile Development. (OK, it’s a hokey acronym…) I don’t believe that any organization should limit itself to one framework, nor do I believe that Agile coaches should limit their understanding – or coaching – to a single framework. And the frameworks themselves need to avoid becoming rigid.
For example, Kanban’s process orientation is great, but maybe Kanban could use a Product Owner in certain situations. Scrum provides a solid framework for team mechanics, but maybe Scrum teams could incorporate technical practices from XP. Conversely, XP’s technical practices are great, but maybe XP could use a little of Scrum’s framework to work out team logistics.
It’s all about continuing to be open-minded and sharing knowledge, of understanding the circumstances in which a particular framework or technique works and not wasting energy by force-fitting an approach. I can see where Kanban would fit perfectly well for an IT support group and a Scrum/XP hybrid would work wonders for a development group – all in the same company.
Experts can be a double-edged sword. On the plus side, experts have the specialized knowledge and skills to work with a specific framework that others lack. Less experienced practitioners can fail where an expert would prevail. That's why it helps to have an experienced, knowledgeable coach available to guide you. A good coach can help you overcome obstacles, and a great coach will teach you how to overcome them for yourself in the future.
However, even experts can be myopic, focusing on one framework because they have developed a deep understanding of that framework. That is why I made the point that energy can be wasted by force-fitting solutions. Assess the situation objectively, and consider if you using the right tool (framework) for the job and circumstances. What obstacles are you hitting? Are there other techniques that could be used? Is the real problem your execution or a poor framework fit? If you believe it is a poor framework fit, why is the fit poor? Keep asking yourself why, and don't settle for the easy answer.
Conditions will change over time. This is another reason why we all need to continually expand our knowledge and try new things, and not to codify Agile development. It should be treated as a body of knowledge that is continually growing, and each Agile implementation should be tailored and adapted over time to meet the unique and changing needs of each organization.
There is a problem in all of this: People are constrained in their ability to absorb new information and apply it effectively. The key is to start people using one framework – the one best suited to the needs of that particular organization and team – to provide focus and a structure to work from, but pointing out that other frameworks and techniques exist.
Another reason for using an established framework is that early adoption requires guidance, and there is no sense in turning an Agile adoption into a grab-bag. Mixing and matching ingredients without truly understanding how and why they work won't lead to anything that tastes good. Use the framework that is the best fit, leveraging the knowledge and skills available that have been built around that framework. But don’t be afraid to share knowledge, borrowing from other frameworks or even using more than one framework in your organization. Mix it up! Just do so in an informed and responsible manner.