Beyond Agile -- Inspect and Adapt? How?

Incremental and iterative development process frameworks provide frequent opportunities for teams to "Inspect and Adapt". What should we inspect? How should we adapt? Is this part of the framework? Teams using incremental and iterative processes have daily stand up meetings that provide an opportunity to observe how things are going, and they can set up a quick meeting to remove obstacles and improve things. At the end of every iteration, there is an opportunity to review the whole iteration and decide how to make things better. Most experts, and most named iterative methods, explicitly call for a retrospective, at the end of each iteration if not more frequently. Some people -- and at least one named method -- argue that if we iterate, reflect, inspect, and adapt, we can and will become a high-performance team. This is true, to an extent: if we observe the right things and make the right choices, then of course we can improve as much as we want. Unfortunately, we were not born knowing the right things to observe, much less the right things to do about what we see. If we get it wrong, good things will be missed.

Alpha Team has been building features for quite some time now. When they hand things off to QA, they rarely come back, and when they do come back, Alpha looks at what they’ve done, and devises ways to avoid that kind of return from QA. Alpha has beefed up its testing ability substantially, and they use pair programming and code reviews to great benefit. Still, things seem sluggish. Even with no bugs coming back from QA at all, it still takes a week or two to be sure that features are done. This seems wrong, but they don’t see what to do.

Alpha Team, for some reason, has not thought of some valuable ways of restructuring the team, and their work, to help them get things done more quickly. The most effective teams move the QA function before development to the greatest extent possible. The testers are part of the team, not in some separate group. They provide tests before the iteration even starts, and the team considers anything “done” that passes all those tests. When something passes all the tests but does not seem “done”, the whole team considers, not who screwed up, but what tests were not thought of, and how to improve their thinking for next time. The result is much more certainty of where the team stands, and much less stress all around. Where is a team supposed to get ideas like this? If we wait for each team to think of things, some of them may never do so. If we set up a standard way of doing things, we’ll be cheating ourselves of learning, and we’ll wind up making process followers of our people rather than intelligent creative workers. What’s most important is that team members need to improve their skills. The organization can help with this by providing training, by subsidizing books, or by other means. We believe that the best approach is for the organization to encourage retrospectives, draw proposals from the team, try them, and watch what happens. When ideas come in from outside, make a point of noting what book or web site was read or what course was taken. In short, show respect for people’s efforts to improve themselves.

Sources of Good Ideas

For internal technical practices, we suggest looking at the practices of Extreme Programming. In particular, automated testing, both Test-Driven Development and Acceptance Test-Driven Development are very valuable, as we discuss elsewhere. For in-team workflow practices, look to Kanban and other approaches to limiting “Work in Progress”. These ideas highlight bottlenecks and delays inside the development team. It’s important to look at the larger flow as well. Nothing good will happen if we get development time down to zero in an organization that takes six months to get an idea off the ground and another six months to deploy it. Here we would recommend ideas from Lean, such as Value Stream Analysis. For internal technical practices, we suggest looking at the practices of Extreme Programming. In particular, automated testing, both Test-Driven Development and Acceptance Test-Driven Development are very valuable, as we discuss elsewhere. For in-team workflow practices, look to Kanban and other approaches to limiting “Work in Progress”. These ideas highlight bottlenecks and delays inside the development team. It’s important to look at the larger flow as well. Nothing good will happen if we get development time down to zero in an organization that takes six months to get an idea off the ground and another six months to deploy it. Here we would recommend ideas from Lean, such as Value Stream Analysis.

Is Our Process Framework Complete? Is It Sufficient?

If your process framework includes taking in features at the beginning of an iteration, delivering them complete at the end, and reflecting on and improving what you do, it is probably complete. In principle, that's enough to make a good framework. It's far from sufficient as a process, however. There are many practices, many ideas, many things that we have to do in order to improve. Those things are necessary and they should come from the team and its explorations. No process framework can list everything we need to do. No framework should try.