Changing Software Development: Learning to Become Agile

11.2. Planning

When we talk about planning in a software development project, we usually consider it as an exercise in scheduling. Yet there are many other plans that we make on a software project. Software design is both an activity – a verb – and an abstract thing – a noun. We create software designs through the process of software design.

As an activity, design is a form of planning. The result of design activity might be something formal, such as a set of UML diagrams, or it might be something less tangible, such as a set of mental models^[] shared by the development team. Used in this way, the design process is an exercise in creating future memories of what the software will look like.

^[] See Holt (2001).

Even in the earliest stages of a software project, we're planning, creating plans and building mental models. From the moment we conceive of a software product, through requirements, specification, design and even into coding, we're planning, creating plans and refining the plans that we've made. Successive refinements change requirements into designs and into code.

However, planning isn't without problems. It's far from a benign activity: creating plans can create unintentional problems; and once made, plans can be used to force behaviour on a team. Sometimes we're better off not planning.

Unpopular Estimates Between developers, stories abound of planners refusing to accept unwelcome estimates. Unfortunately, a number of poor practices have grown up around estimates: