Software Teamwork: Flexibility and Rigor
This chapter is from the book
This chapter is from the book
This chapter is from the book
Guidance over Prescription
A consensus seems to exist among many companies that the way to ensure the success of software projects is to prescribe how everyone will do his or her job.
Policies and procedures. Audits and documentation. An excessively detailed schedule. If the project failed last time around, it’s an indication that we either need more of this stuff, or that we didn’t follow the rules closely enough.
Although this might work for assembly lines that produce widgets, few software development projects will benefit from such a rigid structure. It’s great to have an understanding of how to do the work, but that understanding needs to transcend what is usually found in plans and procedures. The team needs to reach a point at which it is commonly understood why the work needs to be done in a certain way, and how to determine the best approach for attacking the work. What is needed is guidance, not prescription.
Most software projects are characterized by the ongoing discovery of information that takes place throughout the project life cycle. More details about the product or the environment give us better insights into how to best approach or change the remaining work, or to even change or stop the project altogether. A prescribed approach for the entire project rarely works well. We simply can’t accurately predict the pitfalls we will have to overcome on our journey. As the situation evolves, we either find that we need to rethink our "best laid plans," or worse, we try to follow these original plans to everyone’s detriment.
To be effective, we need to focus on guiding principles for getting the job done and an overall vision of what the product is all about. These rarely change. We can establish them early and ensure that everyone completely understands them completely. We now have in place a basis upon which we can make decisions with our newfound information as the pro ject unfolds. Are we still in alignment with our overall project goals? Are we true to our principles for how we develop software here?
Once we have the guidance, we need to be comfortable with disciplined flexibility to get the job done effectively. We need to be able to react to information quickly. We should recognize that early discovery of information that is counter to our goals is good news, for now we can correct our course and advance. Communication is critical for the whole team, and the team extends beyond the developers to include the customers and other key stakeholders.
Policies and procedures do have their place. There are often regulatory issues to deal with. As the team grows, there does need to be some degree of consistency and common understanding, as well as a basis for learning just how the job gets done. It is important to remember, however, that most regulatory bodies merely expect you to be able to demonstrate that you do what you say you will do, not that you will do everything.
Their intent is not to slow you down, but to make you more reliable. If you go down the route of defining process documentation, ensure that it is just enough to support effective development. Too much will just bog you down.