Context
In 2014, one of Canada’s largest banks started a two-year project: building a platform to consolidate financial transaction data from 30 globally distributed source systems. Project leadership took interest in Agile, but their environment was still strongly rooted in Waterfall thinking; the development process they customized – only for programmers and testers – was in essence Waterfall with three-week cycles. The process performed relatively well during the easy first phase of the project, but wasn’t appropriate for the second phase’s length and complexity.
Designing a Way of Working
In February 2015, Gil Broza facilitated three collaborative meetings in which 14 key project members designed their approach to phase two. The participants started by reaching shared understanding and agreement that the following four values were important for that phase:
- Quality of the data (accuracy, completeness, timeliness, …)
- November 2015 delivery
- Responding to changing, uncertain, or vague requirements
- Quality of “the machine” (their word for the platform)
They also articulated some of their beliefs. Beliefs that had the highest impact on method design were:
- It’s very hard to determine the right data from each source system – many are in other countries, maintained by people who are not fluent in English, and the data isn’t always clean.
- Unless our “machine” brings in complete, clean data, downstream users won’t use it.
- We can and should produce a complete spec for “the machine,” even though it evolves.
- We know which source systems are in scope now, but others might be added later.
- It is both valuable and practical to complete the work for just a few source systems at a time.
Based on these values and beliefs, the participants chose their operating principles:
- Flow; Get to “done”; Work to outcomes; Customer feedback
- Effective first and efficient second; Minimalism; Defer decisions to the last responsible moment
- Quality
- Servant leadership
- Visibility
- Team collaboration and feedback
- Continuous improvement
Next, the group used these choices to design the team structure (the project had about 35 people at the time). There would be a “data team” of BA & QA folks, responsible for all aspects of data and interactions with source systems and downstream consumers. The architects and data modelers would comprise a small architecture team. A core team, working in two streams, would build the technology — one source system at a time. Lastly, an assembly team would focus on integration, configuration, tooling, and deployment.
They also defined an initial workflow with a six-week release cadence and three classification levels for data maturity (akin to an incremental definition of “done”).
Supporting the team
Over four months, for three days a week, a 3P Vantage coach helped the project team ingrain the chosen mind-set and develop good habits. For example, the coach helped project leadership create a physical project-level board, which they placed it in the area of highest foot traffic. Every two days, representatives from each of the above teams congregated in front of the board for a quick check-in. The board’s design evolved multiple times before settling on a useful form.
Within a few weeks of working on this phase, the team realized that having a single product owner wasn’t working out for multiple reasons. Instead, a group of five managers/leaders took ownership of the work queue, using majority vote for decision-making.
In a third example of customization, it became clear quite quickly that standups and colocation were not enough for keeping everyone informed. Therefore, the team developed additional communication channels: team lead updates, a blog, and a discussion forum.
In this period, team engagement and morale improved noticeably, and they shipped platform increments with high quality every six weeks. Flow was practically palpable.
How it ended
Five months in, Gil and the team members reviewed what principles they were actually following. The list was strikingly similar to the one used in process design. Team progress was so smooth at this point that stakeholders weren’t interested in status meetings anymore; the big visible project board was enough for them.
When this phase ended, the group — without needing assistance — repeated the process design activity described above in preparation for the different circumstances of phase three. The project team stayed mostly unchanged, enjoying high morale and an effective and efficient workflow, until the project ended one year later.
