SAFe-ty first

 

There are actually over half a dozen scaled Agile approaches available on the market. From Large Scale Scrum (LeSS), to Nexus (Scrum.org’s scaled agile), Scrum at Scale (Jeff Sutherland’s model), Disciplined Agile Delivery (IBM’s model) and the Scaled Agile Framework (SAFe).

Whilst a couple of of those approaches have solely been launched in the previous few years, many have been in use for some time with SAFe in use the longest from 2011.

They are typically additive frameworks – they utilise Scrum at their core, usually utilising the idea of a Meta Scrum, a much bigger Sprint throughout a number of groups that utilise smaller Sprints, first used again in 2006. Often they mix ideas – Meta Scrum, Scrum of Scrums, Scrum, Kanban and ideas from Lean. It was due to this that many Agile practitioners like myself had been prepared to offer scaled approaches time. Time to see who applied them, time to see what labored, time to see how far it labored, time to see whether or not it resulted in long run change of actual worth.

Back in June 2016 I acquired my first long run info on how non customised, scaled transformations had been going. I used to be talking to quite a few individuals who had spent the final 12 months attempting to implement SAFe inside a authorities division. As I described my view on the constraints of scaling approaches, quite a few them lamented that SAFe had not but realised the lofty objectives that administration had anticipated of it. After my stroll via, they stated that they lastly understood why it had fallen brief.

Transformations do are inclined to take time and many people had hoped that scaled approaches could be a gateway to a extra complete Agile implementation. I held out in hope that extra time would transfer organisations onward to raised agility.

Over the previous few years I’ve seen quite a few SAFe implementations, however I’ve but to search out one the place senior leaders after a couple of years have stated “This works superb for us!”. What I hear as an alternative is, “We thought we might go quicker”, or “Getting work prepared for the following Program Increment is inconceivable”.

Enough time has passed by now that I’ve now misplaced full hope that SAFe will realise agility in organisations. Over a dozen senior leaders in organisations which have applied SAFe have declared that it’s not working for them. So the place did all of it go fallacious?

The straightforward reply could be that it was being poorly applied, however in virtually each occasion these organisations had introduced in high tier consultants in SAFe. So let’s look much less on who’s doing the implementation, and extra to the implementations themselves and see the largest callouts on why SAFe (or some other out-of-the-box scaled agile implementation) is probably not the reply.

People deal with it as a silver bullet

In equity this isn’t a SAFe callout, or perhaps a scaled agile situation. This is tremendously prevalent in the entire Agile neighborhood.

It comes into play when organisations hear the hype curve and suppose that if everybody else is doing Agile then they need to too. They soar into Agile as a result of the advertising and marketing tells them that they may ship 200% extra in half the time. They suppose if everybody has two days coaching then the outcomes will come.

Today, I’m shattering that phantasm. If you’re a senior chief and also you suppose all you need to do is ship individuals on coaching after which all of your issues are solved, it simply received’t occur.

Your individuals, your leaders, and particularly your self should make severe change to get the meant outcomes of Agile. And I’m not simply speaking about doing a couple of ceremonies. I’m speaking about severe change – each in practices, insurance policies, processes (all processes, not simply software program supply), and particularly behaviour.

Because Agile wants behavioural change to understand its advantages that is by no means going to be a journey taken in a single day. Human behavioural change takes time, plenty of it. It takes wherever from 5 to 9 months of regularly performing a brand new behaviour for it to change into unconsciously triggered below stress. And leaders are sometimes pressured. In this time, individuals will make errors, and they should have a secure setting to be taught.

If somebody instructed you that the Agile Silver Bullet for a single particular person took six months and was fraught with failure would you suppose it was a Silver Bullet? No manner! Stop considering it’s. Most organisations take 5 to 10 years to finish a change throughout all its individuals. Agile actually isn’t a dash, it’s a marathon, a 3100 mile Self-transcendence marathon.

It encourages large batching

In the early days of Scrum it was mandated that Sprints had been 4 weeks. I bear in mind this and after a couple of months of attempting it questioning “Why a month?”. Not lengthy after that, I began experimenting with three week, two week, one week and even sooner or later sprints. Apparently I wasn’t the one one which felt it was odd, with many others experimenting and discovering that two weeks virtually all the time labored higher than one month. Nowadays, in the event you tried to make use of a 4 week dash, Agile folks would take a look at you as in the event you had been loopy. They would lament that the suggestions loops weren’t quick sufficient and that you must attempt to launch one thing of worth sooner.

My most important situation with SAFe is that it’s caught in an identical vein of early days Scrum considering – that bigger is best. Program Increments (PIs) could be smaller, however everybody tends to implement them as a quarterly exercise, it’s because it isn’t an enormous soar for organisations that already launch quarterly, it may well simply slot in together with the prevailing organisational enterprise launch cycles. Another cause that teams are inclined to have giant Program Increments is as a result of the hassle to get an entire launch practice right into a room for 2 days is exceptionally costly, together with the preparation time.

People implementing SAFe aren’t considering actually questions like, “How can I’ve smaller Program Increments?”, “If I had smaller PIs, would I would like much less time with everybody collectively?”, however critically, it doesn’t ask the largest query of all, “How can I de-couple dependencies and higher outline the work in order that it doesn’t have dependencies between groups?”. After all, in the event you can take away dependencies between groups than you don’t want a Program Increment in any respect. Teams may then simply merely uncover/incept the work as soon as they’ve completed delivering a functionality.

Which brings us to a different level about SAFe’s batching – when groups are delivering in a Program Increment they’re additionally busy discovering/incepting the work for the subsequent Program Increment. Let me step via what occurs:

  1. New to SAFe workforce runs a Program Increment and makes a dedication for the following quarter.
  2. Because of the 2 day PI timebox and no pre-work, they’ve plenty of excellent questions for the work
  3. They spend every week or two attempting to get all of the questions solutions while attempting to ship on their dedication
  4. Because they’ve spent unplanned time getting these solutions and since a dedication was made based mostly on poor info they get crushed on the finish of the PI
  5. At the tip of the PI retrospective they vow to by no means get into this example once more and their answer is to plan just a little higher main into the PI
  6. But as a result of they’ve solely simply found this perception, and they’re about to start out one other PI, they settle for their destiny that the identical downside will occur once more. If they’re sensible they don’t load up the total PI to deal with the unknowns
  7. If they’re actually sensible additionally they put aside capability for planning for the following PI (however they normally don’t do that till PI try #3)
  8. Eventually they get right into a place of 65/25/10 – 65% of effort centered on present PI supply, 25% centered on subsequent PI planning, 10% in help of earlier PIs

Great Agilists know that there’s a worth to context switching – it impacts productiveness fairly considerably.

Working in Program Increments not solely delays launch of worth, reduces the velocity of studying higher methods, but additionally encourages higher context switching.

It encourages previous world considering on estimation

It might be a minor level, however SAFe encourages groups new to story level based mostly estimation to make use of the idea of “Ideal Dev Days”. Putting apart the truth that for some time now Agilists haven’t beneficial utilizing Ideal Dev Days to estimate, or that the definition of what an Ideal Dev Day is continues to be extensively open to interpretation (is a tester a Dev, are all Devs of equal competence?), the actual fact that SAFe encourages beginning estimating by relating it again to time is lacking the purpose.

Yes the web site does say to do that solely as soon as, however most groups don’t learn previous the “begin by doing this” comment to see that the following time that they estimate they need to be utilizing a distinct mechanism.

It doesn’t change management behaviours

On the constructive facet, SAFe is likely one of the earliest certification our bodies to concentrate on management coaching explicitly. The content material can also be fairly good. If you’re fortunate, 5% of your leaders will actually hear and get it, however most received’t make investments time to be skilled.

If you need to rapidly and simply discover which leaders will make the change, present the coaching as an opt-in exercise. Go see who attends and essential who doesn’t. Those who need to attend usually tend to have a progress mindset that’s properly aligned with Agile values.

Regardless of what scaled Agile framework you select to take, management teaching is a should. Leaders might want to make house of their calendar, not only for the brand new ceremonies however to have devoted time for teaching. More importantly, they may should be open to new approaches to their very own behaviours. Coaching will doubtless try to change not simply the impression a frontrunner is attempting to make, however their phrases and physique language as they undertake their daily actions. The best method to get began is for essentially the most senior particular person within the organisation to open themselves up and be weak to teaching after which promote this to all of their leaders – this creates the a lot wanted demand for teaching help.

It doesn’t power a change in organisational construction

SAFe describes all groups as “Feature groups” however does optionally describe the distinction between Feature and Component groups. It’s definition is considerably missing within the distinction between architectural and part groups and tends to mix each below the “Component” umbrella. It additionally fails to recommend different options like Journey or Episode groups.

In each SAFe implementation I’ve seen in Australia, groups have began their SAFe journey as Architecture groups. Why? Because that’s how they had been already structured previous to beginning their launch practice. In some respects that is comprehensible, in spite of everything, change is best once you begin with what you’re doing now. The largest situation I’ve is that this creates an anti-pattern of SAFe co-dependency. Let’s stroll via the steps once more:

  1. New SAFe Release Train kicked off
  2. Teams are setup the best way they’re right now (structure/system oriented)
  3. First Program Increment planning session – large dependencies between groups, however fortunately groups can now see the dependencies and co-ordinate to mitigate threat towards them.
  4. Teams ship regardless of the dependencies
  5. Because SAFe enabled a diminished threat strategy to ship with dependencies the workforce setup just isn’t questioned additional.

SAFe recognises this anti-pattern. Inside of its groups web page it highlights that groups needs to be setup to minimise dependencies and handoffs, however it’s written as a press release on the finish of the web page and most implementers ignore it.

I’ve seen one occasion the place a workforce recognised (with the help of their coach) that the dependencies had been difficult attributable to workforce setup – primarily in a situation the place there have been cut up groups for iOS and Android growth. It took eighteen months for that launch practice to re-configure themselves into joint iOS and Android growth groups.

I perceive why SAFe implementers don’t push for this variation day 1 – it requires potential HR adjustments, however on the very least contemplate in the event you can just about get individuals collectively to cut back dependencies from day 1. Test and be taught what works via digital groups after which push for a proper HR change.

It doesn’t change the system round supply

In the unique days of Agile and Scrum, there was a criticism that groups had been usually in their very own bubble doing supply. Efficiency and effectiveness was restricted to the supply solely portion, and while this bubble continued to increase over time, there have been areas that had been not often touched – funding, governance, and HR processes and practices.

SAFe, continues to endure from the bubble situation – it’s only a larger bubble, one which goes to a program and even portfolio stage.

What it doesn’t repair consists of:

  • PMOs nonetheless exist
  • Gating processes stay unchanged
  • Funding processes stay unchanged
  • Capex/Opex fashions stay unchanged
  • Release administration processes nonetheless exist
  • Training and go to market processes stay unchanged
  • Reporting expectations to senior leaders stays unchanged
  • People hiring and onboarding processes stay unchanged
  • Performance administration, rewards and renumeration stay unchanged

Yes there’s nothing stopping you as a part of your SAFe implementation in tackling the above points, and you must, however it isn’t clear that each one of those issues will stay except you moreover deal with them. As highlighted within the expectation that frameworks are a silver bullet, altering the above parts of the organisation just isn’t a easy feat and definitely not one thing that may occur with an out-of-the-box implementation of a “Quick Start” launch practice.

So is there a greater manner?

For training and coaching, SAFe does a superb mixture of Scrum, Scrum at Scale, and a few Lean and Leadership considering in a mixed session. The different choice is an easy Certified Scrum Master course with an entire pile of different info tacked on, or some extra generic scaling info in ICAgile’s providing.

As for transformation, there are different options to utilizing SAFe that you must contemplate in case you are severe about Agile in your organisation:

  1. Find your personal manner. Scaled frameworks are there to get you to think about one other manner, it doesn’t imply you could’t outline your personal strategy. There will likely be professional’s and cons’s to a few of your decisions so it’s a good suggestion to get assist from an enterprise agile coach on how finest to do that.
  2. Tackle the massive issues. Fix what’s the inflicting essentially the most ache in supply. Funding fashions is a standard criticism amongst groups and but it tends to not be the very first thing that transformations attempt to deal with.
  3. Get the appropriate individuals in your management workforce. There are three forms of leaders – those that have accomplished Agile earlier than and stay and breathe the values, those that say they’ve accomplished Agile earlier than however their actions point out in any other case, and those that haven’t had the chance to offer it a go. You need the previous group to outnumber the latter group (and don’t maintain those that say they’ve accomplished it however their actions present in any other case). Over time, those that haven’t had a chance will find yourself being both true Agile champions or command and management managers in hiding or denial.
  4. Re-enforce the appropriate behaviours and don’t reward the fallacious behaviours. It sounds easy sufficient however that is exhausting to do properly. Ocado is an internet procuring web site within the UK that invested closely on this by having a program the place as soon as every week workers may nominate anybody within the organisation that was dwelling their behaviours (or not). These behaviours had been closely influenced by the Agile values. If you had been nominated you acquired an electronic mail with the remark that was made about you. If you had poor commentary, you didn’t get promoted. If you had persistently good commentary, you had been eligible for promotion. Did this work for them? You wager.
  5. Focus on technical excellence and automation. Highly succesful builders who know construct software program that may be robotically constructed, examined and deployed ought to actually be the norm and never the exception to any enterprise.

Good luck, and bear in mind, no transformation is ever straightforward or secure.

Categories: Agile, Agile at scale


Source link