#1 - SAFe is too ...
A common issue around SAFe is that allegedl, people consider that it is ...- Heavy
- Complicated
- Complex
- Restricted
- Restrictive
Regardless of which of these are bothering you, first consider the following: SAFe is a framework intended to aid you on the journey of developing highly complex systems in a dynamic marketplace. If you can do that with a single team, then - by all means, do that. SAFe is not a way of making simple things complicated.
When you are dealing with a complex, adaptive system, then any simple solutions will be snake oil - based on wishful thinking. SAFe does not claim to dissolve the inherent complexity. On the other hand, it reduces the unnecessary complexity induced by legacy organizational structure.
SAFe does become restrictive and constraining when it comes to structure in the same sense that Scrum does. SAFe discourages bloated, inefficient structures without customer value. In SAFe, there is no place for complex reporting processes, time-squandering status meetings or wasteful accounting structures.
SAFe encourages optimizing structure and processes constantly, applying Lean and Agile principles. Many people say that SAFe, at it's core, is really just plain common sense, even "too obvious to be special". Except that too many organizations don't apply common sense - and don't see the obvious.
When you are dealing with a complex, adaptive system, then any simple solutions will be snake oil - based on wishful thinking. SAFe does not claim to dissolve the inherent complexity. On the other hand, it reduces the unnecessary complexity induced by legacy organizational structure.
SAFe does become restrictive and constraining when it comes to structure in the same sense that Scrum does. SAFe discourages bloated, inefficient structures without customer value. In SAFe, there is no place for complex reporting processes, time-squandering status meetings or wasteful accounting structures.
SAFe encourages optimizing structure and processes constantly, applying Lean and Agile principles. Many people say that SAFe, at it's core, is really just plain common sense, even "too obvious to be special". Except that too many organizations don't apply common sense - and don't see the obvious.
#2 It’s just another name for Waterfall
Common arguments include:
SAFe supports the continuous delivery of Working Products, within each PI - within each Sprint - and within each team. SAFe's delivery model is highly inconsistent with a phased model.
The PI is an abstraction layer of an iteration. Unlike a traditional program, there are no phases assigned to Increments. Every Increment results in a Working Product Increment, and at the end of each increment, the "Proceed/Stop" decision is based on inspection of valuable deliverables. Artifacts like documentation or un-integrated code are not considered value.
While SAFe has so-called "Programs", a SAFe Program is not a classic large-scale Waterfall project. A SAFe program is, first and foremost, a larger group of people working together towards a common vision. It does not imply sequential phases or separations of concerns.
SAFe has specific suggestions how to get started and be successful in a very short period of time, the key idea behind SAFe's program structure is this: As organization size increases, non-value added coordination also increases (i.e. anti-scaling). Therefore, SAFe suggests an organization both in terms of structure and process which significantly reduces non value adding coordination.
SAFe does permit you to integrate with a Waterfall organization either on lower or higher levels of abstraction, yet this type of integration suffers from the same maladies as a Scrum team would suffer when being forced into a Waterfall mode of delivery. SAFe intergration with Waterfall is possible, albeit wasteful and extremely risky. Both the waste and risk are endemic to the Waterfall and transferred onto SAFe.
SAFe encourages abolishing Waterfall structures as fast as possible and suggests converting the entire Value Stream towards SAFe in order to minimize the impact of Waterfall practices.
Even when you aren't really scaling, the SAFe values, SAFe principles and SAFe mindset are useful. Of course, you won't be using SAFe structures and processes to solve a non-existant problem. SAFe is a way to approach the problems you already have and it's excruciatingly good at highlighting where they are.
When it comes to "too big", SAFe is probably the framework that has proven to work with the largest organizations of all scaling frameworks. The Value Stream layer, introduced in SAFe4.0, basically allows you to organize thousands of developers working on the same product. If you think you go beyond that, it is more likely that you only think you need so many people because your organization is so ineffective - not because your development challenge is so big.
There is significant danger in modifying/tailoring SAFe: SAFe follows the Shu-Ha-Ri learning principle. At first, do the motions until you understand - then you adjust the practice to get better results - finally, you transcend everything to obtain the same outcome without the initial motion.
For companies new to agile, it is highly recommended to first learn the basics before jumping into modifications. Just like in Karate, you don't go into a Dojo and tell the Sensei "Well, I like this Karate thing - but we need to modify it a bit so it suits my needs" - you need to get a grip on SAFe before meddling with it. The odds that you are modifying something that is actually essential to success increase with lack of understanding.
An expert agilist would definitely approach SAFe differently from a beginner, yet it is often self-proclaimed "experts" that do the darndest things.
SAFe has been proven to work in thousands of companies across the globe, spanning all kinds of industries. While it is possible that your company is such a special case that you just can't make use of SAFe, chances are that in these cases, neither is any other agile framework, including Scrum or Kanban.
Most likely this means that your optimization goals are not compatible with the following common optimization goals: Value, Time-To-Market, Customer Satisfaction, Effectiveness, Learning. In that case, SAFe has nothing to offer.
Some organizations are already so agile that SAFe is a step backwards. Congratulations! You're already in the top 0.1% of your industry! Keep it up. We'd like to learn from you. You may still refer to the vast experiences collected by SAFe to get some ideas and simply grow and improve on what you're doing.
While this implies that it's possible that you have a SAFe implementation without Scrum at the team level, SAFe actively encourages at least trying out Scrum first.
A little more challenging is the topic of "diluting Scrum". There are modifications to Scrum, based on the idea that a team is not fully autonomous when they are merely a component within a complex system. Pure Scrum has nothing to say about the interaction of teams when interests are in conflict. SAFe redefines the Scrum Master as focusing more on the team, accepting that issues within the organization at large might overburden the Scrum Master.
Scrum equally has no suggestions when the product itself is so big that one PO can not both maintain the entire product and be sufficiently available for all teams. SAFe attempts to provide a meaningful way forward, stating that final product decisions are - just like in Scrum - single person (not committee) decisions, effectively de-valuing the PO role as product/value focussed person within the team - putting a PM in charge of what we'd typically call a "real Product Owner".
The principles and values of Scrum are retained. Similar statements would apply when a team chooses to apply Kanban, except that SAFe purposefully considers the roles of Scrum Master/PO vital to team success - so SAFe suggests having PO/SM even when teams use Kanban.
Continuous Delivery is clearly supported by SAFe, as are other XP practices. While SAFe accepts that for some organizations, Continuous Delivery is still a huge stretch, SAFe encourages these companies to set "Be able to deliver any time" as a key goal for value creation.
SAFe equals Big Bang releasing
SAFe is Non-Agile and doesn't support the Agile Manifesto.
The "But it's not agile" guns are quickly pulled and fired, in classic Western Style "Shoot first, ask later".
SAFe acknowledges that large products, such as "The new iPhone" are typically released as major updates, including big and costly upfront marketing and sales activity. At the same time, SAFe encourages the continuous, fast delivery of value both for commercial and innovation reasons.
Regardless of which approach to releasing is suitable for your specific product, SAFe is fine with that. While frameworks like Scrum are completely neutral regarding large-scale effects such as "Super Bowl", SAFe suggests putting major commercial events on a calendar, then planning potential scope around these events to leverage maximum business value. This idea is not conflicting with the continuous and early delivery of value.
In regards to the Agile Manifesto, SAFe emphasizes the Agile Manifesto equally - or even more - than frameworks like Scrum or Kanban. While agility at scale is significantly more complex than team-level agility, SAFe acknowledges that both the values and principles of the Agile Manifesto are valid. A thorough understanding of - and support for - agility is a prerequisite to succeed with SAFe.
A culture that does not support the Agile Values will not succeed with SAFe. Let's just be brutally honest here: That kind of culture will not succeed with agility regardless of framework or approach.
Well, that was round 1 of SAFe misunderstandings. There are more to discuss later.
SAFe does not claim to have all the answers. SAFe is a good way to get started on your journey to Enterprise Scaled Agility, and "Here's something you can try" is better than "Well, you have to find out ..." for many people. After introducing SAFe, you will constantly inspect+adapt to discover better organizational processes and structure.
Think about why you hold specific reservations about SAFe. Maybe the problems are caused by your perception of SAFe, not by SAFe?
- Each PI is a Waterfall
- SAFe is just another PMBOK style waterfall.
- It’s just RUP Reloaded
SAFe supports the continuous delivery of Working Products, within each PI - within each Sprint - and within each team. SAFe's delivery model is highly inconsistent with a phased model.
The PI is an abstraction layer of an iteration. Unlike a traditional program, there are no phases assigned to Increments. Every Increment results in a Working Product Increment, and at the end of each increment, the "Proceed/Stop" decision is based on inspection of valuable deliverables. Artifacts like documentation or un-integrated code are not considered value.
SAFe has specific suggestions how to get started and be successful in a very short period of time, the key idea behind SAFe's program structure is this: As organization size increases, non-value added coordination also increases (i.e. anti-scaling). Therefore, SAFe suggests an organization both in terms of structure and process which significantly reduces non value adding coordination.
SAFe does permit you to integrate with a Waterfall organization either on lower or higher levels of abstraction, yet this type of integration suffers from the same maladies as a Scrum team would suffer when being forced into a Waterfall mode of delivery. SAFe intergration with Waterfall is possible, albeit wasteful and extremely risky. Both the waste and risk are endemic to the Waterfall and transferred onto SAFe.
SAFe encourages abolishing Waterfall structures as fast as possible and suggests converting the entire Value Stream towards SAFe in order to minimize the impact of Waterfall practices.
#3 - SAFe doesn't fit
People are quick to dismiss SAFe before understanding how to fit it into their organization, for example:
- We are too big / too small for SAFe
- SAFe has to be tailored to fit
- We have to modify SAFe so that it works
- SAFe processes do not fit into our organization
Even when you aren't really scaling, the SAFe values, SAFe principles and SAFe mindset are useful. Of course, you won't be using SAFe structures and processes to solve a non-existant problem. SAFe is a way to approach the problems you already have and it's excruciatingly good at highlighting where they are.
When it comes to "too big", SAFe is probably the framework that has proven to work with the largest organizations of all scaling frameworks. The Value Stream layer, introduced in SAFe4.0, basically allows you to organize thousands of developers working on the same product. If you think you go beyond that, it is more likely that you only think you need so many people because your organization is so ineffective - not because your development challenge is so big.
There is significant danger in modifying/tailoring SAFe: SAFe follows the Shu-Ha-Ri learning principle. At first, do the motions until you understand - then you adjust the practice to get better results - finally, you transcend everything to obtain the same outcome without the initial motion.
For companies new to agile, it is highly recommended to first learn the basics before jumping into modifications. Just like in Karate, you don't go into a Dojo and tell the Sensei "Well, I like this Karate thing - but we need to modify it a bit so it suits my needs" - you need to get a grip on SAFe before meddling with it. The odds that you are modifying something that is actually essential to success increase with lack of understanding.
An expert agilist would definitely approach SAFe differently from a beginner, yet it is often self-proclaimed "experts" that do the darndest things.
SAFe has been proven to work in thousands of companies across the globe, spanning all kinds of industries. While it is possible that your company is such a special case that you just can't make use of SAFe, chances are that in these cases, neither is any other agile framework, including Scrum or Kanban.
Most likely this means that your optimization goals are not compatible with the following common optimization goals: Value, Time-To-Market, Customer Satisfaction, Effectiveness, Learning. In that case, SAFe has nothing to offer.
Some organizations are already so agile that SAFe is a step backwards. Congratulations! You're already in the top 0.1% of your industry! Keep it up. We'd like to learn from you. You may still refer to the vast experiences collected by SAFe to get some ideas and simply grow and improve on what you're doing.
#4 - SAFe isn't real Scrum!
Here's some common statements:- SAFe does not include Kanban/Scrum
- SAFe dilutes Scrum/Kanban
- SAFe doesn't support Continuous Delivery
While this implies that it's possible that you have a SAFe implementation without Scrum at the team level, SAFe actively encourages at least trying out Scrum first.
A little more challenging is the topic of "diluting Scrum". There are modifications to Scrum, based on the idea that a team is not fully autonomous when they are merely a component within a complex system. Pure Scrum has nothing to say about the interaction of teams when interests are in conflict. SAFe redefines the Scrum Master as focusing more on the team, accepting that issues within the organization at large might overburden the Scrum Master.
Scrum equally has no suggestions when the product itself is so big that one PO can not both maintain the entire product and be sufficiently available for all teams. SAFe attempts to provide a meaningful way forward, stating that final product decisions are - just like in Scrum - single person (not committee) decisions, effectively de-valuing the PO role as product/value focussed person within the team - putting a PM in charge of what we'd typically call a "real Product Owner".
The principles and values of Scrum are retained. Similar statements would apply when a team chooses to apply Kanban, except that SAFe purposefully considers the roles of Scrum Master/PO vital to team success - so SAFe suggests having PO/SM even when teams use Kanban.
Continuous Delivery is clearly supported by SAFe, as are other XP practices. While SAFe accepts that for some organizations, Continuous Delivery is still a huge stretch, SAFe encourages these companies to set "Be able to deliver any time" as a key goal for value creation.
#5 - SAFe isn't Agile
Some people claim that SAFe does not manifest agility. The arguments are these:The "But it's not agile" guns are quickly pulled and fired, in classic Western Style "Shoot first, ask later".
Regardless of which approach to releasing is suitable for your specific product, SAFe is fine with that. While frameworks like Scrum are completely neutral regarding large-scale effects such as "Super Bowl", SAFe suggests putting major commercial events on a calendar, then planning potential scope around these events to leverage maximum business value. This idea is not conflicting with the continuous and early delivery of value.
In regards to the Agile Manifesto, SAFe emphasizes the Agile Manifesto equally - or even more - than frameworks like Scrum or Kanban. While agility at scale is significantly more complex than team-level agility, SAFe acknowledges that both the values and principles of the Agile Manifesto are valid. A thorough understanding of - and support for - agility is a prerequisite to succeed with SAFe.
A culture that does not support the Agile Values will not succeed with SAFe. Let's just be brutally honest here: That kind of culture will not succeed with agility regardless of framework or approach.
Conclusion
Well, that was round 1 of SAFe misunderstandings. There are more to discuss later.
SAFe does not claim to have all the answers. SAFe is a good way to get started on your journey to Enterprise Scaled Agility, and "Here's something you can try" is better than "Well, you have to find out ..." for many people. After introducing SAFe, you will constantly inspect+adapt to discover better organizational processes and structure.
Think about why you hold specific reservations about SAFe. Maybe the problems are caused by your perception of SAFe, not by SAFe?
No comments:
Post a Comment