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.
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.