Don't judge a framework by its implementation!
“This is how Scrum usually works in practice. The project manager becomes the scrum master. The business analyst becomes the product owner. The developers are literally the developers and the testers are in QA. The backlog is a storified version of the requirements document. It doesn’t matter if the story gets finished a 4-week sprint or not – because there’s a fixed scope and a deadline. After several sprints and at least 6 weeks before the release, there’s a code freeze and the SIT and CAT testing and bug-fixing happens. Then the code is released.”
As a purist scrummer are you incensed by this abhorrent misrepresentation of your beloved Scrum? How could someone mistake this abomination for the beauty of true Scrum? How dare people propagate these pernicious lies?
Let’s look at another example…
“This is how SAFe usually works in practice. The programme manager becomes the product manager. The project manager becomes the release train engineer. The product owners are glorified business analysts who do whatever the product manager says. The existing component/platform teams are renamed agile teams. The team/group leads become the scrum masters. Then they all work to get the fixed scope determined in the PI finished by the quarterly release deadline. Rinse and repeat.”
Are you nodding your head in agreement, thinking “Yup, that completely nailed SAFe!”? Fits with what little you know about SAFe? Well, if you actually knew anything about SAFe you’d be pretty incensed by the description above. Similar to the description of Scrum, the only similarity is the use of certain keywords. None of the spirit or essence of SAFe is recognisable.
However, it’s not uncommon to see these misconceptions thrown around with abandon. SAFe isn’t agile, it’s just revamped waterfall with a sprinkling of agile terms. But you’ve seen SAFe in practice? You know it’s true? Well, I’ve seen Scrum in practice as well. And it’s not always pretty. Actually, it’s rarely pretty – it’s mostly Frankenstein’s monster of misunderstood concepts and practices. Fortunately, I don’t judge Scrum based on that. I’ve been on courses, read books, worked on Scrum teams as a developer, tester, product owner and scrum master. I can spot the difference between real Scrum and mislabelled half-arsed attempt at fooling upper management that we’re now agile.
So have you actually taken any time to study SAFe? Or was the size of the poster enough to convince you it’s a bad thing? Have you read any books on it? Have you attended a course? Have you made an effort to get to know it like you might XP, Scrum or Kanban? What other business agility frameworks have you compared it to?
Or are you just happy to let your biases and self-righteousness get the better of you?
Title picture and other musings on life as an agile coach at agiledrillsergeant.com
That’s a tell.
Been there 😅excellent👌#mademyday
This leads to deeper, more troubling questions, starting with "Is Scrum (or XP, FDD, DSDM, Kanban Method, SAFe, DAD...) its ideal realization or its most common realization?" People will continue to ask this question and people will continue to answer it in the way that best represents their interests. And maybe that last point matters more than the question.
For a very interesting critique of the SAFe critics, have a listen to Alistair Cockburn in this podcast. If you want to jump past the manifesto story, they start to talk about SAFe at 43:00. https://agilpodden.podbean.com/e/83-agile-manifesto-with-alistair-cockburn/
I have studied SAFE. I am an SPC, have run PI planning and coached a team using SAFE. I read Dean Leffingwell and Don Rienertsen's pre SAFE books and really like them. Plus I was present at the birth of SAFe. I got to see the EDW project and it's PI planning which Dean made the heart of SAFE. SAFE contains a lot of good ideas and tools but the way it has been put together and in particular, the commercialisation of it has made it an anti agile monstrosity in practice. And yes SAFE does have to take responsibility for the way it's implemented in practice if it is nearly always implemented in this horrible anti agile way.