The balance between guiding and directing
As the workshop call for participation notes, right now we have two process cultures. There is an established, heavyweight culture, and an emerging lightweight process culture. Why do we have two cultures? Are they two different solutions to the same problem, or are they solutions to two different perceived problems? How does this impact the introduction of lightweight processes, particularly to environments that are already familiar with heavyweight processes?
One key, though apparently trivial, observation is that the two process cultures arrived at quite different times. Heavyweight processes have been with us for quite a while. They arrived when the "state of the art" was primitive. Most software developers arrived from other disciplines. There was a wide gap between what a programmer wanted to say and what the available languages and tools would let him say. For many technical problems there was only one appropriate solution, or perhaps no solution at all. The main process problem in this environment is making sure that there is a feasible solution and maximizing the chance that a project will find this solution. The penalties for poor choices are very high.
Lightweight processes have arrived in a different environment. Many software developers have received vocational training in college, or even in secondary school. Tools and languages (particularly object-oriented languages) are more expressive and have reduced the programming expression gap. Lots of technical problems are now amenable to a wide range of solutions, or have become non-issues. In this environment there are generally many feasible solutions to a technical problem. The penalties for poor choices are relatively low. The process problem has become trying to find the solution that will best serve the long-term interests of the sponsors, rather than just something that will work.
Heavyweight processes focus on the "one right way." The process is the arbiter of the way. In a heavyweight process, all a developer needs to know is the single sanctioned path. At each point, he only needs to have one technique available. The only significant choice was made by the people who chose the process. Lightweight processes focus on finding the best way for the moment, and the individual is the arbiter of the way. In a lightweight process a developer needs to choose from as many alternative paths as possible. He needs to be knowledgeable, confident and empowered.
So one significant challenge in crossing the process chasm is broadening the skill set of each developer, and encouraging him to make as many choices as possible for himself. Another is helping him acquire a sense of software aesthetics to help support his choices. This is part of the coaching role.
It’s clear from documented experiences on the Chrysler C3 project that experienced coaches who are familiar with their team guide through questioning. Rather than tell someone the solution to a problem, they lead him to the solution through a directed dialogue that exposes that exposes the available choices and encourages the developer to consider the tradeoffs himself. Being able to do this effectively distinguishes the excellent coach. It’s the software-development embodiment of the "give a man a fish…" adage. In the early stages of a project, this can be a very time-consuming process. If the coach and developer don’t have a reasonable amount of shared experience, it can also be frustrating – to the developer because he keeps making "wrong" choices, and to the coach because while he is busy coaching one developer, others are working in much the way they did before. So in earlier phases of the project, the coach may need to be more directive – telling developers what to do in some circumstances, while guiding in others. This lets the project move at a reasonable pace without sacrificing quality. The risk is that the developers will become dependent on the coach for decision-making, losing their confidence and empowerment. Deciding when to guide and when to direct is an art, but it is fundamental to introducing lightweight processes into heavyweight environments.