Running the transformation using a SAFe Agile Release Train

Empowering change in an agile way.

By Glenn Smith, SPCT and Charlie Fleet, SPC

Abstract

If we had a dollar for every time someone said agile cannot be used outside of the IT space, we’d be rich! This article outlines how we brought numerous non-IT functions together to work in an agile way and deliver the transformation, using the SAFe Agile Release Train (ART) construct to run the transformation. How the shape and size of the Lean-Agile Centre of Excellence (LACE) ebbed and flowed while launching over 15 ARTs, all achieving business outcomes. More significantly, we will explore this approach’s lasting legacy to the broader organisation.

Context

Through growth coming from various mergers and acquisitions, the multinational enterprise had over 3,000 staff globally, with the majority working on delivering business-to-business products for the travel industry. It had recently realised they were no longer an industry company but a technology company and needed to think and act differently. By their own admission, senior leaders’ opinions and the sales function were the primary drivers of strategy and objectives, rather than a modern product management philosophy.

After the early wins during the launch of the first three Agile Release Trains (ARTs), tensions started to emerge. The transformation was being perceived as a US-led, engineering-centric activity that wouldn’t have a material change in the broader enterprise. However, if allowed to play out, this assumption wouldn’t deliver the business agility the organisation desired.

The LACE reflected. One thing that jumped out was that the textbook LACE models didn’t seem to provide the answer to close the gap in understanding and the confusion being felt. None of the existing models were a decent fit for taming the dependencies and incompatible ways of working existing between functional groups spread across three continents

A crazy idea was born – the LACE leadership proposed that the LACE should “eat its own dog food” and use a SAFe ART to run the transformation. We thought it would be the perfect vehicle to align ways of working and managing the dependencies.

Between the two authors of this article, we represented both the client and the external transformation partner. As we share our views and recommendations, we would like to acknowledge we were part of a broader change agent community and are thus channelling the efforts of many in what we share.

Actions

So the process of widening the membership of the LACE to become an ART started very much as a grass-roots activity, leveraging the informal network of leaders that had recently graduated from a nine-month leadership development program.

In just one Program Increment, the LACE morphed from a single agile team into a 70-person team of teams of 70 mid-level leaders who were up for the challenge. It spanned marketing, sales, communications, HR, account management, corporate development, and others. We wanted to demonstrate that these functions, which would not typically be perceived as bedfellows with agile or need to collaborate closely, could and should. Our mission was to transform the enterprise. With this initial groundswell of buy-in and motion, getting the executive support for this experiment became a more straightforward activity.

Some functions joined pretty readily, eager to make the enterprise better. It was an easy sell for some, as in the case of the HR team, having a very forward-looking leader. We suspect most didn’t know what they were getting themselves into!

Not everyone though just jumped on board. Plenty of coffee drinking with arm-waving at the SAFe website and doodles on whiteboards were needed to bring people into the fold. Common questions that needed answering included, why are we doing this?, why should I care?, what’s in it for me? A perfect example of this was the facilities team. They had heard and seen much activity happening, including regular significant events (PI Planning), but they didn’t know what was happening and if they should be helping or stopping it. We outlined to them the issues the enterprise had been experiencing and the linkage of those issues with how it operated to deliver products. They were still unsure but agreed to try joining the transformation ART to get closer to the action and, at the very least, see what everyone was up to.

With our people assembled, we needed to launch the ART. Being a non-IT ART had no bearing on the steps we undertook compared to any other ART. An SPC was assigned to guide, train, undertake team formation and support PI Planning.

All of the existing ARTs had a common cadence and synchronisation, so we echoed this as there was a plan for the entire portfolio to have the same heartbeat. As we needed to interact with other ARTs, this worked well, as we could align our roadmaps, allowing them to predict and plan for the temporary impact of change. For the two coaching teams, from around seven teams on the train, this created a pinch point during the iteration ceremonies, as their team sessions often clashed with the teams they were coaching, so they would adjust their timings to work around this.

The ART structure followed the traditional format with all the ART leadership roles in place. The RTE, a recent agile convert having seen how effective agile had been on the ARTs, did a fantastic job at modelling the behaviours you would desire across the ART needed for those new to this way of working. In addition, we appointed one of the senior SPCs who had done numerous transformations to become the System Architect. Their role was to gain high-level consistency of application of the work of the ART, by defining guiding principles and setting standards.

Modelling good behaviours, all teams had both a PO and SM, although they may not have been full-time and typically didn’t come from those roles, so we had to coach people.

The mission for the ART was to enact a change in working practices across the enterprise to enable a shorter time to market with a focus on more valuable work. Therefore, measuring the ART’s impact would likely be impossible in the same PI. Instead, we turned to leading indicators to define and measure value in the PI, as our long-term success was linked to these lagging indicators of business outcomes.

Leading indicators helped ensure the backlog was more than just ‘doing stuff’. For example, instead of creating a backlog item to just delivering a course, we looked at engagement measures like feedback, exams, etc. Expect to see this pattern in your non-IT teams, so measure the near-term outcomes of their work. Be prepared to explain why their backlogs need to be units of value and not just discrete tasks.

We didn’t invest in making it easy to utilise reusable knowledge through the joys of running at pace. We found that for repeating backlog items, like training delivery, we either duplicated a previous item in our Agile Application Lifecycle Management (ALM) tool or recreated it by hand. Our suggestion would be to curate repeating items, wrapping in new learnings into a catalogue you can simile pull from when needed. Some non-IT teams can have considerable repeatable work, so we suggest making it visible, and the catalogue approach will reduce the friction of doing so. It wasn’t a conscious tradeoff decision for us, but it should have been.

Once up and running, it wasn’t smooth sailing. Not everybody was fully dedicated to the transformation because they couldn’t wholly free themselves from the day job, and we didn’t want to set the bar so high to join that few did. The reality is that these teams struggled with their PI predictability measure. It reached the point where people with a minimal capacity allocation were discouraged from being on the train to being supportive of the train. In hindsight, this wasn’t the correct model as these VPs had great enthusiasm for change, distancing them from the action.

Fast forward three PI’s, the transformation train was making lots of progress. We had launched around 15 trains, seeing measurable business benefits, including 85% predictability and 50 to 90% shortening of lead time on feature delivery.

With the last few trains nearing launch, office space made fit for purpose and a vast swath of the organisation trained, the transformation ART had served its predominant purpose. We didn’t need the big structure we now had, and it was time for the LACE to reduce in size.

As the LACE entered its next phase, evolving with the needs of the enterprise, the value and its lasting legacy were much greater than the 15 or so ARTs it had launched. While The ART had catalysed around those from the leadership development program, we now had a wider durable network of people who could get things done. In addition, muscle memory had been created on how to interoperate across functional and geographic boundaries.

More encouragingly, because of the success within the transformation ART and elsewhere, there was now a pull across a growing range of functions where people were asking, “would agile work here?”. We connected these enquiries with the increasing number of internal SPCs. One example was the go-to-market team, which up until this point had sat on the periphery with the effect of slowing adoption of the new products being developed. With the support of a capable SPC, they became an agile team. They adopted the same cadence and synchronisation as the rest of the organisation, gaining alignment and shortening lead times as a result.

There was still some resistance to the transformation. They were happy to paint a picture that transformation ART had failed. We had to manage communication by talking to stakeholders. A changing structure is an example of agility, as some felt this implied we hadn’t designed and implemented it correctly.

Today the enterprise no longer needs a formal transformation team. Using agile across the entire enterprise is just how they do things. It has become the new business-as-usual.

Takeaways

Share stories outside the IT domain

Remind people who tell you that agile only works for software or hardware that there are plenty of examples where this isn’t the case. In your organisation, you likely already have one, the LACE. If you struggle with examples from within your organisation, borrow ours and others you find.

Create and leverage networks to speed change in those wanting to get change

Transformation is always more straightforward when there is a pull to get involved. Leveraging your existing networks, you can speed this up after your initial quick wins. Use them shamelessly to get to parts of your organisation more quickly than if left to happen organically. In addition to existing ones, invest in building a wider network through whatever means. A great example is training classes, not simply opportunities to provide new skills but a chance to connect with people. Also, look to leverage a shared interest and create Communities of Practice to pull together like-minded people who want to discuss, explore and grow around a particular topic.

Beware of the curse of knowledge when pitching

When explaining the benefit of agile or the issues other parts of the organisation are struggling with, it is far too easier to fall foul of the curse of knowledge. This is where we don’t mention things we think are known when they are not. So when talking to new teams about their agile journey, go back to basics.

Guide teams on how to break work into smaller chunks of value

Help business teams starting their agile journey and struggling to break down work to fit in the artificial containers of iterations and PIs to use leading indicators to expose and then measure the value in the smaller slice over needing it all. Share the principles behind this approach and the benefit it brings.

Evaluate how part-time effort should be integrated

When our VPs struggled with time, they stepped away completely, but if we had the time again, we would do it differently. It might be more sensible to think of them as a shared service or supplier, attending PI planning and making commitments on behalf of their wider organisation.

Create a catalogue of repeating work

Where teams are doing repeatable work, have them curate a catalogue of backlog items to reduce the burden of planning their business-as-usual items. Teach them to use them as repositories of reusable knowledge that they can iterate as they learn. The catalogue can be as simple as a document on a shared location like a wiki.

The design and size of agile teams and team of teams will evolve with the demand

Like the experience of how our LACE adapted over time, agile teams or ARTs will evolve in size and shape based on the need, and that’s okay. Kotter’s book Accelerate discusses the need for an adapting value network, which can provide you with talking points.