There are now over half a lots scaled Agile methods on the marketplace. From Big Scale Scrum (LeSS), to Nexus (Scrum.org’s scaled nimble), Scrum at Scale (Jeff Sutherland’s variation), Disciplined Agile Shipment (IBM’s variation) and the Scaled Agile Structure (SAFe).

Whilst a few of these methods have actually just been launched in the last couple of years, lots of have actually remained in usage for a while with SAFe in usage the longest from 2011.

They are usually additive structures– they make use of Scrum at their core, frequently making use of the idea of a Meta Scrum, a larger Sprint throughout several groups that make use of smaller sized Sprints, initially utilized back in 2006. Frequently they integrate principles– Meta Scrum, Scrum of Scrums, Scrum, Kanban and concepts from Lean. It was since of this that lots of Agile specialists like myself wanted to offer scaled methods time. Time to see who executed them, time to see what worked, time to see how far it worked, time to see whether it led to long term modification of genuine worth.

Back in June 2016 I got my very first long term info on how non personalized, scaled changes were going. I was talking to a variety of individuals who had actually invested the in 2015 attempting to carry out SAFe within a federal government department. As I explained my view on the restrictions of scaling methods, a variety of them regreted that SAFe had actually not yet understood the lofty objectives that management had actually anticipated of it. After my walk through, they stated that they lastly comprehended why it had actually failed.

Changes do tend to require time and a number of us had actually hoped that scaled methods would be an entrance to a more thorough Nimble application. I held out in hope that more time would move organisations onward to much better dexterity.

Over the last couple of years I have actually seen a variety of SAFe applications, however I have yet to discover one where senior leaders after a couple of years have actually stated “This works remarkable for us!”. What I hear rather is, “We believed we would go much faster”, or “Getting work all set for the next Program Increment is difficult”.

Enough time has actually passed now that I have actually now lost total hope that SAFe will understand dexterity in organisations. Over a lots senior leaders in organisations that have actually carried out SAFe have actually stated that it is not working for them. So where did it all fail?

The simple response would be that it was being inadequately carried out, however in nearly every circumstances these organisations had actually generated leading tier professionals in SAFe. So let’s look less on who is doing the application, and more to the applications themselves and see the most significant callouts on why SAFe (or any other out-of-the-box scaled nimble application) might not be the response.

Individuals treat it as a silver bullet

In fairness this is not a SAFe callout, or perhaps a scaled nimble problem. This is greatly common in the entire Agile neighborhood.

It enters play when organisations hear the buzz curve and believe that if everybody else is doing Agile then they must too. They delve into Agile since the marketing informs them that they will provide 200% more in half the time. They believe if everybody has 2 days training then the outcomes will come.

Today, I am shattering that impression. If you are a senior leader and you believe all you need to do is send out individuals on training and after that all your issues are fixed, it simply will not take place.

Your individuals, your leaders, and specifically yourself need to make major modification to get the designated outcomes of Agile. And I am not simply speaking about doing a couple of events. I am speaking about major modification– both in practices, policies, procedures (all procedures, not simply software application shipment), and specifically behaviour.

Due to the fact that Agile requires behavioural modification to understand its advantages this is never ever going to be a journey taken over night. Human behavioural modification requires time, a great deal of it. It takes anywhere from 5 to 9 months of continuously carrying out a brand-new behaviour for it to end up being automatically activated under tension. And leaders are frequently stressed out. In this time, individuals will make errors, and they require to have a safe environment to discover.

If somebody informed you that the Agile Silver Bullet for a bachelor took 6 months and was laden with failure would you believe it was a Silver Bullet? No chance! Stop believing it is. Many organisations take 5 to 10 years to finish a change throughout all its individuals. Agile truly isn’t a sprint, it is a marathon, a 3100 mile Self-transcendence marathon.

It motivates huge batching

In the early days of Scrum it was mandated that Sprints were 4 weeks. I keep in mind taking a look at this and after a couple of months of attempting it questioning “Why a month?”. Not long after that, I began explore 3 week, 2 week, one week and even one day sprints. Obviously I wasn’t the only one that felt it was odd, with lots of others exploring and discovering that 2 weeks generally worked much better than one month. Nowadays, if you attempted to utilize a 4 week sprint, Nimble folk would take a look at you as if you were insane. They would lament that the feedback loops weren’t quickly sufficient which you must attempt to launch something of worth earlier.

My most substantial problem with SAFe is that it is stuck in a comparable vein of early days Scrum thinking– that bigger is much better. Program Increments (PIs) can be smaller sized, however everybody tends to execute them as a quarterly activity, this is since it isn’t a big dive for organisations that currently launch quarterly, it can simply suit together with the existing organisational business release cycles. Another factor that groups tend to have big Program Increments is since the effort to get an entire release train into a space for 2 days is extremely pricey, consisting of the preparation time.

Individuals executing SAFe aren’t believing truly concerns like, “How can I have smaller sized Program Increments?”, “If I had smaller sized PIs, would I require less time with everybody together?”, however seriously, it does not ask the most significant concern of all, “How can I de-couple reliances and much better specify the work so that it does not have reliances in between groups?”. After all, if you can eliminate reliances in between groups than you do not require a Program Increment at all. Groups might then just merely discover/incept the work as soon as they have actually ended up providing an ability.

Which brings us to another point about SAFe’s batching– when groups are providing in a Program Increment they are likewise hectic discovering/incepting the work for the next Program Increment. Let me step through what takes place:

1. New to SAFe group runs a Program Increment and makes a dedication for the next quarter.
2. Due to the fact that of the 2 day PI timebox and no pre-work, they have a great deal of exceptional concerns for the work
3. They invest a week or 2 attempting to get all the concerns responses whilst attempting to provide on their dedication
4. Due to the fact that they have actually invested unintended time getting these responses and since a dedication was made based upon bad info they get squashed at the end of the PI
5. At the end of the PI retrospective they vow to never ever enter this scenario once again and their option is to prepare a little much better leading into the PI
6. However since they have actually only simply found this insight, and they will begin another PI, they accept their fate that the very same issue will take place once again. If they are wise they do not fill up the complete PI to deal with the unknowns
7. If they are truly wise they likewise reserved capability for preparing for the next PI (however they normally do not do this up until PI effort # 3)
8. Ultimately they enter a position of 65/25/10– 65% of effort concentrated on present PI shipment, 25% concentrated on next PI preparation, 10% in assistance of previous PIs

Excellent Agilists understand that there is a rate to context changing– it affects performance rather substantially.

Operating In Program Increments not just hold-ups release of worth, decreases the speed of discovering much better methods, however likewise motivates higher context changing.

It motivates vintage believing on evaluation

It is most likely a technicality, however SAFe motivates groups brand-new to story point based evaluation to utilize the idea of “Perfect Dev Days”. Putting aside the reality that for a while now Agilists have not suggested utilizing Perfect Dev Days to approximate, or that the meaning of what a Suitable Dev Day is is still extensively available to analysis (is a tester a Dev, are all Devs of equivalent proficiency?), the really reality that SAFe motivates beginning estimating by relating it back to time is missing out on the point.

Yes the site does state to do this just as soon as, however a lot of groups do not check out past the “start by doing this” remark to see that the next time that they approximate they must be utilizing a various system.

It does not alter management behaviours

On the favorable side, SAFe is among the earliest accreditation bodies to concentrate on management training clearly. The material is likewise rather excellent. If you are fortunate, 5% of your leaders will truly listen and get it, however a lot of will not invest time to be trained.

If you wish to rapidly and quickly discover which leaders will make the modification, supply the training as an opt-in activity. Go see who participates in and essential who does not. Those who wish to go to are most likely to have a development state of mind that is well lined up with Nimble worths.

Despite what scaled Agile structure you pick to take, management training is a must. Leaders will require to make area in their calendar, not simply for the brand-new events however to have actually committed time for training. More significantly, they will require to be available to brand-new methods to their own behaviours. Training will likely try to change not simply the effect a leader is attempting to make, however their words and body movement as they undertake their daily activities. The most convenient method to start is for the most senior individual in the organisation to open themselves up and be susceptible to training and after that promote this to all of their leaders– this develops the much required need for training assistance.

It does not require a modification in organisational structure

SAFe explains all groups as “Function groups” however does additionally explain the distinction in between Function and Element groups. It’s meaning is rather doing not have in the distinction in between architectural and element groups and tends to integrate both under the “Element” umbrella. It likewise stops working to recommend other options like Journey or Episode groups.

In every SAFe application I have actually seen in Australia, groups have actually begun their SAFe journey as Architecture groups. Why? Since that is how they were currently structured prior to beginning their release train. In some aspects this is easy to understand, after all, modification is most convenient when you begin with what you are doing now. The most significant problem I have is that this develops an anti-pattern of SAFe co-dependency. Let’s stroll through the actions once again:

1. New SAFe Release Train started
2. Groups are setup the method they are today (architecture/system oriented)
3. First Program Increment preparing session– huge reliances in between groups, however luckily groups can now see the reliances and co-ordinate to reduce danger versus them.
4. Groups provide regardless of the reliances
5. Due to the fact that SAFe made it possible for a decreased danger method to provide with reliances the group setup is not questioned even more.

SAFe identifies this anti-pattern. Within its groups page it highlights that groups must be setup to reduce reliances and handoffs, however it is composed as a declaration at the end of the page and most implementers overlook it.

I have actually seen one circumstances where a group identified (with the assistance of their coach) that the reliances were challenging due to group setup– mainly in a situation where there were divided groups for iOS and Android advancement. It took eighteen months for that release train to re-configure themselves into joint iOS and Android advancement groups.

I comprehend why SAFe implementers do not promote this modification day 1– it needs prospective HR modifications, however at the minimum think about if you can practically get individuals together to decrease reliances from day 1. Test and discover what resolve virtual groups and after that promote an official HR modification.

It does not alter the system around shipment

In the initial days of Agile and Scrum, there was a criticism that groups were frequently in their own bubble doing shipment. Effectiveness and efficiency was restricted to the shipment just part, and whilst this bubble continued to broaden in time, there were locations that were seldom touched– financing, governance, and HR procedures and practices.

SAFe, continues to experience the bubble problem– it is simply a larger bubble, one that goes to a program or perhaps portfolio level.

What it does not repair consists of:

• PMOs still exist
• Gating procedures stay the same
• Financing procedures stay the same
• Capex/Opex designs stay the same
• Release management procedures still exist
• Training and go to market procedures stay the same
• Reporting expectations to senior leaders stays the same
• Individuals employing and onboarding procedures stay the same
• Efficiency management, benefits and renumeration stay the same

Yes there is absolutely nothing stopping you as part of your SAFe application in dealing with the above concerns, and you should, however it isn’t clear that all of these issues will stay unless you in addition tackle them. As highlighted in the expectation that structures are a silver bullet, altering the above aspects of the organisation is not a basic task and definitely not something that will occur with an out-of-the-box application of a “Flying start” release train.

So exists a much better method?

For education and training, SAFe does a great mix of Scrum, Scrum at Scale, and some Lean and Management thinking in a combined session. The alternative choice is a basic Qualified Scrum Master course with an entire stack of other info added, or some more generic scaling info in ICAgile’s offering.

When it comes to improvement, there are other options to utilizing SAFe that you must think about if you are major about Agile in your organisation:

1. Discover your own method. Scaled structures exist to get you to think about another method, it does not indicate that you can’t specify your own method. There will be professional’s and cons’s to a few of your options so it is a great concept to get assist from a business nimble coach on how finest to do this.
2. Take on the huge issues. Repair what is the triggering one of the most discomfort in shipment. Financing designs is a typical problem among groups and yet it tends not to be the very first thing that changes attempt to take on.
3. Get the best individuals on your management group. There are 3 kinds of leaders– those who have actually done Agile prior to and live and breathe the worths, those who state they have actually done Agile prior to however their actions suggest otherwise, and those who have not had the chance to try. You desire the previous group to surpass the latter group (and do not keep those who state they have actually done it however their actions reveal otherwise). Gradually, those who have not had a chance will wind up being either real Nimble champs or command and control supervisors in concealing or rejection.
4. Re-enforce the best behaviours and do not reward the incorrect behaviours. It sounds basic enough however this is tough to do well. Ocado is an online shopping site in the UK that invested greatly in this by having a program where as soon as a week staff members might choose anybody in the organisation that was living their behaviours (or not). These behaviours were greatly affected by the Agile worths. If you were chosen you got an e-mail with the remark that was made about you. If you had bad commentary, you didn’t get promoted. If you had regularly excellent commentary, you were qualified for promo. Did this work for them? You wager.
5. Concentrate on technical quality and automation. Extremely capable designers who understand how to develop software application that can be instantly developed, checked and released must truly be the standard and not the exception to any organization.

Best of luck, and keep in mind, no improvement is ever simple or safe.