Waterfall with sprints

Craig Larman, co-author of the LeSS (Large Scale Scrum) framework and
leading figure in the agile space, has formulated five Laws of Organisational Behaviour.

In his first law, Larman says that “organisations are implicitly optimised to preserve the status quo for specialists and mid-level managers”. The agile adoption is the perfect territory in which we have observed instances of such behaviour, when organisations try to move away from traditional Waterfall structures towards agile ways of working, typically via Scrum or Kanban.

Restructuring

One of the first changes made by such organisations is the restructuring of their development functions into cross-functional teams; Developers and QA Engineers together with Product Owners will form teams that are capable of delivering potentially shippable increments of working software to customers, from idea to production. This will, in turn, enable a faster feedback cycle which will help us learn what customers need and measure the right things.

Unsurprisingly, in an organisation whose structure was once optimised to deliver projects in a Waterfall fashion, we will find job roles that match the different project phases prescribed by Waterfall: requirement gathering and system design is carried out by Business Analysts, Architects and Designers who will produce specification documents to be handed over to engineering teams for implementation.

Do we move Business Analystss, Architects and Designers to cross-functional teams?

The short answer is: yes, we should. Because agile works with increments and iterations and therefore what requirements and what design we’ll have in the future depends on what we’ve learned about our current product increment.

However, what the first Larman’s law of organisational behaviour is trying to warn us about is that in practice, specialists and mid-level managers will resist this change.

Why is change resisted?

Let’s focus on the architects for a moment. For architects to work as part of cross-functional teams, they will need to let architecture emerge iteration after iteration. It’s a radical mindset shift. In a traditional Waterfall setting, Architects produce architectural design documents outlining what the architecture of the “finished product” looks like as soon as the requirements are finalised. Now, in the new world, we’re trying to tell them that there is no final product, because the scope is variable by definition and will be evolving iteration after iteration. Whether we like it or not, this is likely to break all the sign-off and approval processes that are currently installed in the organisation.

There is another aspect to consider. Organisations simply don’t have enough Architects and Designers to allow them to work as part of cross-functional teams. They would have to be shared across multiple projects anyway, which is an argument in favour of them keeping the current structure, one where Architects and Designers — still shared on multiple projects — will feed cross-functional teams with requirements and architectural documents. Until these artifacts are available, these cross-functional teams won’t be able to start iterating.

Here’s the paradox: in this setting, cross-functional teams have no power in deciding what they do. Their accountability goes as far as delivering the solution that has been given to them, sprint after sprint. As a side effect, if a Product Owner is allocated to such team, he/she will end up acting as a Delivery Manager whose responsibility is to ensure the team is being “productive”, rather than focusing on the product, the market and the customer.

In essence, these organisations work with increments but without iterating, in a fixed scope fixed time fashion; in other words, Waterfall with sprints. And whether they can produce a potentially shippable product increment (PI) in all their sprints no longer matters, because they are not really using the feedback cycle to decide on the next move.

Instead, they start with the final solution already in mind, build it one piece at a time and then assemble the whole thing at the end when they’re ready to release to a customer.

Despite doing daily stand-ups, sprint planning, demos and retrospectives, these teams are still practicing Waterfall, and if we look at the value, risk and adaptability curves we get when we work like this, they look exactly like what we’d expect in a Waterfall project:

If development teams who have developed the ability to iterate and maximise learning are not empowered enough to work on the entire development life cycle, we are giving up the primary reasons for doing agile in the first place:

• deliver value to customers early and continuously, and
• reduce the risk of building the wrong product

Everyone who is involved in shaping a product — including the specialists and the mid-level managers — ought to be part of cross-functional teams to iterate effectively, otherwise the organisation will be optimised for following plans rather than for responding to change.