I held a provocatively titled session to explore some of the issues surrounding SAFe, DAD, and other Agile scaling frameworks that prescriptively define the structure in how they work. I personally don’t feel it useful attacking frameworks, but understanding the context around them so that one can judge for themselves whether they will apply or not. The path I took was to explore the problems, then the why we are scaling, then finally the assumptions these hierarchical and rigid frameworks make. I did this through time boxed brain-writing portions and then discussion on the results. This was to eliminate the possibility for undo influence between participants.
We had several people come and go, but my core group was Karen Spencer, Kristen Tavelli, Dave Rooney, Brett Palmer, Susan Strain, Diana Wiliams, Darren Terrell, Sameli Zeid, Patrick Wojtak, and myself of course. Brett in particular stated he found the session useful; he had just completed his SPC and was struggling with some of the rationale behind how to apply it.
Problems created when introducing SAFe (or other hierarchical scaling approach)
The following are the problems folks have seen when implementing these hierarchical approaches. (NOTE: we are talking about actual implementations seen and/or the way the framework is being prescribed to apply.)
- unknown needs for why certain measures or metrics are required – most of the metrics these frameworks seem to roll-up seem to be to ensure that the same items are measured across teams and not necessarily what may be needed for the individual team itself
- these metrics also seem to be used to compare team performance in a negative manner (and thus lead to team’s gaming their metrics to keep from being viewed negatively)
- it also seems to prescribe the same process across all teams (mostly around Scrum rituals)
- often times the organization begins implementing SAFe without executive buy-in, in particular from the business side of the organization
- it tends to make too many decisions upfront with the product management/program level making decisions around how work will be done and not just about the how, sometimes well before any team(s) will begin solving it
- it also removes decisions from the team around cadences and architecture, and constrains what improvements or experiments a team may do
- after getting agile teams to drop formal roles and promote T-shaped people (generalizing specialists); most of these frameworks and SAFe in particular, introduces unneeded roles again
- SAFE seems to focus at driving a release (train – get that damn train off my runway says the aviator!) at the team level; they are still left to simply struggle on their own (in fact there seems no one that they can truly turn to for impediment removal either)
- with all these new roles and early decisions, this introduces unneeded coordination overhead
- it reintroduces big upfront requirements again, sometimes using lighter models, but sometimes favoring back towards heavier ones
- it reinvents Gantt charts with post-its
- for teams starting their implementation of this sort of framework, it begins to force common processes and tools onto teams that may have evolved to a different set
- also when beginning implementation, there seems ot be a lack of communication to the teams why such changes are needed, it just begins to impose them without explaining the rationale behind them
- and there may be some possible unsound assumptions being made as to the need to scale in the first place
Whew! That’s a lot of problems, but there must be a reason for scaling?
Why Are We Scaling? (What do organizations want…?)
So we turned our attention to why we are doing this in the first place. Understanding the reason(s) may help us make more useful decisions on approaches and such. Here’s our take on the why’s organizations we’ve encountered are doing so…
- there’s a silver bullet mentality; there must be a one right way to getting consistent result from all teams
- there is a desire to help large programs adopt Agile across the enterprise with an approach that can be easily visualized
- the above two reasons also seem to be a means for simply trying to organize a large number of teams and the people within them
- for programs with large technical products, it can help them coordinate their activities, dependencies, and constraints
- there may be multiple teams with multiple dependencies
- often ‘programs’ are defined by the organizational structure that already exists or the budget that is provided to fund the work (it’s easier to sell large programs for large budgets that will produce large benefits that than a collection of smaller products that may collectively and more loosely accomplish the same results)
- there is a belief it will remove impediments more easily (remove an impediment for one team will remove it for all teams)
- there is a desire on management’s part to see consistency and predictability across all teams
- and lastly in many Agile approaches, middle managers don’t see where they fit; they feel a loss of power – these hierarchical approaches show where they retain power and control
In particular, we discussed how some of these desires to retain hierarchy for coordination produce results that follow Conway’s Law. The resulting development may have rigid and brittle interfaces.
So lastly we turned our attention to the assumptions these approaches seem to be based on…
- belief that management has limited insight into what teams are doing; our discussion on this revealed two parts to this – management expects information to be pushed to them as opposed to pulling for it and secondly management has a belief all data coming to them should be identical for easy consumption
- a fundamental belief that process is more important; essentially it is process that helps interactions between people
- a belief that this is how one should scale/coordinate Scrum teams and not through simpler mechanisms such as Scrum of Scrums
- along with the organization and budget above, BIG Budgets = Importance = Easy Approval over having to ponder each smaller need/budget request on its merit
- that management believes they will be able to see better productivity and identify where teams need to improve their performance
- there is a fundamental belief that all development work is the same and thus should follow the same process
- it assumes that organizations will customize the approach and not adopt it as-is
- for organizations where they have removed these roles, introducing new roles will be easy (or having people swap from one role to a new one will be easily done)
- it assumes all teams can standardize on a cadence
- it assumes we must manage complexity from a central location; I mentioned that a wonderful book that explores where complexity can be managed in a decentralized fashion is Organizing for Complexity by Niels Pflaeging
- there is a belief that effectiveness is derived via consistency or that efficiency yields effectiveness (or that they are the same)
- the trade space (trade-offs being made) between autonomy and measurement around effectiveness is (are) obvious
- management should be able to continue as-is; as Agile moves out from teams, management should not be expected to change in its role
- the architectural stuff that needs to be done does not equate to business value or is too hard to equate to business value, so we’ll manage it as separate items of work
- and lastly hierarchies are a natural way for people to organize; people coming together for common purpose would naturally choose it as their preferred structure
- one I mentioned at the end was that organizations (management) must start with an end structure in sight and that they don’t need to just evolve to a structure
Sameli also had an item that came up that organizations can easily change their structure to match what SAFe has.
I hope you found what we discussed useful and that it will help guide you in your decisions on whether SAFe is right for you and/or how to customize it. Start with this latter assumptions part to help you avoid the problems that may arise, regardless of whether you use SAFe or a similar approach, how to customize it, or decide on another approach altogether.
I only just came across this, so apologies for the time it took to respond!
It’s tremendously powerful that you’ve created this from actual practise and experience, and that as evidence of risks and problems, it is very much more to be respected than the “It can’t posssibly work” brigade.
I think you’ve collected some great examples of risks and problems that need to be addressed or at the very least guarded against, and most of the experienced practitioners I know and respect are mostly aware of most of them. I can certainly say that most of the problems you identify I would personally be guarding against in any implementation that I’m involved in.
However, I think a number of the underlying Assumptions and “Why”s you’ve identified are false, or oversimplify the problem space. I don’t want to do a point by point, but if I may pull an example or two:
Firstly, I generally guard against absolutes. I think as “most teams should be able to standardise on a cadence” it’s more valid. Secondly, as a practical thing, most teams find one week sprints very difficult, 3 week sprints offer distinct risks in becoming mini-waterfalls (week 1: design, week 2, code, week 3, test) particularly with less experienced teams. So what are you gonna do but end up coalescing around 2 week sprints. Cadence is good, messing with cadence is a smell, so if you start together you should seek to maintain aligned cadence. And again, practically, if you have multiple teams delivering into a system, how else are you going to get system level demos to stakeholders?
However, the most significant assumption of all which you’ve entirely missed is Systems Thinking 101: that we should not seek to optimise each element in a system but rather we should optimise the whole system. If a significant systemic benefit is available at the cost of minor annoyance to sub-systems, then so be it.
If process doesn’t help interactions, then we should stop doing it. Remember the line from the Manifesto: “there is value in the items on the right” However, it is the interactions that matter and SAFe is very clear about that in its guidance. If that’s not happening in practise, then we need to make the guidance stronger: doing it badly is not necessarily a criticism of the “it” that we are doing.
As I said, I don’t want to rain on the whole article, because I think it’s very helpful to both practitioners and methodologists. If this is how SAFe is being practised, then we need to address practitioner training and guidance. And sometimes, to challenge customer organisations who will use anything to support their existing culture and assumptions. Which is what I do certainly in my practise.
Thanks for writing, I appreciate you taking time to reply.
However, I’m not going to address any of your comments, simply because these are not my thoughts, but the collective thoughts of about 8-10 agile coaches that have been in the industry for a very long time. These items were created using a divergent thinking exercise so that people were free to contemplate all aspects they had seen. I actually think it a slight bit insulting to say that we are missing systems thinking given at least a couple of us are very deeply versed in Cynefin, causal loops, etc. and not just simpler RCA of value stream issues.
A good number of us had been through SAFe training (as well as having knowledge of other scaling approaches), so it was also not like there was an ignorant audience.
Perhaps you didn’t mean to come across this way… Then my observation would be one that you missed had multiple people providing insights. In general, it appears you are thinking this is a singular opinion from a SAFe basher; that’s off-target.
I appreciate that you took the time to reply. I am 100% working on the assumption that your aim is to make SAFe *better* (rather than the SAFe-bashers’ objective of killing it just to watch it die). And believe me, if I thought that you were a lone basher (or even a group of bashers), this would be a very different conversation.
And I do very much understand that it was the view of a number of practitioners who have been through SAFe training and accept that there is a great deal of experience that went into this reflection.
My Deming senses are strongly warning me that if an experienced group of people have misunderstood some SAFe fundamentals (and my reading of your writeup is that it did), it’s not a lack of experience or knowledge in the people, but a systemic fault in SAFe’s training and communication.
As the original said: “assumptions these approaches seem to be based on” – I know that a good number of those assumptions are not those that SAFe said. But if that’s the case, then the SAFe community needs to be better at communicating its assumptions and correcting where misassumptions have been allowed to develop. Some of these become much clearer when you see SAFe in practise, but that doesn’t excuse problems with the training one bit.
So, I’m not arguing that your session or its participants was in any way ignorant; simply that we (as a SAFe leadership community) have served you badly. And I absolutely want to take your concerns seriously.
So here’s my commitment: Next week is the SAFe Leadership Retreat: the first time the community has actually met face to face.
I will be bringing this write-up to that event as an input, with a strong argument to use it in the intended spirit of reflection and improvement.
Thanks for the clarification Martin; one of the folk in attendance had recently gotten his SPC, and he mentioned that he wished the assumptions upon which SAFe is founded on had been articulated. So it would be wonderful for you to help the community better; personally I am framework agnostic. I’ll apply principles and concepts from anywhere I find them and I actually have read much of the original works that SAFe is based on and find them more useful.
Cheers and thanks for taking the time respond/clarify.