There are now over half a dozen scaled Agile approaches on the market. From Large Scale Scrum (LeSS), to Nexus (Scrum.org’s scaled agile), Scrum at Scale (Jeff Sutherland’s version), Disciplined Agile Delivery (IBM’s version) and the Scaled Agile Framework (SAFe).
Whilst a few of these approaches have only been released in the last few years, many have been in use for a while with SAFe in use the longest from 2011.
They are generally additive frameworks – they utilise Scrum at their core, often utilising the concept of a Meta Scrum, a bigger Sprint across multiple teams that utilise smaller Sprints, first used back in 2006. Often they combine concepts – Meta Scrum, Scrum of Scrums, Scrum, Kanban and principles from Lean. It was because of this that many Agile practitioners like myself were willing to give scaled approaches time. Time to see who implemented them, time to see what worked, time to see how far it worked, time to see whether it resulted in long term change of real value.
Back in June 2016 I received my first long term information on how non customised, scaled transformations were going. I was speaking to a number of people who had spent the last year trying to implement SAFe within a government department. As I described my view on the limitations of scaling approaches, a number of them lamented that SAFe had not yet realised the lofty goals that management had expected of it. After my walk through, they said that they finally understood why it had fallen short.
Transformations do tend to take time and many of us had hoped that scaled approaches would be a gateway to a more comprehensive Agile implementation. I held out in hope that more time would move organisations onward to better agility.
Over the last few years I have seen a number of SAFe implementations, but I have yet to find one where senior leaders after a few years have said “This works amazing for us!”. What I hear instead is, “We thought we would go faster”, or “Getting work ready for the next Program Increment is impossible”.
Enough time has gone by now that I have now lost complete hope that SAFe will realise agility in organisations. Over a dozen senior leaders in organisations that have implemented SAFe have declared that it is not working for them. So where did it all go wrong?
The easy answer would be that it was being poorly implemented, but in almost every instance these organisations had brought in top tier experts in SAFe. So let’s look less on who is doing the implementation, and more to the implementations themselves and see the biggest callouts on why SAFe (or any other out-of-the-box scaled agile implementation) may not be the answer.
People treat it as a silver bullet
In fairness this is not a SAFe callout, or even a scaled agile issue. This is tremendously prevalent in the whole Agile community.
It comes into play when organisations hear the hype curve and think that if everyone else is doing Agile then they should too. They jump into Agile because the marketing tells them that they will deliver 200% more in half the time. They think if everyone has two days training then the results will come.
Today, I am shattering that illusion. If you are a senior leader and you think all you have to do is send people on training and then all your problems are solved, it just won’t happen.
Your people, your leaders, and especially yourself have to make serious change to get the intended results of Agile. And I am not just talking about doing a few ceremonies. I am talking about serious change – both in practices, policies, processes (all processes, not just software delivery), and especially behaviour.
Because Agile needs behavioural change to realise its benefits this is never going to be a journey taken overnight. Human behavioural change takes time, a lot of it. It takes anywhere from five to nine months of continually performing a new behaviour for it to become unconsciously triggered under stress. And leaders are often stressed. In this time, people will make mistakes, and they need to have a safe environment to learn.
If someone told you that the Agile Silver Bullet for a single person took six months and was fraught with failure would you think it was a Silver Bullet? No way! Stop thinking it is. Most organisations take five to ten years to complete a transformation across all its people. Agile really isn’t a sprint, it is a marathon, a 3100 mile Self-transcendence marathon.
It encourages massive batching
In the early days of Scrum it was mandated that Sprints were four weeks. I remember looking at this and after a few months of trying it wondering “Why a month?”. Not long after that, I started experimenting with three week, two week, one week and even one day sprints. Apparently I wasn’t the only one that felt it was odd, with many others experimenting and finding that two weeks almost always worked better than one month. Nowadays, if you tried to use a four week sprint, Agile folk would look at you as if you were crazy. They would lament that the feedback loops weren’t fast enough and that you should try to release something of value sooner.
My most significant issue with SAFe is that it is stuck in a similar vein of early days Scrum thinking – that larger is better. Program Increments (PIs) can be smaller, but everyone tends to implement them as a quarterly activity, this is because it isn’t a huge jump for organisations that already release quarterly, it can just fit in along with the existing organisational enterprise release cycles. Another reason that groups tend to have large Program Increments is because the effort to get a whole release train into a room for two days is phenomenally expensive, including the preparation time.
People implementing SAFe aren’t thinking really questions like, “How can I have smaller Program Increments?”, “If I had smaller PIs, would I need less time with everyone together?”, but critically, it doesn’t ask the biggest question of all, “How can I de-couple dependencies and better define the work so that it doesn’t have dependencies between teams?”. After all, if you can remove dependencies between teams than you don’t need a Program Increment at all. Teams could then just simply discover/incept the work once they have finished delivering a capability.
Which brings us to another point about SAFe’s batching – when teams are delivering in a Program Increment they are also busy discovering/incepting the work for the next Program Increment. Let me step through what happens:
- New to SAFe team runs a Program Increment and makes a commitment for the next quarter.
- Because of the two day PI timebox and no pre-work, they have a lot of outstanding questions for the work
- They spend a week or two trying to get all the questions answers whilst trying to deliver on their commitment
- Because they have spent unplanned time getting these answers and because a commitment was made based on poor information they get crushed at the end of the PI
- At the end of the PI retrospective they vow to never get into this situation again and their solution is to plan a little better leading into the PI
- But because they have only just discovered this insight, and they are about to start another PI, they accept their fate that the same problem will happen again. If they are smart they don’t load up the full PI to handle the unknowns
- If they are really smart they also set aside capacity for planning for the next PI (but they usually don’t do this until PI attempt #3)
- Eventually they get into a position of 65/25/10 – 65% of effort focused on current PI delivery, 25% focused on next PI planning, 10% in support of previous PIs
Great Agilists know that there is a price to context switching – it impacts productivity quite significantly.
Working in Program Increments not only delays release of value, reduces the speed of learning better ways, but also encourages greater context switching.
It encourages old world thinking on estimation
It is probably a minor point, but SAFe encourages teams new to story point based estimation to use the concept of “Ideal Dev Days”. Putting aside the fact that for a while now Agilists haven’t recommended using Ideal Dev Days to estimate, or that the definition of what an Ideal Dev Day is is still widely open to interpretation (is a tester a Dev, are all Devs of equal competence?), the very fact that SAFe encourages starting estimating by relating it back to time is missing the point.
Yes the website does say to do this only once, but most teams don’t read past the “start by doing this” remark to see that the next time that they estimate they should be using a different mechanism.
It doesn’t change leadership behaviours
On the positive side, SAFe is one of the earliest certification bodies to focus on leadership training explicitly. The content is also quite good. If you are lucky, 5% of your leaders will really listen and get it, but most won’t invest time to be trained.
If you want to quickly and easily find which leaders will make the change, provide the training as an opt-in activity. Go see who attends and important who doesn’t. Those who want to attend are more likely to have a growth mindset that is well aligned with Agile values.
Regardless of what scaled Agile framework you choose to take, leadership coaching is a must. Leaders will need to make space in their calendar, not just for the new ceremonies but to have dedicated time for coaching. More importantly, they will need to be open to new approaches to their own behaviours. Coaching will likely attempt to alter not just the impact a leader is trying to make, but their words and body language as they undertake their day to day activities. The easiest way to get started is for the most senior person in the organisation to open themselves up and be vulnerable to coaching and then advertise this to all of their leaders – this creates the much needed demand for coaching support.
It doesn’t force a change in organisational structure
SAFe describes all teams as “Feature teams” but does optionally describe the difference between Feature and Component teams. It’s definition is somewhat lacking in the difference between architectural and component teams and tends to combine both under the “Component” umbrella. It also fails to suggest other alternatives like Journey or Episode teams.
In every SAFe implementation I have seen in Australia, teams have started their SAFe journey as Architecture teams. Why? Because that is how they were already structured prior to starting their release train. In some respects this is understandable, after all, change is easiest when you start with what you are doing now. The biggest issue I have is that this creates an anti-pattern of SAFe co-dependency. Let’s walk through the steps again:
- New SAFe Release Train kicked off
- Teams are setup the way they are today (architecture/system oriented)
- First Program Increment planning session – massive dependencies between teams, but thankfully teams can now see the dependencies and co-ordinate to mitigate risk against them.
- Teams deliver despite the dependencies
- Because SAFe enabled a reduced risk approach to deliver with dependencies the team setup is not questioned further.
SAFe recognises this anti-pattern. Inside of its teams page it highlights that teams should be setup to minimise dependencies and handoffs, but it is written as a statement at the end of the page and most implementers ignore it.
I have seen one instance where a team recognised (with the support of their coach) that the dependencies were challenging due to team setup – primarily in a scenario where there were split teams for iOS and Android development. It took eighteen months for that release train to re-configure themselves into joint iOS and Android development teams.
I understand why SAFe implementers don’t push for this change day 1 – it requires potential HR changes, but at the very least consider if you can virtually get people together to reduce dependencies from day 1. Test and learn what works through virtual teams and then push for a formal HR change.
It doesn’t change the system around delivery
In the original days of Agile and Scrum, there was a criticism that teams were often in their own bubble doing delivery. Efficiency and effectiveness was limited to the delivery only portion, and whilst this bubble continued to expand over time, there were areas that were rarely touched – funding, governance, and HR processes and practices.
SAFe, continues to suffer from the bubble issue – it is just a bigger bubble, one that goes to a program or even portfolio level.
What it doesn’t fix includes:
- PMOs still exist
- Gating processes remain unchanged
- Funding processes remain unchanged
- Capex/Opex models remain unchanged
- Release management processes still exist
- Training and go to market processes remain unchanged
- Reporting expectations to senior leaders remains unchanged
- People hiring and onboarding processes remain unchanged
- Performance management, rewards and renumeration remain unchanged
Yes there is nothing stopping you as part of your SAFe implementation in tackling the above issues, and you should, but it isn’t clear that all of these problems will remain unless you additionally tackle them. As highlighted in the expectation that frameworks are a silver bullet, changing the above elements of the organisation is not a simple feat and certainly not something that will happen with an out-of-the-box implementation of a “Quick Start” release train.
So is there a better way?
For education and training, SAFe does a good combination of Scrum, Scrum at Scale, and some Lean and Leadership thinking in a combined session. The alternative option is a simple Certified Scrum Master course with a whole pile of other information tacked on, or some more generic scaling information in ICAgile’s offering.
As for transformation, there are other alternatives to using SAFe that you should consider if you are serious about Agile in your organisation:
- Find your own way. Scaled frameworks are there to get you to think of another way, it doesn’t mean that you can’t define your own approach. There will be pro’s and cons’s to some of your choices so it is a good idea to get help from an enterprise agile coach on how best to do this.
- Tackle the big problems. Fix what is the causing the most pain in delivery. Funding models is a common complaint amongst teams and yet it tends not to be the first thing that transformations try to tackle.
- Get the right people on your leadership team. There are three types of leaders – those who have done Agile before and live and breathe the values, those who say they have done Agile before but their actions indicate otherwise, and those who haven’t had the opportunity to give it a go. You want the former group to outnumber the latter group (and don’t keep those who say they’ve done it but their actions show otherwise). Over time, those who haven’t had an opportunity will end up being either true Agile champions or command and control managers in hiding or denial.
- Re-enforce the right behaviours and don’t reward the wrong behaviours. It sounds simple enough but this is hard to do well. Ocado is an online shopping website in the UK that invested heavily in this by having a program where once a week employees could nominate anyone in the organisation that was living their behaviours (or not). These behaviours were heavily influenced by the Agile values. If you were nominated you received an email with the comment that was made about you. If you had poor commentary, you didn’t get promoted. If you had consistently good commentary, you were eligible for promotion. Did this work for them? You bet.
- Focus on technical excellence and automation. Highly capable developers who know how to build software that can be automatically built, tested and deployed should really be the norm and not the exception to any business.
Good luck, and remember, no transformation is ever easy or safe.