Is SAFe Truly Waterfall? My response.

I was recently provided a link to this article?https://www.dhirubhai.net/pulse/watch-out-waterfall-ahead-truth-safe-pawe?-huryn-/ by Pawe? Huryn

In my review, I found a lot of the references to be taken out of context and manipulated to provide justification and prove a point. I will explain and provide the correct context and reasoning behind my review, but before I do it’s important that my readers understand the challenges in scaling an agile framework for use within a large enterprise.

Enterprise-level organizations are comprised of a strong hierarchy of management layers that have developed over the years to sustain and operate their business at such a large scale. The Agile Manifesto, 12 principles behind it, and frameworks like scrum that developed in line with them were defined and created by developers working within small organizations who never foresaw the application nor support for the application of these frameworks at an enterprise-level. Therefore, Agile frameworks like Scrum keep failing in larger organizations due to the hierarchy. There is a constant push to revert to traditional ways, as management at all layers is not included in the agile process.

For Scrum or similar frameworks to succeed at an enterprise level, there needs to be a change in the operating model to ensure all levels in the hierarchy are involved in the process. To date, the only operating model to be successful at this, while supporting frameworks like scrum, is SAFe.

So, when I review this article, I find there is a lack of understanding, with several points taken out of context. Let’s review them point by point:?

1.?????“Waterfalling the requirements”. Within a small to mid-sized company the PO does not have direct contact with the customer, never mind at an enterprise level.??There are layers of people such as product managers, account managers, and leadership that the PO must talk with sometimes, yet never discuss the requirements directly with the customer. This is touched upon within The Scrum Guide by stating the PO is the voice of the customer, with no other discussion as to how this would work. Within SAFe’s model, they are addressing this omission and streamlining the process to ensure the voice of the actual customer is being heard.

2.?????Backlog Management: In most Agile operating models the team will have their own backlog that pulls from a higher-level backlog. In Nexus, teams create their sprint backlog from a common product backlog, however, in SAFe an ART is formed around a Value Stream which may contain multiple products rather than a single product. Another difference that smaller frameworks do not account for, within an enterprise-level organization a process that delivers value to a customer may contain multiple products to deliver that value, which is less seen in smaller organizations, and is an area where the smaller Agile frameworks fail. Because an ART focusing on a single value stream to a customer must work on several products, the backlogs must be broken down further to align the complexities. But we see the same in the Spotify model where teams work on different products as part of the same value delivery model.?

3.?????Untrustworthy Developers. I had a lot of trouble understanding the point being made on this item as all Agile frameworks have a review where the voice of the customer confirms if the story meets the requirements or not, and approves or rejects the story, as clearly described in The Scrum Guide.??This process in SAFe is adopted from The Scrum Guide at the team level.?

4.?????The article states “In SAFe, there is no time to think about the outcomes. The highest priority is keeping people busy”, SAFe at a team level follows the same approach as standard scrum, even throughout the scale there are multiple opportunities to review, inspect and adapt. One of Safe’s pillars is innovation to support innovation with opportunities provided throughout the framework. Also, in this section, it states, “Plans with “deliverables” extend up to 3 years.”. What product roadmap doesn’t expect to run up to 3 years or more, regardless of which framework is being executed?

5.?????Following a Plan: This section really stood out for me as it is embedded within every agile framework not just SAFe. Standard scrum creates a product roadmap, release plan, and MVP, which is nothing more than a plan and a commitment to achieve this plan. When selecting user stories, what the team agrees to work on when formulating the Sprint backlog is their committed stories, stories that are reviewed and are determined to require more clarification are put back into the backlog and are nothing more than uncommitted. When a team member completes their stories for the sprint they may pull from the backlog and add it to the sprint where the story is accounted for, even though it was not committed.?????

6.?????Abandoning Scrum: “There is neither Scrum Team nor Scrum in SAFe”, I am confused by this especially as I work with many clients coaching scrum teams in a SAFe enterprise. However SAFe doesn’t require Scrum. You can follow other Agile frameworks at the Team level, such as Kanban. Because SAFe is a Lean-Agile Operating Model it provides the support to use Scrum, Kanban or other Agile Frameworks at the team level which can be difficult to understand if one is just reading portions of articles on SAFe and not becoming fully educated on it.??If we compare Agile Frameworks and operating models to a sports game, SAFe would be the Stadium and field where the game is played, and Scrum, Kanban, or XP are the games that can be played on that field.

I have spent half my career working in Project and Program Management and have a strong understanding of Waterfall. With my last 10+ years working within Agile, leading Agile transformations, and becoming a Scaled Agile Program Consultant I can testify that SAFe is NOT Waterfall. Although I will add, in support of the Author, that I can see this is based on an older version of the SAFe framework and there have been many changes and improvements since then, so at the time of their writing, the argument may have held more weight than it does compared to the framework today.

I would like it if Maarten Dalmijn , and Michael Lloyd could comment as I value your input and appreciate your perspectives.