Popular Post
-
![Agilemania Blog]()
What is the Definition of Done (DOD) in S...
Apr 5th 2021 - BY Satyajit Gantayat
-
![Agilemania Blog]()
Our Scrum Master Holds the Certification ...
Jun 2nd 2020 - BY Sumeet Madan
-
![Agilemania Blog]()
Agile assessment metrics for organization
Aug 3rd 2016 - BY
- Satyajit Gantayat
- Mar 24th 2021
There has been some amount of criticism about SAFe. Some Agile experts are not hard-core fans of SAFe. They say there are hundreds of pages, hours of videos, several different training courses, and more. And this makes SAFe more complicated, bureaucratic than the Agile manifesto recommends. They also have this opinion that SAFe is so heavy, maybe it is not Agile at all.
Let us dig deeper
Most of us started our Agile journey with one framework, and that is Scrum. Scrum is simple to understand with some immutable principles & guidelines. It is a lightweight framework suitable for small self-managed teams. For a long period, our idea of Agile was only Scrum.When more and more organizations and teams adopted Agile, it required scaling in a big way. The entire organization had to be in the process, not just a few self-managed teams.
That's when SAFe came to the party. It provided us with a unique framework and guidelines for the entire organization, including the chief executives, to be part of the process. It is for large-scale software development teams of 50-125 people on multiple projects but wants to still adopt the best Agile practices, despite their size. When the scaling was done for the entire organization, it needed more complex processes and guidelines for obvious reasons. It meant having multiple readiness meetings, planning meetings, checklists, etc. This was perhaps overwhelming for people. And probably that is the reason to be perceived that SAFe is not Agile.
Let us look at some of the Agile principles and how they are embedded in SAFe
- Individual interactions over Processes and Tools :- If you look at the even basic configuration of SAFe, i.e., Essential SAFe big picture looks complex showcasing the different roles involved, frameworks like Scrum, XP, Kanban, core competencies. So, the perception is made that SAFe is process heavy. The foundational unit in SAFe is the Agile team, with the option to use Scrum, XP, or Kanban. SAFe also adds additional interaction events to ensure collaboration happens across the teams and not just within the agile teams aligned to a common goal and work with a synchronized cadence.
- Working Software over Comprehensive Documentation :- SAFe reemphasizes and uses working software as the means of progress towards achieving the objectives. System Demo and PI Demo confirm this theory.
- Customer Collaboration over Contract Negotiation :- SAFe supports and has built-in events to increase Customer Collaboration. The roles like Product Owner, Product and Solution Management, and the agile teams collaborate with the Customers to develop and deliver products or solutions. Also, "SAFe Managed-Investment Contracts" provides an approach to deal with how organizations engage suppliers, which is more in line with agile ways of working.
- Responding to Change over following a plan :- One of the worries people dislike SAFe might want to point out is how SAFe deals with the business changes, as the common pattern for a PI (Program Increment) is a time box of 4 to 5 sprints. The ability to change when required is built-in SAFe. It helps to balance with the organization's need to run the business. We cannot run a business with a vision, roadmap, or a plan that is limited to two weeks.
Why the perception of SAFe not being Agile?
Layers of Process: One viewpoint is that SAFe adds layers of process to product development that is not required.For example, Program Increment Planning (PI) is a formalized process by which all teams plan out and discuss their deliverables for the next quarter and align with all other groups. It is a formal meeting that takes place for several days. It may appear good on its face because communication like this is a good thing, as is the planning and understanding resulting from it. But the process by which it is getting achieved makes it overly troublesome in practice and takes away a team's agility both by forcing the set meetings at the set time and locking in many of the commitments of those meetings with little wiggle room after the fact.
Layers of Management: The pundits also say that SAFe also adds (or keeps) management layers throughout the development process, starting from the Development Teams to RTEs to Epic Owners and beyond. The many layers of management reflect the many layers of process, confusing the overall workflow. While this may look incredibly appealing to managers, centralizing a lot of control at each level, the reality of having so many hands involved is often unsettling, and slowdowns as a lot of people are involved in the process. Each group may have different ways of doing things.
For the above 2 points, let's be honest here – typical Agile enterprise transformations are complicated! It stands to reason that most enterprises will need a reasonably large framework to leverage when seeking full enterprise agility. Designed specifically for large enterprise, SAFe addresses the critical enterprise-level challenges such as:
- How business strategy is getting translated into executable actions at the development team level
- How to ensure seamless collaboration between IT and business
- The lean economics
- Funding
- Pull-based model of bringing the work to persistent teams
- Consistent estimation approaches across all teams
Also, having agility means being able to shift priority or feature to deliver the outcomes better. It allows teams to learn from their experiments and then make adjustments as they go. Does SAFe allow this? The pundits ask.
Now, you could still have a cross-functional, self-managed team at the Team level. The iteration starts with a planning meeting where the team decides what user stories they can deliver by the end of the iteration. Each day, the team discusses their progress and demos to the Product Owner at the end. It is to ensure they have delivered what is needed. They then get together to retrospect where they can improve for the next iteration before starting the cycle again with a new Planning meeting. All of this under the guidance of a Scrum Master who makes sure the team works smoothly.
In the context of SAFe®, you have multiple Agile teams working independently but in sync. By implication, all teams need to have the same Sprint start date, end date, and duration. This is a key tenet of the SAFe® framework and is referred to as 'Develop in Cadence' in the big picture. Thereby, the basic atom comprising the SAFe® molecule is a Scrum team. The aggregated increment of multiple Scrum teams is the 'feature' planned and agreed to be released with the Product Owner (PO) beforehand.
Too many templates: Some say there are too many templates, reports prescribed in SAFe. Does it stick to the Agile principles? While training and coaching teams on Scrum or Kanban, we often come across people who ask if we have any ready templates that they can use. For every development process, Scrum has given the independence to the teams to use whatever suits them. But, teams often look for something to begin with. What SAFe has done is to provide us with all the templates that may require to kick-start. You are free to customize or create your own as you see fit for your teams.
So, Is SAFe® Agile?
The Agile manifesto at no place mentions the ideal team size for the adherence of its principles. Hence, it would be argumentative to state that delivery in agile cannot scale. Also, the principles do not state 'how' to practice Agile going over the Agile manifesto. Nor do they recommend any best practices. Agile principles guide towards the end goal. They can be taken to scale, encompassing bigger numbers of representatives to collaborate creatively to achieve a common goal.SAFe is a fantastic tool for managing large-scale programs consisting of multiple teams working on large epics. It does have some unusual terms. But the terms map to common-sense ideas, and their language is easy to adopt. Scrum patterns at the team level roll up into the program level and somewhat to the portfolio level. Teams that have already mastered Scrum have an easier time adopting SAFe.
SAFe's top-level diagram is incredibly neat and shows every nook and cranny of a robust framework. Some ideas might bother me in SAFe, and I tend to adjust them, but the overall framework is strong, well planned, and easy to follow.
SAFe might not be the ONLY solution to scale. There could be other scaling frameworks that might better work for your organization. No matter which framework you choose, Agile remains an inert, lifeless set of ceremonies without an Agile mindset. The real question should be, is your Organization Ready for an Agile mindset? Are your executives, managers ready to unlearn the old patterns of management behavior? Suppose everyone in the organization was to understand and practice what the Agile manifesto recommends. In that case, the organization might very slowly evolve to the effectiveness that real Agile provides. Remember, it is a journey, and no framework solves the problem, and people do.
Find Our Upcoming Trainings
Satyajit Gantayat
Satyajit Gantayat is an Agile Coach and a SAFe Program Consultant with more than 20 years of experience in Agile Transformation
Sign up for Agilemania Newsletter
Stay updated with the latest Agile & Scrum trends.
Popular Post
-
![Agilemania Blog]()
What is the Definition of Done (DOD) in S...
Apr 5th 2021 - BY Satyajit Gantayat
-
![Agilemania Blog]()
Our Scrum Master Holds the Certification ...
Jun 2nd 2020 - BY Sumeet Madan
-
![Agilemania Blog]()
Agile assessment metrics for organization
Aug 3rd 2016 - BY
Agilemania is a group of passionate Lean-Agile-DevOps consultants and trainers focused on delivering measurable, sustainable results for our clients.
Connect with us on Social Media
Knowledge Area
Certified Partners
Agilemania Technologies Private Limited © 2024 All rights reserved.
