“Framework XXX doesn’t work”
It is almost always the fault of the implementation
Whatever we do, we humans like to bash other ways of doing.
Here are 3 examples of frameworks and models that have been victims of such bashing:
- Scrum, often seen as a way to squeeze ever more juice out of developers
- SAFe, usually seen as the most bureaucratic and evil Agile at scale framework
- Waterfall, distinguished as the worst way to work now that Agile is everywhere
Personally, I see a pattern in these 3 examples: to some extent, the bashing is justified because it is what happens all too often.
I’d like to go one step further and choose my words carefully. What is witnessed and judged upon is how these 3 frameworks and models are practiced. The judgement is rarely based on the true value of said framework or model.
Let’s take a closer look at these 3 examples.
“Scrum is a way to squeeze ever more juice out of developers”
Popular beliefs
“Working with Scrum is the same as before except that now we are expected to deliver every two weeks”
“At least before we had specifications; now we have to work with whatever is thrown at us”
“The point of Scrum is to force the team to overcommit, and then to force the team to stick to it in whatever way”
Sad quotes, right? Sadly not that uncommon…
Witnessed implementation
These quotes obviously come from disgruntled developers. This is what they might have been through:
- The Scrum Master is either absent, the management’s puppet, or himself rewarded on the raw output of the team and nothing else
- The Product Owner is a micro-manager, defining and assigning technical tasks, and also giving judgment on the performance of individual members
- Retrospective meetings are not conducted, or at best are run in a ridiculously short amount of time and action items are rarely put in place if ever
- No time is ever allowed for continuous improvement
- Sprint Review meetings are skipped, or are nothing more than a demo; success theater instead of progress transparency
- Definition of Done has not been defined, or nobody knows its existence, or it is plainly ignored
- What matters is shipping on time, not value brought to the customer, nor the quality of what is shipped
- Velocity is used as a mesure of performance; maybe velocity is measured for individual team members
- Having a developer talk directly with customers is impossible
- And on and on…
The list of anecdotes is endless, obviously varying from one bad experience to another. How sad…
What the framework is meant to be
I feel sorry for you if all you have ever experienced of Scrum is the kind of things I just listed.
As an experienced Scrum Master, all the examples given in this list are so damn wrong.
Scrum is about collaboration, transparency, full team ownership, extreme focus, continuous improvement… None of these examples match the Scrum mindset.
Mindset? Yes: while some examples are simply not following the Scrum Guide, others are more in the lines of a perverted implementation of tools and guidelines.
My point really:
You can implement Scrum without explicitly breaking the rules and yet end up with a perverted environment seeking the exact opposite of Scrum.
Is it Scrum?
The company would say it is. The team members would think it is if they don’t have any other experience of Scrum. Hence the original quote of disgruntled developers: “Scrum is a way to squeeze ever more juice out of developers.”
Indeed they are right about the environment they experienced, which was labeled “Scrum.”
“SAFe is the evilest Agile at scale framework”
Popular beliefs
“Just look at this picture summing up all of SAFe on a single poster: doesn’t it feel bloated and overly complex?”
“Linking estimations in SAFe back to real time units is easy: 1 point = 1 man-day of work”
“PI Planning is the worst meeting of all. What’s the point of stopping everyone during 2 full days? Boring!”
“SAFe enforces processes for everything…”
Witnessed implementation
The stereotype implementation of SAFe is about strictly following all of the guide. And the guide is, well… rather big.
- SAFe implementations end up being a whole pile of processes
- Processes over collaboration
- Centralized structures of Product Managers and Architects take care of all the important stuff, leaving only minor details to the teams; decision making is centralized
- All teams use the same baseline for point estimations; that make it easy to compare velocity between teams and judge which teams should be more rewarded
Does it look like the old way of doing? There sure is some commonalities…
What the framework is meant to be
As pointed out by Henrik Kniberg SAFe is, first and foremost, a really big toolbox. (link at the end of the post)
Implementors are expected to select and adapt tools appropriate to their context. It is more about getting started than following strict guidelines.
However, it is true that many companies love SAFe because it gives a lot of answers. It is comforting to big managers to rely on the SAFe guide backed up by consultants with SAFe certifications.
As a result, many SAFe implementations are, indeed, a pile of processes not that different from how the organisation was before.
This explains easily why many people in the Agile community criticize SAFe, based on the witnessed implementations.
But is it SAFe to be criticized? Should SAFe be blamed?
We can see that in these dubious SAFe implementations, the company is thinking the same. There is no change in mindset.
Don’t blame SAFe for people not wanting to think. It is not SAFe which is process-heavy; it is the culture of the companies that say they do SAFe while in fact they just work as before.
“Waterfall is intrinsically wrong”
Popular beliefs
“Everything about waterfall should be killed”
“Gantt charts are bad”
“If you doing any kind of detailed specification, then you’re doing it wrong”
“We know better than waterfall and V-cycle now”
Witnessed implementation
Often, Agile is defined by comparing it to waterfall, explaining how everything is different.
- This comparison is so strong that anything related to waterfall becomes banned: “specifications” are now forbidden
- Management cannot be challenged on whether the company is doing Agile or not; this is taken for granted and cannot be discussed
- New projects are now done “the Agile way” (often Scrum and SAFe 😒) but the mindset is the same at the company level, outside of engineering: new feature ideas come from the bosses’ minds, and year-long roadmaps are required
- Years of project management experience are forgotten, in particular about dependencies and risk management; some traditional project managers are not sure what to do next, given the impression that they are starting a whole new career from scratch
What the model is meant to be
It is true that “traditional” project management is flawed and it’s no wonder Agile is now so pervasive.
Let me get this straight: what’s wrong with waterfall is not inherently the model; it is the lack of iteration. As long as you do short cycles, you will be good with waterfall.
This is actually known for a very long time, and even the father of the V cycle, Winston V. Royce, acknowledged it and excluded using only one cycle. But history chose another path and forgot his legacy to only remember the phases…
Beyond iterative and incremental development, the other big difference with Agile is the focus on the human side of projects. Collaboration is paramount. Yet taking this human side of projects into account has never been forbidden by the waterfall model.
What I am trying to say is that the practices around the waterfall model are not the problem; it is the mindset.
Running an “Agile” project with the same traditional, old-fashioned mindset will only lead to ugly results. Don’t blame waterfall.
What is there to say about companies that completely stopped doing specifications in the name of Agile, ending up with developers improvising business rules on the fly?
What is there to say about companies that once were completely reluctant to Agile and are now forbidding using waterfall-tainted words? Is it dogmatism or following the herd?
3 examples, a single pattern
A pattern emerges from these 3 examples: the mindset is off.
- Scrum is completely hijacked in an attempt to make more money in the short term, not caring about sustainability
- SAFe is applied in the most stupid way, leading to a bureaucracy very alike to how the previous organization was working
- Waterfall is now forgotten so that nobody doubts how Agile the company is now, in spite of the same mindset
In short:
Despite a move to “Agile”, the company works like before. No, actually it is now worse because not only the mindset is flawed, but in addition its previous experience has been forgotten.
In the end, it is all about people and their mindset. Problems are rarely caused by a given framework. It is almost always the fault of the implementation.
Sources and further reading
Some background about Agile at Scale
Tales of broken (and often toxic) Agile implementations
The useless Scrum Master
Lars Roost & Henrik Kniberg: “Is SAFe Evil?”
TL;DR: it’s a toolbox
Winston W Royce and how single-pass waterfall is wrong
Winston W. Royce (1970). “Managing the Development of Large Software Systems” in: Technical Papers of Western Electronic Show and Convention (WesCon) August 25–28, 1970, Los Angeles, USA.
Agile Manifesto about sustainability
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Liked this article? Show it!
Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.
And follow me on my blog to be notified when I publish new articles!
Thank you so much!
