Why Playing it SAFe is Dangerous…
I don't want this post to be directly about SAFe and why it is not the best approach for an Organization to adopt Agile ways of working. For what Agile means and how to bring this into your Organization I would strongly urge to look at the writings of experts like Allen Holub or Jon Smart, both of whom provide excellent, entertaining perspectives
I will say, in general, I am not a fan of SAFe for multiple reasons, but like any model there may be parts that are relevant and helpful to an Organization in its journey. The classic George Box quote of “…all models are wrong, some are useful…” comes to mind!
What I wanted to focus on is the impact that models like SAFe have not necessarily in terms of what they provide as a framework but in terms of what they do to our thinking and cognitive load
Here I would like to to turn to the work of the Team Topologies authors Matt Skelton and Manuel Pais. Team Topologies introduces many useful concepts not least the emphasis on socio-technical design and the need to pay attention to Teams (and individuals) Cognitive load as one important factor in optimizing an organization and how to get things done more effectively and efficiently [the ‘flow’ of work and outcomes]
The Team Topologies approach introduces the concept of different types of Cognitive load that we need to deal with on a day-to-day basis ranging from;
Intrinsic Cognitive Load -the aspects of the task fundamental to the problem space, or to para phrase the knowledge that we need to do our jobs or the task in hand. Although this needs to be ‘maintained’ ideally this should become- as ‘automatic’ as possible; something we can call on as knowledge whenever we need it
Extraneous Cognitive Load - this relates to the environment in which the task is being done. This includes the method, guidance, guardrails and other information that you need to know in order to carry out a task in context
Germane Cognitive Load - this relates to aspects of the task that need special attention for learning or high performance, or to put this another way how to apply the knowledge that you have to the problem in front of you; the ability to think creatively to solve problems and come up with new solutions
…and as Manuel and Matt state in the book we typically want to do three things; minimize intrinsic Cognitive Load, remove as much Extraneous load as Possible and maximize the capacity to apply the knowledge and skills we have through our Germaine Cognitive thought
I really like this simple way to rationalize what is a complex topic!
So what has this got to do with SAFe and other similar, all encompassing methodologies?
Well for me it is the fact they impact organizations’ ability to freely think and consistently keep their focus on how to define, refine and deliver the goals they want to achieve. The methodologies do the opposite of the goal stated previously in terms of optimising our cognitive load profile. SAFe, as an example, provides what is a complex, often prescriptive, approach to follow which not only adds to the Extraneous Cognitive load but significantly also adds to the Intrinsic Cognitive load too. Pretty much across every IT role from Portfolio Manager to Developer, there are new things to learn and new processes and ceremonies that ‘have’ to be followed often at the exclusion of what was understood and practiced before and frequently at the exclusion of why we should be doing in the first place to support the outcome we actually looking for
Now it is not to suggest that all change is bad and learning new things or approaches should be avoided, far from it, however when faced with a complete revolution in how to work it is often overwhelming to the point of removing the vast majority of our capacity to focus on productive thinking and work. If this implementation of the new method lasts for weeks or even months, typically following more of a ‘big bang’ implementation approach (e.g. complete this series of trainings and certifications to begin to work in the new way), it is likely to start to put a larger overheard on our Intrinsic and Extraneous Cognitive capacity. This in itself would be a bad outcome
But, I would argue that methods like SAFe go further and actually begin to take away our ability to think and challenge; to reduce or remove our ability to apply the knowledge and experience we already have. This is not just because we might be overwhelmed with new things to learn in terms of processes but equally because we are taught that there is now a right way of doing something and it is ‘only’ this method or approach that is being shown
Hearing “…but that’s what SAFe says…” when trying to challenge or provide a solution in a debate is very counter productive, frequently frustrating and often demoralizing to say the least. To negate the ability to apply the knowledge and skills you do have, losing many years of experience in the ability to develop and test hypothesis for new ways of doings things between teams of people is highly destructive
Good or bad, any new design and implementation of change needs to be thought through and the options and trade-offs in the design carefully considered. If because of the volume of data that we need to deal with mentally or the accompanying prescriptive nature of the top-down direction we effectively stop thinking and applying our knowledge then this is arguably the worst result we could hope for; we stop being able to focus on the outcome, we constrain our existing knowledge and experience and we effectively waste significant time and money just in order to reduce our ability to think, innovate and improve
So what’s the answer…?
Well whether you choose to use SAFe or another current or future methodology there are perhaps some simple things we can always do to help our Organizations, people and Teams and counter-act the ‘groupthink’ encouraged by the frameworks
Understand and focus on your Goals and Outcomes - to start by looking at what you want to achieve and what ‘good looks like’? To keep in mind the outcomes we want to achieve and how the different parts of the overall system will contribute to these goals. Help the Teams, Products and Portfolios to understand how they fit to the next steps and how they contribute. Worry less about how what you want to achieve fits into a model and more about the alignment and clarity on the outcome; who we are optimizing for and why. In working out how to achieve the goal I would argue is infinitely easier if we know what we want to achieve and why rather than starting with a solution looking for a problem!
Create you own plan that includes the Customer - breaking the delivery into iterations where we can valdiate and learn from quickly is important - intentional design and architecture to support the desired outcome isn’t a dirty word and is needed; it only becomes problematic if we this gets ‘too big’ before we start to deliver and learn. What’s good enough is never easy but if you can link link the approach to learning from perhaps a ‘sample area’ that becomes a reference model for the overall approach, or an ‘architype’ that proves the principle or supports the overall outcome this is often a good way to go. What is always important is that we take the customer / consumer with us on the journey with us and explain what we are doing and why and most importantly what it means for them - what changes they can expect and what benefits this will bring. Try to keep things simple for the customer and not overwhelm them with more change than they can deal with - what we are doing should be something that benefits them after all!
Leverage only what is needed; build on success - without sounding overly simplistic, try and focus on what is delivering the outcomes you are looking for. Look at working on iterations with smaller outputs that can show success and build on that success - valdiate the model and that the key ‘exam questions’, linked to the agreed outcomes are being proved, or at least what is being done is moving us closer to the answer or outcome we are looking for. The trap that large methodologies encourage is that we stop to think if everything is helping us in our goal and are we get distracted ’ticking the boxes’ because that’s what the method requires us to do? Consider adapting the ‘5 whys’ approach to be critical of whether what we are doing is helping us (particularly if we are using a methodology in whole or part), in order to deliver the right outcome in the best way and not distracting us - Lean and Agile!
Runways and dependencies - It is unavoidable that we will have dependencies no matter how much we plan to deliver incremental chunks of work that are independent. We can look to use the intentional design process to understand what these dependencies are along with setting out a ‘runway’ that identifies what needs to be done in a given sequence to enables the work that follows. Of course we’ll always need to adapt as we go, but thinking ahead and understanding how the key parts fit together and impact each other is an important step . Providing we keep getting feedback and learning as we go then there is no contradiction or problem in having an ‘upfront design’, in fact it is essential. What matters is that we are flexible and willing to learn and adapt; to test or design and hypothesis and continue to build what’s needed. Methods like SAFe can be notoriously silent in how things can be implemented and it is important to design and adapt how you are planning to change and learn just as much as what the target state looks like
I don’t want this to sound like a lot of annoying, trite, ‘agile’ wisdom and this is by no means a perfect approach, but maybe this could help us avoid some of the pitfalls of optimising for the ‘means’ rather than the ‘end’ goals and outcomes that we want to achieve!
I’d love to know what you think and what you experience has been?
