Everything described in there is mirrored in SAFe fwiw, even though their survey said it was mostly used in large non-tech companies.
Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team). Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams. Releases can happen at any point. A strong and continuously improving CI/CD pipeline is an expectation.
I really wish more people knew about SAFe. It’s constantly improving and refining the experience and from what I have seen, if there is a better way to do things SAFe will become it.
SAFe is beautiful in that it is the ultimate expression of Enterprise Agile Cargoculting: all pretenses of agility are lost, there are ten different levels of decision making, and all responsibility is diffused in a confused mess of worker bees running around under an all-powerful and all-seeing LPM
> Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team)
Except that they can't, because they will need to align on PI dates based on sprint durations, publish their burndown statistics and various other measures, and there's no way the poor soul who is reponsible for collating that will go into several different tools
> Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams
No they're not, they're done by the product owners, the system architects, the release train engineers (shhh... don't call them project managers), the product managers etc
> Releases can happen at any point
In my experience, releases can only happen at the end of a program increment, or maybe at the end of each sprint because until then nobody has integrated everything together
> A strong and continuously improving CI/CD pipeline is an expectation.
Fair enough, until the "innovation sprint" becomes the "bugfix spring" and all those good resolutions fly out of the window
> I really wish more people knew about SAFe.
So do I, just like I wish more people knew about colorectal cancer
> It’s constantly improving and refining the experience and from what I have seen, if there is a better way to do things SAFe will become it.
SAFe is constantly evolving, because that's the easiest way to keep the money coming in. It's as if PADI had found a way to change diving equipment every 2 years and ask everyone to recertify
One thing I've noticed with Scrum and SAFe are that all negative experiences are not _true_ scrum/safe. It seems entirely natural that processes will shift as team composition changes or the rules chafe. Once there's been drift from the canonical process there doesn't seem any way out of that except doubling down, possibly by buying more training.
Judging by the number of SAFe consultants (complete with that video of a guy drawing comic-book style diagrams about spotify, cute the first time but infuriating after the 10th) I'd have to say that if our SAFe was bastardised maybe SAFe itself is a bastard
I know many companies running SAFe on the east coast and it’s generally an improvement across the board from everybody I talk to. The only problems I’ve seen are from 2 camps: the people who don’t want to have to plan anything and the people who want everything that is planned to be 100% accurate and not a best guess. Either of these two groups will cause problems to a process like this with the latter usually being in some type of leadership role.
SAFe consultants or not, it’s still up to your company leadership to implement it. A lot of SAFe consultants I have talked to try to advocate for things that follow Scrum because many teams are already familiar with it. This is honestly one of the biggest issues that I have found with the teaching.
80% of SAFe is based on Donald Reniertson’s “2nd Generation Lean Product Development” book, which is fantastic. Once you’ve read that it’s easy to spot the differences.
I hate that diagram. It looks like gibberish to anyone who hasn’t gone through a training to understand it, and even this it still looks like gibberish.
SAFe is about addressing the communication problems that happen as an organization grows. You’re looking at the diagram for everything that would be applied to a very large organization.
SAFe itself has a goal of using 50-150 person “release trains” that are essentially independent units. That’s the core of what’s going on.
Everything outside of that is about managing communication between other “trains”. In the diagram that you’re looking at, the bottom 2 sections where the CD Pipeline sits is where most developers will experience SAFe and you’ll find that it simply advocates for DevOps best practices.
I completely understand how everything else looks like a mess. It’s a lot to digest.
Also note up in the top left corner, where you've got the customer abstractly feeding work into this treadmill of... stuff. If your development team aren't talking to either the customer, or representatives of the customer, nothing else in agile will work.
SAFe is just waterfall management with agile keywords tacked on. It's not an engineering methodology. The only "problem" SAFe solves is reintroduction of deadlines and quarterly objectives, which flies in the face of everything agile actually stands for.
The quarterly PI’s are for planning because the most you can reasonably plan for with any degree of accuracy is about 8-12 weeks.
There are no deadlines imposed. You plan what you’re going to work on and how long it will take. You coordinate with other teams for any dependencies they may need from you and when. But you as a developer are responsible for saying how long it will take and when you can have it done.
Even after that, you’re only allowed to plan 2/3 of your time and the final 2 weeks of the PI are unplanned specifically to build in more buffer for you. If you do finish when you originally planned to, that 2 weeks is equivalent to 20% time where you can work on anything you want for the company, training for yourself, etc. It’s a built in reward for being on schedule.
And then as a group you discuss all of the risks that could prevent one of these items from being hit schedule wise. So if something comes up that keeps a team from being able to finish something, everybody was aware of it in the beginning and had the opportunity to try to help address it.
There’s no waterfall to it unless you consider anything that acknowledges dependencies to be waterfall.
Planning for 8-12 weeks at a time is the ideal window that lets you set expectations, coordinate multiple teams and avoid derailment without the idea that you can plan forever into the future. The farther you get from now, the more any plans become pure imagination which is why year long waterfall plans are a joke. It’s entirely possible to plan 8-12 weeks at a time. Especially when the point of the system is to acknowledge that estimates are at best a guess.
There’s a balance between setting expectations that business people can plan around and working in a box without communicating anything other than “I’ll let you know when it’s ready.” SAFe strikes that balance better than anything I’ve seen.
But everything will always boil down to leadership embracing it. Until leadership can acknowledge the fundamental lack of accuracy from software estimates, you’re screwed no matter what the methodology.
> You as a developer are responsible for saying how long it will take and when you can have it done.
Which amounts to estimating software deliverables beyond the scrum window, which will invariably lead to disappointment, which will eventually fallback upon the shoulders of devs. It is impossible for delivery dates beyond the estimation horizon to not start being used by management as an anchor at some point in the near future. It only takes one manager promising stuff for the rest of the management team to try and emulate the savior.
Teams coordination only requires timely backlog priority management and does not need to be planned top-down for days on end with all members of all teams present.
Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team). Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams. Releases can happen at any point. A strong and continuously improving CI/CD pipeline is an expectation.
I really wish more people knew about SAFe. It’s constantly improving and refining the experience and from what I have seen, if there is a better way to do things SAFe will become it.