Two Rhythms, One Programme
The Wema payments programme. Hardware and software had to move at different speeds, for entirely good reasons.
- Works across engineers and suppliers
- Commercially aware
- Hardware and software
- Systems thinking
- Where
- Wema Bank
- When
- 2021 to 2023
- My role
- Head of Service Innovation, programme owner
- Themes
- Hardware and softwareWaterfall and agileChange controlSuppliers
On budget
for a dual-rhythm hardware and software programme
-
01Situation
The physical devices needed their specifications locked months ahead for certification and manufacture. The app and the web platform ran in 2-week sprints. Each team had started to see the other as the enemy.
-
02The move
I set up fixed points, milestones where the interface between hardware and software was frozen. Software could change anything else, as fast as it liked. Changing the interface meant a change request with the hardware cost made visible to whoever asked for it.
-
03Result
The programme shipped on budget and roughly on time, and "two rhythms, one programme" became the mental model the whole team used.
Two timelines, meeting at the fixed points
Hardware in long blocks, software in 2-week beats, and the 4 places they were allowed to touch.
Hover a sprint to see what changed. Orange sprints crossed a fixed point and went through a change request.
The situation
The largest single programme budget I owned directly was the payments programme at Wema. It combined physical hardware, a mobile app and a web platform, with multiple external suppliers, and it had a problem built into its very shape that I think is one of the most useful things I have ever had to solve.
The hardware devices had to be designed, certified and manufactured on a fixed timeline, with the manufacturer needing the final specifications locked months in advance. You cannot iterate on a piece of hardware that has already been stamped out of a factory. The mobile app and the web platform, on the other hand, were built in 2-week sprints, because we were genuinely learning what customers and merchants wanted as we went.
So I had 2 teams that needed to run at fundamentally different speeds, for entirely good reasons. The software team wanted to keep changing things. The hardware team needed things to stop changing. Left alone, each team starts to see the other as the enemy: the software team thinks hardware is slow and rigid, the hardware team thinks software is chaotic and undisciplined.
What I did
I set up what I called fixed points. At specific milestones, we agreed that the interface between the hardware and the software was frozen. The software team could change almost anything they liked, as fast as they liked, as long as they did not change what the hardware expected of them. If they genuinely needed to change that interface, it went through a formal change request, with the cost and schedule impact on the hardware side made fully visible to everyone, including the people asking for the change.
Once everyone understood why the fixed points existed, the arguments mostly stopped. The software team stopped seeing the hardware team as slow, and the hardware team stopped seeing the software team as chaotic. They understood they were simply running at different speeds for good reasons, and the fixed points were the places where the two speeds safely met.
Outcome
The programme shipped on budget and roughly on time, which in a dual-rhythm hardware-and-software programme is a non-trivial outcome. More importantly, the shared understanding of “two rhythms, one programme” became the mental model the whole team used, which I think did more for delivery than any process document.
The lesson
I do not think of waterfall and agile as a choice between 2 religions. I think of it as choosing the right rhythm for each part of the work and then carefully managing the places where different rhythms meet.
That one idea has unstuck more arguments for me than any methodology ever has.
How I found out .
Each method, and why I chose it.
WhyCertification and tooling dates are not negotiable. Drawing them next to the sprint calendar showed where the 2 rhythms could safely meet.
The people it had to work for.
Composite and anonymised. Needs and frictions kept, names removed.
Persona 1 of 4
The hardware programme manager
A manufacturer that needs specifications locked months ahead, and a certification body that does not do iterations.
- Needs
- He needs things to stop changing, because the manufacturer cannot un-stamp a device.
- Friction
- A software team that treats every sprint as a chance to improve the device.
Written on the
inside cover
- Both teams were right. The hardware team needed stability and the software team needed freedom, for good reasons.
- Once the cost of changing the interface was visible, most proposed changes turned out to have a software-only alternative.
- Most arguments were about the interface. Almost none were about anything else.
- The phrase "two rhythms, one programme" did more for delivery than any process document.
What was actually on the wall.
The maps, papers and notes that did the work.
Most of this is under NDA, so each piece is described rather than shown.
-
Interface contract, v1 to v4
1 version per fixed point. Message formats, error codes, timings. Anonymised extracts in the exhibit.
-
Fixed-point calendar
4 dates on 1 page, pinned in both team rooms.
-
Change request template
With a mandatory section for hardware schedule and cost impact, filled in before anyone argues.
What changed, and what I keep.
- On budget
- for the largest programme budget I owned directly
- Roughly on time
- for a programme with physical devices, an app, a web platform and several suppliers
- 4
- fixed points where the interface was frozen
- 2 weeks
- the software rhythm, kept intact throughout
- The hardware, the app and the web platform shipped as 1 coherent service, which is the thing dual-rhythm programmes most often fail to do.
- The manufacturer relationship survived the programme intact, because interface changes arrived as costed requests rather than surprises.
- The phrase "two rhythms, one programme" became the team's shared mental model and did more for delivery than any process document.
- 01 Waterfall and agile are not 2 religions. Choose the right rhythm for each part of the work.
- 02 Manage the places where the rhythms meet. Everything else can run at its own speed.
- 03 Make the cost of a change visible to the person asking for it. Most arguments end there.
I would have held the first fixed point a little later. We froze the physical specification early to protect the manufacturing date, with less merchant evidence than I would want now.