Joined-up thinking

How do you execute a successful bimodal programme? Jon Sheffield explains.

Gartner defines ‘bimodal’ as “the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration”. We have been supporting this thinking by reviewing its application across our global client base and a number of complex transformational programmes.

When managing a programme, in practical terms, ‘bimodal’ means some components are executed using agile techniques, and others using more ‘traditional’ methods. We prefer the term ‘scheduled’, as ‘traditional’ often carries a negative connotation. Similarly, we make the distinction between ‘agile’ meaning the use of a recognised, agile set of techniques, and ‘agile’ implying simply agility and speed. The two are by no means the same.

So, how do you successfully execute a bimodal programme?

Our experience with clients has established a number of fundamental principles that drive success.

1. One size does not fit all

Example: The Scrum coaches on a client’s major programme wanted to take four days to train the entire programme team of 160 people on Scrum techniques. Two-thirds were working on components that were only ever going to be executed using scheduled techniques, and the other third – the developers – already knew Scrum. It’s not that the Scrum techniques weren’t valuable – they weren’t appropriate for the majority of the programme, and would have been counterproductive.

There’s a lot of justifiable enthusiasm about the benefits of agile development. But a method is a means to an end: securing the optimum outcome possible. So, treat each component of the programme appropriately, because you want to maximise the effectiveness of each style of working.

A programme’s project management office (PMO) has a new and valuable role to play in this. A team brought together on a bimodal programme will have different levels of understanding of agile, but the PMO must be well versed in all the methods needed for the programme. This allows it to facilitate the process of integrating styles of working, holding together and lubricating the operation of the programme.

2. Keep the main thing the main thing

Any programme – bimodal or not – is constituted to achieve a specific result for the sponsoring organisation. The agile components of a bimodal programme must figure out how to help the programme towards that objective.

Agile handles uncertainty in requirements and solution delivery well, and there are potentially large advantages in that, but the chief financial officer and other executives of an organisation will certainly want to understand:

what it will get,
when it will get it,
how much it will cost,
what the benefits are, and
whether it is more worthwhile to do this than something else.

Answering these questions for the agile components of a bimodal programme is always a challenge. After all, it involves defining the requirements and the solution in detail, and that’s not agile. In addition, organisations vary in the extent to which they need precise answers to these questions.

A bimodal programme must be equipped to provide the right level of detail and precision to match the organisation’s risk appetite.

Example: A non-departmental public body client working in a highly regulated environment had an established and detailed programme management framework based on ‘traditional’ programme and project methods. They wanted to understand how they could secure the benefits of agile and what it would mean for their framework.

Matching bimodal execution to the risk appetite of the organisation will almost always involve some degree of compromise.

A roadmap approach that charts the programme’s route towards the overall objectives and goals works best. This lays out what the programme anticipates will be delivered when, and how those things relate to the programme’s value. This isn’t a traditional integrated programme schedule – it can’t be with agile components.

Programme increments of eight to 12 weeks’ duration provide breakpoints within which the programme’s different working styles can be synchronised, and a cadence on which to review the programme and shape the objectives for the next increment (and the one after next in outline).

Agile development teams may struggle with the concept of committing to deliver to programme increment boundaries – it is a compromise on ‘pure agile’ (whatever that is) – but it will meet the needs of the sponsoring organisation.

Executives accountable for programmes are more likely to accept the perceived increase in risk in less detailed answers to their five key questions. Increments provide a mechanism for agreeing funding on the basis of demonstrated results, and that can go a long way to satisfying chief financial officers.

The PMO has a key role to play in devising the programme’s integrated delivery roadmap, and the skills required are complex. Harmonising working styles and their approaches to planning requires knowledge of scheduling and agile, and the ability to shape the programme’s structure. The PMO’s role involves more effective soft skills than those required on a traditional programme. This also means more rewarding roles for those within the PMO.

3. Language, culture and change

It is hard to overemphasise the importance of language on bimodal programmes. Different agile methods use very different language or, more problematically, the same words for different things. One person’s ‘sprint’ is another person’s ‘increment’ or ‘iteration’.

A further level of confusion occurs when agile methods use similar or the same terms as established scheduled or traditional techniques. Throw in in-house methods or software development life cycle terminology, and more confusion is possible.

Behind the language are the mindsets that created the language. A bimodal programme involves multiple communities with their own world views, and, because those communities consist of people, they come with assumptions and prejudices.

Diehard project managers can display intolerance towards agile’s approach to requirements and solution definition. Similarly, proponents of agile can be equally distrustful of the value of scheduled ways of working. Both communities can be – and, in our experience, often are – highly protective of their own world views.

Example: A client executed the early stages of a programme very effectively up to the point when the development teams were mobilised on the agile components. Not understanding the cultural shift on the programme that was about to occur, the client failed to establish clear rules of engagement before the teams arrived.

Our advice would always be to determine the programme’s ways of working as primary. This enables incoming agile or traditionally minded resources to adjust to ‘the way we do things around here’, which is often quoted as a definition of culture.

We would also advise recognising that the amount of change management needed on a bimodal programme is significantly greater than that typically required on a traditional programme.
Creating an effective programme team is always, and has always been, a challenge. We would say the risk associated with that is greater on bimodal programmes, and it is important to mitigate that risk.

Conclusion

In recent years, the various agile methods have taken great steps towards becoming normalised in IT development, and that means most programmes in the future are likely to be bimodal in nature. Learning what makes bimodal programmes successful can be a very painful process of trial and error, leading some organisations to abandon the potential benefits agile can bring.

We believe applying the right principles, the first three of which we have shared above, from day one can drive success – but what successful execution of bimodal means for every organisation is slightly different.

John Sheffield is chief operating officer at Pcubed.