Lot of discussion has been made of SAFe as it seems to be gaining huge popularity. This could be due to the certification course and the 4 or 5? day training.
Question is, does it really adhere to the principles of the Agile manifesto? And if the answer is no what does that mean for scaling agile?
In the Nexus guide, it states that it’s impossible to stay agile past 9 scrum teams.
What are your thoughts?
I’ve done SAFe at two separate engagements; one was a full adoption/transformation with the methodology, the other was an agile shop that adopted the framework in an attempt to bring order to scaling.
The first instance had tons of issues with the problem they were trying to solve by adopting the framework i.e.-tying multiple teams together across different silos to deliver on a program. The “scrum of scrums of scrums” was non-existent in both resources, attendance, and empowerment, and that problem was solved by throwing a bunch of people at it hoping it would just work. By the time I left it still wasn’t effectively working, altho they were “muddling through.”
Second instance has gone much better vis a vis the transformation; they went in whole-hog and are doing all the ceremony and delivering. I have noticed however that the framework is so rigidly defined that it’s basically “waterfall enterprise IT planning with iterative delivery window(s)”…there’s this giant 2-day “program increment planning session” that takes all the resources off the floor to plan out the next 10 weeks, or attempt to plan. That’s an expensive two days of questionable value. There’s only around 10 teams at play so I think the tipping point has been reached, I’ll have to see what happens when we throw more shovels at it.
I get SAFe and why an IT executive would want to use it, as it’s got all the governance and steps that give them comfort as well as it being a fully-defined turnkey agile adoption solution. But I could see an attempted adoption go disastrously wrong if your culture isn’t ready for it/not enough knowledge in the org to aid in the transition/rushed timelines with unrealistic expectations/etc. Basically every reason for every failed agile transformation 
I must admit I don’t know much about other frameworks but am curious. Like making a great meal I think the true solution to scaling agile would be picking-and-choosing from different recipes ingredients you think will work, trying the meal, and then making changes and trying again until you find the right fit.
Just my two cents.
Another emerging model by Andy Hunt: GROWS: http://growsmethod.com/
I look forward to experimenting with it…
Here’s another one that just came out: http://oikosofy.com/oikosofy-enterprise-agile-framework/
I have no real experience with SAFe, but feel that most scaling frameworks can be replaced by good leadership, excellent facilitation, common sense, and basic agile practices. Given that…I guess I subscribe more to the thought leadership that Mike Cottmeyer (Leading Agile) has been putting out on the subject the past several years.
The first thing Craig Larman says in his LESS workshop is don’t scale Agile to you absolutely have to. How’s that for a Sales Pitch!
So, not to be cliche, but every organization needs to start with “Why”. Why do you want to scale agile? What will it allow you to accomplish? Typical answers are:
Will scaling Agile really solve these issues? Perhaps eventually, but your talking about turning a complex adaptive system, that is the organization and its culture, on its head. A very daunting task.
What if we compliment the “why” question with “when?” “Mr CEO, when would you like to realize the benefits of Agile?” We all know the answers is always “yesterday.” Is adopting one of the numerous scaling methodologies going to allow you to achieve that? Most likely not.
Which brings me to my sort of “radical” view on scaling. I don’t believe changing your existing organization will allow you to realize the benefits of agile early in the adoption. Instead, start fresh, and form a new agile organization within the walls of your enterprise. Run experiments with different practices from all frameworks to see what works for given your unique objectives and culture. Dealing with the pain points at a smaller scale is much easier.
As we learn, and new objectives surface, on-board new teams into the new organization. If your lucky, the new agile organization will evolve and replace the existing one! Perhaps the scaling issue will surface again, but you will be in a much better position to succeed at this point. This approach is inspired by Ken Schwaber’s Scrum studio concept.
Too many companies are starting off on the agile journey using SAFe, get good at just using scrum, pick a handful of teams and get it right. Get some early wins then add more teams using just scrum and SoSoS.
Bottom line don’t scale crap!!
As an SPC we have been using SAFE for 9 months. It works well as a framework, not a rule book. In fact inside of SAFE, they call out using it more framework based.
Is it perfect no!, but it has helped us through explosive growth and transition keeping the main things the main things while remaining very agile.
Especially with mixed methodology teams. We have SCRUM, Kanban, XP, and Lean UX teams at the team level and SAFE support planning across them with some light modification.
is it pure agile… No! The teams are still highly agile. The program level helping the teams plan is somewhat a fractle of scrum on a longer “sprint” but with a hint of lean. Above that it become more LEAN and principles based. The top level, which can be formal or informal, is very lean/Kanban
The big question-- does it work! - yup. Last cycle
17 team / 3500 points/ 147 feature 1780 user stories with 89% predictability.
Wow @Shaw557, that is great progress in 9 months.Your case at is very interesting in that the organization was agile for 5 years and then adopted SAFe. Was there not a need to scale earlier on? Or was their failed attempts?
Not the biggest supporter of SAFe… Recently Dean and Alex put out a blog post on Essential SAFe which boils that King size comforter of diagram and all it process to 8 key Points.
When I look at scaling all of the existing frame works have good and bad practice (IMO), but they are designed to fix issue in your org to help a bunch people deliver together. That’s why I continually go back to the Heart of Agile (Alistair Cockburn) and look at what is broken or need adjusting with the org and team then run and experiment to see if that fixes it.
This could be as simple as a product owner stand up which just facilitates better communication across PO’s… which could help sequence backlogs and sprint dependencies. Simple and effective
Scaling always boils down to teams with good technical practices that can deliver consistently working and tested software. With out this foundation scaling only compounds the issue and is pointless.
I have really started looking at practice and concepts to manage the Dunbar Number. I will stop myself here before I wonder down a rabbit whole.
Actually, maybe we should venture down Dunbar’s rabbit hole. I think there is something useful there.
In terms of developing empathy, rapport, trust, safety, ownership, let alone coordination costs… a tribe of ~150 seems like an upper limit, regardless of what tools or technology we try to throw into the cave…
Doing some Research today on DAD… they focus on what they call a Large Agile team Concept. This feel like Scaled Agile Framework’s Agile Release Train with some slight twist…
Here is the link to it… http://www.disciplinedagiledelivery.com/agility-at-scale/large-agile-teams/
I recently obtained the Scaled Professional Scrum certification from Scrum.org . This is based on the Nexus framework. A lot of it is based on many people are already doing when scaling scrum but adds another layer with an integration team (who doesn’t do the actual integration BTW).
If anyone has any questions i’d be happy to answer about that.
I’m interested to hear more about the logistics behind planning and executing work when you have teams practicing different methodologies within the same ART. I learned in SAFe training that it is possible, but from what I’ve seen in practice, folks tend to shy away from that. In my personal experience, I’ve seen people lean towards suggesting that the teams decide together which methodology to follow. While it’s good to empower the teams with that decision, I don’t think this is really setting them up to perform at their best, as much as they would by practicing the methodology that they’re the most familiar with and that they’ve worked to optimize.
Would be curious to hear about this as well. I have not been through a full blown SAFe implementation yet. I am a test away from my SPC. I would be curious to when anyone chimes in on your question how close they are following the SAFe framework or are they skipping any of the parts. From my research and understanding when you don’t include certain parts of the SAFe framework things really do fall apart seems a little less forgiving them SCRUM in a lot of ways. If that makes sense.
