Consider these four statements about software development requirements:
- You can discover all the requirements upfront.
- You can minimize requirements changes early in the development cycle.
- Once you select a set of requirements you can precisely estimate the effort to deliver them.
- The fact that a requirement has been defined is an indication that the requirement will be delivered.
Are these statements true or false?
How you answer that might be a good indication of the project management methods best suited for your project.
If you think that these four statements of mostly true, then a traditional, step-wise, plan-driven (read "waterfall") method is likely appropriate and has as much chance of succeeding as anything else. On the other hand, if you think these statements are mostly false, then that same plan-driven approach is likely to be problematic. Instead a more agile approach that re-evaluates requirements at iteration boundaries has a much better chance of success.
An agile approach embraces the notion that we don't know everything upfront. Changes in requirements are not only expected, they are often seen as a good thing. They keep us on a path that is delivering value. Developing software should not be about delivering some fixed set of features by the desired date. Developing software should be about making the business bigger, better or more efficient. It's alright that we don't know all the details about just how to do that upfront. Agile methods let us start with something we know and build on to that based on what we learn along the way. Frequent feedback validates the work we have done, identifies changes that could make that work better, and discovers new ideas that couldn't be seen before. Managing this level uncertainty and change is uncomfortable to traditionally trained project managers, but doing so provides our best chance for success.
Successful businesses are not static; they constantly evolve as they adjust to changes in their market, the activities of their competitors, fluctuations in the economy and many, many other things. We should not think that we have a static playing field when developing software in these business environments.
| Comments |
|