Yes. As the name of the post suggests, we at Practical Agile have chosen not to be involved in SAFe adoptions.
Some may ask: But you are practical Agile and your subtitle is “Agile in your context” isn’t this kind of statement in conflict with your own brand? We think not, and this post will try to explain why.
We are practical Agile
Which means we are not about reading a book or taking a training and then implementing the ideas exactly as they are explained, We are all about helping our customers make the relevant adaptation to fit their own unique organizational system, and we strongly believe that this needs to be done properly, through experimenting, learning and using empirical process control, and not by using someone else’s ideas of how things should be done.
This does not mean not to learn from others, but it also does not mean to adopt something blindly because someone (or many for that matter) thinks it works for them.
We are Agile
And by that we mean we embrace the Agile values and see them as very important foundations to a successful agile adoption, let’s examine the 4 agile values.
“Individuals and interaction Over processes and tool”
For us means that we try to minimize the amount of process prescription as much as possible and encourage people to interact and organizations to learn and gradually create their own unique process. SAFe (while we really assume was not the primary intention) reduces the chance of this learning and discovery process by prescribing too many things, by defining too many roles, which from our experience, in many organization, will end up not really doing a cultural change but a shallow, sometime “fake” change.
“Working software over comprehensive documentation”
We really believe in having real working software, meaning a complete integrated product that is available to be delivered every increment (or even more frequent), because of that we do not support designing the organization around components but having it focused on customer value.
Amongst other things, the guidance of SAFe is to create a complete shippable product every PI, which is in our opinion wrong and increases the time to get feedback regarding the system.
Additionally SAFe defines a “non-value adding” iteration called the IP iteration that is dedicated to innovation and planning, which to us sound like more about documentation than software.
“Customer collaboration over contract negotiation”
When examining SAFe essentials we could not find any guidance regarding customer collaboration, specifically not about teams collaborating with customers, fo that SAFe defines various roles such as “Product Management, System Arch/Eng, and Release Train Engineer” that are the customer’s main point of contact and we could not find a clear directive or even a recommendation for teams to communicate with the customer, we could find a statement that the team PO (another potentially dangerous concept) is “representing the customer to the agile team”.
“Responding to change over following a plan”
Once again, we can find several elements in SAFe that emphasize investing a lot in planning – which from my experience will result in more difficulty to divert from the plan, plus it increases the cost of change. When trying to achieve perfection (even when very hard) we do not think it is a good idea to compromise, we aspire to be able to have real continuous planning, meaning you plan ahead as little as possible (and responsible). Providing guidance to plan for 3 month is not only a compromise but will often result in a motivation to follow the plan, even when it is obsolete.
All of the above does not mean that SAFe is good or bad, it is an explanation of our company’s value and vision and why there is a mismatch between the way we see things and SAFe, and the reason we chose not to be involved in SAFe adoption and prefer a different approach (you know what it is…)