Waterfall Development Is Prescriptive; Agile Development Is Adaptive

The single biggest mistake companies make when adopting an agile development approach like Scrum, Kanban, XP or Lean, is establishing too many rules. This tendency results from their prescriptive cultures. They like to define lots of rules and want to make agile development fit in. It won’t.

A prescriptive culture is one where there are lots of rules and procedures. People are trained to perform their jobs in precise ways. Workflows are governed by phases and gates. Policy police in the form of a project management office (PMO) or a compliance committee exist to make sure everyone follows the rules.

Waterfall development fits nicely into prescriptive cultures. In waterfall, development activities occur in a prescribed order and are accompanied by designated approvals. It just fits.

In such environments, change happens slowly and deliberately (if it happens at all). Proposed changes require extensive reviews and multiple approvals. Documentation has to be revised and published. Rollout plans have to be created. Training has to be delivered.

And then along comes agile development.

Everyone is curious about the latest software development trend — agile development. Everyone has to give it a try — at least once.

People in prescriptive cultures immediately go in search of the “agile rules”. How is agile development done? How is it controlled? Where is the process documented? How are approvals handled? What does an agile gantt chart look like?

They soon discover that rules are few, controls are minimal, documentation is sparse, approvals are simple, and gantt charts are non-existent. They conclude that agile development cannot work for them as is. They will need to improve it — by adding the missing rules.

So they embark on a mission to improve agile development. The end result is likely to be some variation of iterative waterfall with a new agile label slapped on — “Company X Agile Methodology”.

Okay, enough.

Agile development is not prescriptive. Scrum is not prescriptive. Kanban isn’t either. Neither are XP or Lean. If you try to make any of these approaches prescriptive, you have re-defined waterfall development. You have not adopted agile development.

To be agile, software development teams need freedom to adapt and change between and during sprints or iterations. Let the teams define the rules as they go, not in advance. Give the end users a loud voice in determining how the process works. Learn as you go. Continuously improve. Adapt.

If you must have policy police, have the development teams (including the end users) drive them, not the other way around. That’s agile!