Bringing Agility to Your Organization, Part 2

scaled-agile
Posted by Suzie

11 August 2015

As discussed in my previous blog post, many organizations want to scale agile to achieve the benefits of adaptability and responsiveness across levels. In order to achieve this, and to meet the demands of their business, they turn to large-scale agile frameworks—such as SAFe—to help them transition. Yet do these frameworks really help organizations achieve the agility they want and need to stay relevant?

Here I’ll explore some of the dangers of using SAFe, and how SAFe may not be the answer for all organizations looking to scale agile.

hiking

Appearance of agility

One common complaint about practises like SAFe is that they are not agile at all and are in fact mini-waterfalls. Yet whether SAFe is or isn’t waterfall doesn’t matter: What matters is SAFe’s ability to support the level of agility your business needs.

If we take organizational agility to mean “the ability to both create and respond to change in order to profit in a turbulent business environment”, then how much agility an organization needs depends on whether you’re in a turbulent business environment, and if you are, how quickly you need to respond. We believe for those that truly require rapid innovation, adaptability and change, SAFe is not the best option. If followed as suggested, as we’ve seen at a variety of organizations, SAFe would mean development teams building requirements defined by other teams months before implementation. By adding “hardening” iterations and release trains, SAFe does not allow for continuous innovation, quality and delivery, as these are only allowed for on pre-determined schedules.

working

Achieving agility beyond the development team demands a culture change in an organization, yet SAFe does not attempt to change organizations. SAFe supports a control culture by scaling management and scaling reporting mechanisms.

One size does not fit all

There is no getting away from it: one of the fundamental reasons agile organizations are successful is that the teams changed, adapted and delivered value the way they wanted to achieve their goals. Any team that is not given the ability to work how it wants will not achieve all that they can. While SAFe is a framework that can be altered, there are many places (such as story estimation, iteration length, release train length) that suggest a very prescriptive process. At the very least, SAFe’s focus on specific ways of working and the top-down nature of requirements management dilute the power of the high-performing teams that are so critical to a responsive enterprise.

Management-focused, not value-focused

Much of the process of SAFe is geared towards management visibility, understanding and control. For example, estimates in SAFe are aligned and used to manage time and cost drivers rather than team based improvement measures. Similarly release trains suggested by SAFe as a way of coordinating large pieces of work are counterproductive to striving to release more often and actually limit the ability of enterprises to respond to change.

SAFe does not necessarily change the fundamental thinking of old organizations with control cultures.

Our advice is that enterprises should stop thinking about “scaling” process and start thinking lean. More important than management understanding and visibility are the principles of delivering value more often through frequent releases, shorter feedback loops and smaller upfront commitments that allow enterprises to respond to change. Similarly, a better way to manage teams and understand progress toward goals is to track measures such as business value delivered, cycle time, quality and customer satisfaction. These measures will drive the right outcomes rather than the ones that indicate if an original plan is on track.

description-here

So do we recommend rolling out SAFe when scaling agile?

It depends. It is highly likely chaotic or waterfall organizations who use SAFe will see some benefits from improved visibility, transparency and alignment. However, an organization that follows SAFe without any understanding of the underlying principles, that has not had previous successes at the team level, or does not understand their successes, will fail to become truly innovative, adaptive and responsive using SAFe alone. This is because SAFe does not necessarily change the fundamental thinking of old organizations with control cultures, waterfall mindsets and needs. SAFe is very easy to interpret and slice and dice, and therefore, to adulterate. You may well end up using SAFe practises to simply rename your waterfall process rather than adapt and respond.

We suggest if you want to use SAFe, you look at it as a way to get started or to learn about some techniques for scaling agile. Like all frameworks, some of what is suggested will work for you and some will not. If you have no process at all you may find that the structure from SAFe works well to control chaos, but you should expect to change and adapt. More importantly, you need to know your context, where you are going, and what you want to achieve by being agile. SAFe alone will not get you there.


comments powered by Disqus