Your Framework Sucks
We can learn the art of fierce compassion – redefining strength, deconstructing isolation and renewing a sense of community, practicing letting go of rigid us-vs.-them thinking – while cultivating power and clarity in response to difficult situations. -Sharon Salzberg
Recently I’ve seen a lot of negative comments on social media criticizing SAFe and other scaling frameworks. Some of it can be chalked up to the Agile community’s typical aversion to change (ironic, isn’t it…). You hear it whenever somebody says, “That’s not agile.” That’s just another way of saying, “That’s different.” This isn’t anything new. I remember people used to say the same thing about Kanban when it was first introduced. They’ll probably say it about the next new thing that comes along too. Some of it is the usual competitive “My agile-fu is stronger than your agile-fu.” There are a bunch of agile scaling frameworks now, and curiously, none of them has anything good to say about the others. Despite all that, there are some criticisms that I think are pretty legit. I’d like to address a few of those here.
First, the rollout plans for SAFe and other frameworks seem to be pretty static. That could just be me, after all, but I don’t see a lot of variation in the approaches to rolling out frameworks. It’s often top down, and dictated largely by the management teams or key stakeholders in the organization. I’m not arguing that isn’t the right way to do things, but I am arguing it’s not the only way to do it. The agile community at large has been experimenting with how to introduce agile to groups in a fashion that is more bottom up for a long time. This bottom up approach has many advantages. If we can get the people doing the work to have a voice in how they are organized, then we are much more likely to get their buy-in and engagement with the new organization. Those folks also know more about the work, so they are probably better suited to make key decisions about who works with whom. Bear with me here, because this is some pretty radical stuff. There are folks who are experimenting with self-selecting teams that are making impressive progress. Imagine being able to work on whatever team you like? Amazing.
For example, we should be able to introduce team self-selection into SAFe as one of multiple options for creating release trains. There is nothing about self-selecting teams that breaks or somehow violates the 9 fundamental principles of SAFe. In fact, I might argue that self-selecting teams are perfect for SAFe. I truly believe that they are much more likely to be high performing teams than teams that are selected in a top down fashion by managers. There could even be a hybrid model where the management teams define the capacity – the overall size of the release train according to funding allocation, and the teams self-select to match that capacity. It would be a combination of top down and bottom up.
The other area where I see rather dramatic over-control from the top is with the emphasis on the top down epic-feature-story elaboration. Often this process can be so rigid that teams can feel as though their feet have been nailed to the floor. Everything is so tightly defined by the time that it comes to the team, that the team doesn’t feel like they have any options. All of the key decisions have been made. In a very real sense, if everything has been decided before the team sees it, then the epic-feature-story elaboration process is indistinguishable from waterfall from the teams perspective. It’s especially bad when the teams are asked to commit to delivering those features and stories for a planning increment. Suddenly you have teams wondering what, if anything, they are contributing to the process. There certainly doesn’t feel like there is much room for learning.
I think there is a hybrid approach here where the teams take the epic-feature-story breakdown as inputs for negotiation and conversation, but they don’t commit to them. To me, epics, features, and stories are a useful language or model that product owners use to describe what they think the customer or marketplace wants. Epics, features, and stories are not actual value. They are a description of what we think value might be. They are an input to the team design process, not an output. This is important and probably bears repeating: epics, features, and user stories are an input to the design process, NOT AN OUTPUT. We want teams to commit to outputs. Specifically, something valuable. Software that does something useful is valuable. So we want them to commit to delivering some software that we can use to do something valuable. So we should stop asking teams to commit to the inputs, and instead ask that they commit to outputs. Commit to value. That would cure a whole lot of dysfunctions that arise from asking teams to commit to delivering inputs.
There is a transformation that needs to take place between a request defined by epics-features-stories and the resulting useful software that is produced. This is where the sausage gets made. The team uses features and stories to try and understand in simple terms what is being requested of them. Then they integrate that model with their own understanding of the domain and the working system that they have before them. Even that is an incomplete picture of the world. To really do well, they have to use all of this incomplete information to test their assumptions against the system and the customer to get some feedback. They find unanticipated problems, and they have to have the freedom to change fundamental assumptions in order to arrive at what is hopefully something very useful to the customer. That’s never a given, there are always lots of unknowns, and we have to allow for that.
These are a couple of examples of how we can experiment and play with how the framework actually gets rolled out. There is lots of room for variation – that’s why they call it a framework to begin with. There’s a roadmap for rolling out SAFe. If you are just starting out, that’s probably the best place to begin. However, I think that as experienced practitioners, we need to be exploring many different ways of rolling out SAFe (or whatever your framework of choice happens to be). Not all customers are alike, especially when it comes to scaling agile. We need to be flexible and creative in the manner in which we implement our frameworks. In and of themselves, frameworks provide a set of overlapping ideas that can help us start to deliver value amid the chaos that is often the norm in so many places. However we need to implement those frameworks using all the creativity and imagination at our disposal. This is how we can best serve our customers.