September 30, 2015

A Train to SAFety: An Ongoing Series

At CCC we have been building custom software to support our business for over 20 years.  As our mission has evolved, software and services delivered via software have proliferated and become a more significant part of our business.  This has led to a number of different development projects started at different times, under different methodologies and different business climates.  We adopted Agile as a company-wide practice for new projects, but now even some projects started as agile have reached a phase in their lifecycles where they don’t require a dedicated scrum team, but they are still supported and occasionally released – which means yet another style of project.

When we adopted agile, we also adopted a product platform approach, and built program management around the creation of the various parts of the product platform.  This gave us some consistency in technology as well as in project management.  However, when teams needed to co-ordinate, special-purpose scrum of scrums tended to proliferate, and took on lives of their own.  Also, so much activity was taking place within the program that information that should have reached an audience outside an individual scrum team could get lost in the details of status reports.  This still left some long-running legacy development efforts outside of the program and integrating them into the program became even more difficult as we starting getting towards the long tail of one-off projects where the benefits of technology standardization were expensive to achieve and customer demand for changes in delivery models was weak.

When the product platform program started showing growing pains, we started looking around for alternate models that could handle the complexity of our development efforts, and we started looking into the Scaled Agile Framework (SAFe) and saw a lot to like in its concept of an Agile Release Train – which represents a collection of teams working together on related goals, that are aligned to a source of value to the enterprise.  But what is the impact for team members working on stories on teams?

Train Essentials

Having your team put on a train shouldn’t be a traumatic event.  The goal is to reduce the pain points associated with our polyglot approach to development by streamlining communication paths and improving consistency across projects – not to introduce another layer of complexity.

Because the teams on a train are working towards similar goals, it’s common for one team to require something from another team on the train.  So, teams on the same train regularly scrum together as part of their process.  They can negotiate contracts between themselves quickly and verify their work via continuous integration and delivery.  Conversely, teams on different trains don’t have the same kind of mutual dependencies and contracts between trains tend to involve more than two parties and may require more planning and preparation.  The key here is in identifying which teams should share a train, and which ones shouldn’t.  We’ve done this based on surveying our teams and looking at the patterns of shared library usage in our build files.  It’s also important to allow for, and provide a mechanism for teams to “jump trains” and switch at appropriate times based on the project’s life cycle.

One common reason for jumping trains is a project has moved from proof-of-concept to working towards MVP to maintenance and finally to retirement.  Consistency in planning and processes within a train is important to facilitate communications and collaboration on the train, but different trains can operate differently.  We’re experimenting with trains that do time-boxed iterations for projects that are doing regular releases to production, but projects that are doing proof-of-concepts for new products, or working on retiring legacy projects we’re planning on shifting to a flexible, shared work-queue arrangement to better handle shared resources and unpredictable requirements.

This concept of allowing teams to jump trains raises a different challenge with which we’re still grappling: How can we measure progress, investment and quality consistently between trains?  Future updates in this series will present our thinking and results as they become available, along with other developments as we further adapt and flesh out SAFe for our use.

Matt Kleiderman

Director of Architecture