As we start to understand the things we need to do to get our projects
out the door, we can split these tasks into two camps: the things that must be
done under any circumstances, and the things where we have some latitude on
their implementation.
This chapter covers a few guidelines that we can use to ensure that our
approach is visible, reasonable to follow, and supports the need to effectively
and efficiently get our job done.

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.

NOTE

The strongest process is not just a set of procedures that suggests that all
the industry’s "best practices" will be slavishly applied.
Instead, it is one that allows the team to adapt to the situation in a
disciplined manner.

Its emphasis is on collaboration and sharing information to facilitate a
shared success. The few absolutes are the guiding approach for development
quality and the information required to ensure that the vision and scope of the
project are known and managed.

In the hands of a conscientious team, supportive guidance goes a lot further
than rigid prescription.