SAFe Agile

The Scaled Agile Framework (SAFe) has some great practices. They can allow the benefits seen in small Agile teams to be realised at enterprise scale.

When I first heard about SAFe, I was sceptical. There seemed to be a lot of new terminology, such as Solution Train, or Architectural Runway, and I was not sure that it added much to basic Agile.

My company is faced with the challenge of expanding into different countries through acquisitions. Each unit will have IT development functionality, and we already consist of three different units with the number set to grow.

Allowing each to operate independently is not an option; there needs to be coordination to achieve maximum impact for the numbers. Our job as technology leaders is to ensure that Group IT work well together, with each business unit able to develop at both local and group level.

We need to be strategically aligned, working to the same architectural plans so that we can benefit from economies of scale. Having local silos of expertise will not enable a truly Agile performance.

The plan is to operate as an Agile company, however, each unit brings its own version of Agile to the party, with wide variations in practice. Rather than force the other teams to do it our way, I wanted to take a closer look at SAFe to see if it would be a fit.

My aim in looking for something new is to avoid a feeling in any unit that another team’s process, whether it is perfect or flawed, is being forced upon them. Rather, all units (at least those that are in existence now), would go into it as a new experience, and see it for the first time together.

Note that I also took a look at Daikibo, but felt that it would not be as close a fit for the nature of our organisation. Daikibo seems more tailored to a large consultancy company with requirement to support global systems.

This article will not describe everything in SAFe – there are plenty of articles available free on their website, www.scaledagileframework.com — but I would like to mention a few of the features that I particularly liked.

The Program Increment

Agile teams organise work into Sprints. For Scrum teams such as my own these are usually two weeks long, although one week and four weeks are also common. The Program Increment consists of a number of contiguous sprints to cover a total of between eight and twelve weeks.

One of the issues I find with our sprint-to-sprint schedule, with no real start or end point beyond calendar events such as holidays, is that it can become a bit monotonous and feel like there is no overarching goal to achieve.

Projects come and go, but rather than celebrating success, we often move straight into the next one. On rare occasions we can deal with some technical debt, but the point is that we deal with change on a non-stop basis.

Also, sprints tend to merge into one another. Some are successful and others are not, but it can be difficult to get a sense of progress without taking time out to review.

Retrospectives are useful, but most of the time we concentrate on the past two-week sprint and do not look at longer term trends.

So this idea of a Program Increment intrigued me. The idea that all the teams get together with all the business stakeholders for a session that can take a couple of days is awesome. Together the next eight to twelve weeks is planned and committed to, all under the objective of meeting some business goal.

Often we find it difficult to get answers to the most basic questions we have about the work we will be doing. Other times it is simply difficult to get priority calls. And we don’t regularly get feedback, positive or negative, directly from our customers. The PI planning session makes all this possible.

A two-day meeting with everyone involved may sound like a lot but there is a plenty to cover. Everyone there needs to share the same purpose, or vision, for the upcoming interval. The details are teased out in the session, then presented, challenged and reviewed.

The sprint in which this planning takes place is labelled the Innovation and Planning Iteration. It allows space for teams to reset. Often any technical debt that has built up can be addressed during this window or new ideas tried out. Many of the team will be needed to help prepare for the planning session itself.

I won’t go into all the details of what is involved in planning. For more information read the PI Planning page on the SAFe website.

The Release Train Engineer (RTE)

This role was new to me, although we had independently come up with a similar function in my organisation. This person will be at their busiest during the planning interval, making sure that the meeting goes off smoothly, but they have a lot to do the rest of the time also.

They work closely with the business executives, the architecture team and the security team to ensure that the backlog is prioritised and aligned with strategic goals. They need to make sure that everyone who is needed in planning the increment is there or at least available by phone to answer questions.

Ultimately they protect the decisions that are made at the planning interval to ensure that what was agreed upon is delivered. They will keep in regular contact with scrum teams to ensure progress is made. They massage the backlog, looking for the highest value items to bring into an increment next.

We formed a committee, which we called Release Governance, to do much the same thing. We focused more on making sure that our monthly release cycle delivered the right changes at the right time, limiting impact on business processes, and managing test resources.

While this worked well for us while we were all in the same office, it may struggle to manage change over multiple locations with different release cycles. With the number of infrastructure changes necessary to incorporate new offices in different countries, there is too much change for a committee to manage.

Having a dedicated role take responsibility for all released changes is a step forward. In the SAFe framework the RTE is depicted wearing a train engineer’s cap. This is an indicator of the importance of this individual in an Agile Release Train (ART).

The ART is another new term but is a good metaphor for the delivery of change on a constant basis. It helps us realise that the pace we need to deliver to keep up with business needs must be fast.

Continuing the metaphor, it is the architecture team that decide what track to follow, the project managers decide what and when to release along the way. But it is the engineer who decides and controls the pace that the train is going at, and ultimately how efficiently they can get there.

Focus on Program not Project

When you place everyone with an interest in software development into one room to plan an eight to ten-week increment, it forces them to be aware of what everyone else is doing.

Projects cause friction, in my view. A company might have anywhere from one to a dozen or more projects, most involving IT in some manner, and each project manager has to compete for resources.

Don’t believe me? I’m not just talking about development, QA or operations resources. They need access to the executive level for strategy decisions and calls, to business managers and their teams to arrange testing and training for new systems, to external vendors, to finance to ensure adequate budget is available to pay for everything, and the list goes on.

This creates a friction that is ultimately resolved by project managers, but often they are not the first to notice these problems; it is felt first by the resources that are being squeezed by requests from multiple directions. This is where the stresses are felt first, often leading to pressure and resentment.

While I have not been through a planning session for a Program Interval I love the way that it places all the stakeholders in a single room at once, forcing these conflicts on time and resources to be visible to everyone. It should be apparent where the shortages are before they occur.

It’s only when you play it all back at the end of the first draft of planning the increment that you realise that a particular resource is going to be needed by too many customers.

A program can be defined as a collection of projects, or as a general strategy for a company. Get everyone onto the same page about what the vision for the interval will should be, and it becomes easy, individual by individual, to see what impact that they can have on to make the program a success.

Projects still have a key role to play, but one project will not dominate unless it is chosen as the key goal for the entire PI.

Cross Functional Teams

It is difficult to convince management that we need to allow operators to work more closely with developers. We have often been faced with problems when it comes to moving a new piece of functionality into production.

Much of this is mitigated by being a close team that is comfortable talking to each other off-line, however, with an ever increasing team size and multiple offices in different countries, this will not work at scale. Already the amount of change being driven by operations to join the offices networks is causing downtime for our internally developed software.

This comes from a break down in communication, partly due to the number of new faces, and the new work habits that are developing, but also because there is not enough time to know or tell about every change in the system.

SAFe emphasises the necessity to form cross functional teams. If that is not possible, there is an opportunity during the PI planning session for developers to see the plans the operations team has and vice versa.

This gives a chance for either team to spot any potential issues. For example, if the developers say they have a dependency for ops to create a new database server, then operations won’t be surprised when the ticket to do so arrives the following week.

Operations might raise questions at planning, forcing the developers to think more carefully about what the use case is, thus avoiding being delayed by asking for the wrong specification and thus delaying the project.

If the development team is planning to use new infrastructure, setting up a new server for example, then they may request for an operator with appropriate experience to be allocated to their team for one or more sprints within the PI.

This is a great way to show the benefits that are possible by having cross functional teams without forming them prematurely or permanently. It makes sense to only add an operator to a team when there is a clear and defined need. But my hope is that the need for this and the benefit become clear over time so that it becomes the norm rather than the exception.

Conclusion

I have only looked at the tip of the ice berg as far as SAFe goes. I need to convince my colleagues that it is something worth trying. And support is going to be needed from the board level down.

Program Increments are a great extension of Agile that may make the most sense to introduce first. Getting access to all the people we need to make this happen is going to be a challenge.

Hiring a dedicated Release Train Engineer will be even more difficult. Perhaps some combination of Project Manager and our existing Release Governance can fill this role together. The Innovation and Planning Iteration might start out as just being about planning until we gather momentum.

The other concepts I like will naturally come about if we are successful with the first two.

SAFe also promises some Dev Ops principles that I am interested in looking into further. These are not as mature as the other concepts and will likely evolve over the next year or so. SAFe continually refines itself and is always striving to make itself better.