Uncovering Better Ways of Developing Software by doing it and Helping Others do it
In the Agile Manifesto it says, “We are uncovering better ways of developing software by doing it and helping others do it.” I have been paying attention to the conversations between the BUFD traditionalists, the Agilists, and now the Kanban communities. This conversation has not always been friendly – and some members of each community certainly aren’t looking to learn about better ways of developing software. In fact, the contentious debates are creating obstacles to helping others do it.
I find that there are valuable capabilities in each of the practice areas. Agile was never completely different than BUFD. It was 20-30% different. And that difference, when done well in the right context, dramatically improved the value of the software being developed and the velocity that it was delivered. Kanban is probably 10-20% different than Scrum, the most prominent instance of Agile. XP doesn’t really come into the discussion because XP practices will be applied in both of the situation. In the right context, Kanban will deliver dramatically improved value and velocity over explicit Scrum. After all, some companies have moved to single-unit engineer-to-order flow over small batches and realized dramatic improvements.
As I have been wrapping my brain around the distinctions and benefits, I keep coming back to Gerald Nadler’s book from the mid 1990’s, Breakthrough Thinking: The Seven Principles of Creative Problem Solving. Nadler had developed a meta-model for problem solving (solution finding) that has consistently delivered dramatic results. I am going to share the seven principles with you and then use them to talk about why I think the principles in Kanban can deliver results that are better than teams doing Scrum.
1. Uniqueness: Every problem is unique. You can’t directly copy a solution from elsewhere. Only if the context of the purposes shows it is useful should some available solution be considered.
2. Purposes: Always and continually ask the purpose. Then ask the purpose of that purpose. Expand as far as possible with this exercise. Focusing on purpose lets the uniqueness of the situation become clear and strips away nonessential aspects of the problem context.
3. Solution-after-next: Find solutions today that achieve the focus purpose, based on what might be the solution of the future. Having a target solution I the future gives direction to near-term solutions and infuses them with larger purposes.
4. Systems: Employ a format that includes all elements and interrelationships that the target solution will entail. Every solution or system is part of a larger system, and solving one problem inevitably leads to another. Understanding the elements and dimensions that comprise a solution lets you determine in advance the complexities you must incorporate into the implementation of the solution.
5. Limited Information Collection: Before taking the time and wasting the effort to collect and analyze extensive data, determine what purposes would be achieved by gathering the data. Study the solution, not the problem.
6. People Design: Throughout the process of finding a solution, give everyone who will be affected by that solution the opportunity to take part in its development. People are willing to explore purposes and solutions-after-next, rather than to gather data about what is wrong with the current system. Those who carry out and use the solution should be intimately and continuously involved in its development. Also, the proposed solution should include only the critical details, in order to allow flexibility for those who must apply the solution.
7. Betterment Timeline: Even as you design today’s solution, schedule future changes necessary to its continuous success. The only way to preserve the vitality of a solution is to build in and then monitor a program of continual change. A sequence of purpose-directed solutions and knowledge of the solution-after-next are bridges to a better future.
Scrum explicitly calls out several of these principles, particularly uniqueness, purposes, and people design. It provides direction that you should be looking for a way to remove impediments. It doesn’t explicitly provide guidance for doing that and a good, experienced manager is already applying many of the other principles. As I was telling Mike Cottmeyer this morning, a Scrum team in the right context will (and have) evolve into (many of) the Kanban practices.
Kanban explicitly calls out the rest of these principles. The Kanban itself becomes a framework for understanding the System and focusing on just enough information. The operations review is specifically in place to establish a betterment timeline and the solution after next.
Most of the Scrum teams dislike management and the other functional groups they interface with. The concept of pigs and chickens and the common perception that management causes obstacles for the team lead to conflict and distrust. Kanban focuses on how the development team can work better across the organization. From a purposes focus and people design standpoint, the Kanban perspective leads to greater trust and a shared focus on the solution-after-next.
Finally, many Scrum teams struggle with how to schedule defects and rework into their iterations. In the iteration world, QA gets the release after the end of the iteration for acceptance testing – this creates delay in feedback. This delay leads to all the relearning problems that we all have discussing. The enforced reduction in work in process and the single-unit flow reduces rework and shortens the time to feedback on defects and acceptance issues.
According to most reports, we still aren’t great a reliably delivering technology. No one has an answer yet that works for everyone. There is a lot of room for improvement and I believe we need to keep an open mind as we uncover better ways of developing software by doing it and helping others do it.
Great post Dennis. Our conversation this weekend inspired me to put a few thoughts down on this subject:
http://www.leadingagile.com/2009/07/scrum-or-kanban-its-not-black-or-white.html
I think we can both agree that a well run agile team is already doing much of what you are talking about here. If a Kanban helps the team get better… and give managers something to do… I am all for it
Mike
Both of these methods make problems more visable. Kanban makes the problems visable sooner leading to faster learning and less rework. These qualities are hard to argue against.
If Aglie is working just fine, then the team can challenge itself to get better. Try reducing the batch size (iteration) by half. This will cause problems. It is supposed to. Overcoming these exposed problems will help the team get better.
[...] Uncovering Better Ways of Developing Software by doing it and Helping Others do it [...]
I do like the point of purposes and solution-for-the-future. I feel everyone take these into account and go in a better way rather than arguing against each other. This will make nothing else than they stagnate at their plans.