The greater the uncertainty and dynamics of a market in which the organization operates, the more the business and IT crave flexibility and experimentation. And in situations that call for flexibility, it is difficult to formulate and capture all the specifications in advance – which is a requirement of the traditional waterfall method.
As such, the standard Agile/Scrum methodology is ideal for creating proofs of concept and determining the expected speed of a large development project. In the latter case, multiple short development periods, called 'sprints', are used to develop functionality of varying complexity, giving the project team a fairly accurate indication of the flow speed of the overall project.
The Agile approach offers even more advantages:
- focusing on the specific challenge of the (internal or external) customer or client
- fast deliveries (for example, by developing the most valuable functionality first)
- prevent waste (for a proof of concept, a detailed needs analysis can be omitted)
- short cycle learning (e.g. customer feedback after each sprint demo),
- the flexibility to make decisions late in the process (e.g. backlog prioritization along the way),
- empowering the team (e.g. encouraging rather than prescribing),
- built-in integrity (e.g. soft controls, authority based on expertise rather than hierarchy)
All good things, which is why the Agile methodology sells itself so easily all the way to the boardroom. One of the consequences was that overnight, all project managers had to get out or be retrained as Scrum Masters. It also led to backlogs (the planned work stock) permanently overflowing, having to redo unnecessary things, and lazy business and IT organizations. How so?
Agile can lead to laziness
In the first week of development, the business wants a proverbial green car, after three sprints it prefers a blue one and after sprint eight red seems to be the best choice. Ask an outsider a critical question about this and you will be told by the team that this kind of ‘flexibility’ is the power of Agile.
The scrum team itself, especially if it consists of hired outsiders, will not easily ask critical questions about this. They continue programming, testing, refining the backlog and obediently executing what the product owner asks on behalf of the business. The obvious reason: hourly billing.
Because the implicit assumption in Agile is that there is always another sprint, it is not only important to be critical of the functional items on the backlog. The same assumption can also lead to a lazy attitude of the team towards the delivered work. Not asking critical questions during the refinement sessions and a lot of programming errors lead to backlogs that are largely filled with rework, the modification or rebuilding of software components.