Launching an Agile Release Train While Standing in a Waterfall

• Pipeline Services - Get the right stuff on the train
• Development Services - Deliver the right stuff to the station on time
• Deployment Services - Get the stuff off the train
• Transition Services - Get teams ready to join the train
• Enterprise Services - Help the train operate within a mostly waterfall enterprise.

With an organisational structure in place, our next challenge lay in establishing our new ways of operating to become an agile program. We gave Pipeline Services the task of visualising the entire program - including the wagile and outsourced projects. We then reviewed the in-flight program of work and the pipeline. If a project had not already been outsourced, we considered it a candidate for delivery by the Agile Release Train. At the conclusion of this triaging process, we determined the last few projects we would outsource and committed to cease the practice of outsourcing deliverables from now on.

We initially had a couple of dicey moments with stakeholders requesting outsourced offshore delivery because they thought it would be cheaper. I offered the customer two options in these scenarios: (1) We send the project offshore. The customer pays the “cheaper” rate. But we take no responsibility for the quality of the outcome or the timeliness of the delivery; (2) The project is delivered by the EDW Agile Release Train, and I will guarantee a quality product within the timeframe and dollar range we quoted. Interestingly enough, no one ever chose option 1.

The projects that were deemed as destined to be delivered by the Agile Release Train were allocated to the pipeline team for inception work, in line with our interpretation of the analysis function in the Portfolio Kanban. The Pipeline team included several business analysts precisely for this purpose.

This turned out to be one of our early mistakes. Not only did this approach impede our ability to let go of our old working patterns, but we also found that when these projects were handed over to the feature teams, they came complete with a design and a bunch of technical rather than business features. This resulted in us moving to a model where the feature teams reserve 10% of their capacity each iteration for discovery work on new epics and to identify the features themselves. After all, as the manifesto says: “The best architectures, requirements, and designs emerge from self-organizing teams.”

Today the Pipeline Services team is headed up by a Program Portfolio Manager and consists of four Project Portfolio Managers and a couple of System Specialists.  For a more detailed understanding of how the Project Manager role evolved into that of a Project Portfolio Manager, check out my earlier post: What Happens to Project Managers When You Implement SAFe? I realise that on paper, Pipeline Services could easily be confused with a traditional PMO. This is not our intent. Unlike a traditional PMO, this team’s mission is to provide services to the development teams and not to manage or govern them.

Another of our early mistakes was allowing the Pipeline team to push epics to specific delivery teams of their choosing. Over time we have transitioned to a model whereby the Pipeline team showcase their work (ready-to-discover epics) to their product owner (development services). The Feature teams can pull the priority features into their rolling four-iteration plan as required. We still don't have this practice as smooth as I would like it to be, with organisational politics often creating situations where work allocation begins to look a lot more like a push than pull; however, we are committed to continually refining the process.

Development Services is led by a blended Development Manager / Release Train Engineer and is the home of our six feature teams. For us, the Release Train Engineer (RTE) role, as articulated in SAFe, has never really emerged. Instead, the responsibilities have been split across the three services leads, leading some folks to see me as the RTE!

In the case of the Development Services Manager, he is the facilitator of our cut-down version of PI planning and our adaptation of scrum of scrums (from the Cocktail Party in Henrik Kniberg's Lean from the Trenches). He leads the train’s continuous improvement effort, drives the adoption of engineering practices and coordinates the train’s approach to communities of practice (based on the Chapters model from Henrik Kniberg and Anders Ivarsson's paper Scaling Agile @ Spotify). The Pipeline Services lead and her team look after the bulk of the other RTE responsibilities, including facilitating prioritisation, escalation of impediments outside the control of the development teams, managing risk and formal epic status reporting (where required).

One of the more unusual and potentially controversial aspects of the Development Services structure is aligning the Scrum Master role with line management accountability for their teams. While this may not sit comfortably with many agilists, for us, it has been a significant improvement to our prior state and provided better support to our people. While we have experimented with the size and shape of our feature teams over time, we have landed on eight being the right size - a Scrum Master, a Technical Lead, a Test Specialist and five T-shaped developers. 

It is worth noting that reducing team size was a key enabler for growing T-shaped developers, as the non-homogeneous nature of the work required by the feature teams meant that teams needed developers to work outside their specialisations to meet their delivery commitments.

The third component of the EDW Agile Release Train, Deployment Services, is led by our Release Manager. This team has three functions - release services, environments services and the system team.

Release services coordinate all our production deployments, including hotfixes. On behalf of the EDW Agile Release Train, they have the primary relationship with the Enterprise Release & Test Management function and EDW production support operations. The Environment team provide DBA services to the feature teams, including the provision of development and test environments. The system team (known as the Three Amigos) is responsible for building our automated deployment and continuous integration capability. (For more on how this team has helped improve software engineering practices, see my earlier post on applying business change management to software engineering.)