Transforming A Waterfall Programme
Shorter time to market: From 6 months to 4 weeks
Satisfaction: unhappy to happy teams and stakeholders
Stability: From chaotic component teams to stable Feature Teams
Planning: From being blind to evidence-based forecasting based on the velocity and effectiveness of the teams
At a new client, a complex waterfall programme asked help to transform. Many complex problems, in its various projects and their teams. There was no way out for the leadership team to improve things. To start and understand the situation, one of our specialist agile coaches began to engage with the teams, project managers, tech leaders and others.
The first findings were appalling, and their problems seemed hard to solve. Lack of transparency of the work at hand, silo-ed teams, circa six month time to market (lead time), phased waterfall approach (mixed with sprints that were planned - meaning the scope of the sprints was fixated). There were no visuals on progress. There was no understanding of the value of the output. There were disjointed projects in the programme, negative energy, many conflicts, no meeting hygiene, semi-burned out leadership, demotivated teams and hardball project managers pushing the developers to the brink of quitting their jobs. Scrum masters were hired and had an overlap with a directly assigned project manager; this led to more conflict. An excellent opportunity for improvement.
“Many conflicts, no meeting hygiene, semi-burned out leadership”
The start
When one finds such a vast array of issues, the mountain of problems in front, seems hard to climb, or let alone dissect. The coach conducted a series of informal interviews with those people who the transformation coach believed, were able to influence cultural change: the project managers, individual developers, the leadership team of the programme and some technical leads from the various groups. The two Scrum Masters were on the verge of dropping their work and walking out of the building, the head of the programme indicated that she was burned-out.
Roll-out
By making the actual problems (their effect on the organisation and the future budgets) transparent to the leadership, top-down buy-in was made possible. While the coach focused on this, the Scrum framework and its simple rules are slowly implemented (e.g. sprint scope doesn't change, developers aren't swapped mid-sprint), the team and a product owner owns the backlog.
But there was a problem. There weren't any product owners, which led the coach to the next issues: Who would fill in the gap of the product owner role? There was no buy-in to spend more money; however, the teams needed a person to own the backlog, who also knew the work, had the relationships with the stakeholders and could take the right decisions. Now, some of the PMs started learning about product management and prioritisation.
(Please note: We take note that there is no default route for doing this, sometimes it's hard to find the right character, there's no one-size-fits-all mapping towards the Product Owner role)
Product Ownership and value evolution
While the PMs were now focusing more on the Product Owner role, the Scrum Masters were able to socialise the concepts of focusing on value earlier, versus just following the plan set in stone. Some PM's found it very difficult to convince their stakeholders to be 'flexible' about the output and switch to a focus on producing value earlier so to satisfy the needs of the stakeholders. Producing value more first enabled the stakeholders to test the product earlier and validate the outcomes.
After numerous small changes, organisational course corrections, positive manipulations, and following most of the agile events, artefacts and roles, the system had become significantly more productive. For our coach, this engagement had been intensive and rewarding at the end.
Hindsight
Getting the teams to be stable, to become more effective was hardest to get done. When the teams started to understand their velocity, they learned to know how effective they were and how they contribute to their goals. Then the teams started to do preliminary estimations of more significant bits of future work (story mapping, etc.). With the teams working together closely, in a stable environment, this contributed to more motivation, and with higher focus, they shared a single goal. That helped the team members to become more supportive of each other. The coach helped the Product Owners to build burn-up charts*. And use those to negotiate value earlier in the timeline, and drop those 'nice to have' features and focus on high-value features instead and prioritise these.
While our coach worked on the transformation, a central body in the organisation had been formed. And the tribe, which was constructed by our coach, supported an example for the rest of the organisations' transformation.
The organisations' biggest websites were migrated successfully, in time and on or under budget. The time to market (lead time) reduced to 4 weeks.
*Burn-up charts: Charts that show time and the amount of story points completed cumulatively, also these charts show the variation of speed, and by using that deviation number plot a line, as a forecast to the future. The forecast includes both a pessimistic and an optimistic delivery data for parts of the work