“Some say that I should settle down, go slower and not push so hard, so quickly for such transformational change. To them, I say that you misunderstand the size of the problems we face, the strength of the status quo and the urgency of the people’s desire for change.”
– Eliot Spitzer
According to the latest VersionOne State of Agile survey 2018, the most prevalent scaled agile framework in use today is SAFe. Note that I didn’t say it was the most popular framework. I’m not sure that most people love SAFe, but I can say that most people use it. Why don’t people love it? Well, I’m sure there are lots of good reasons:
The framework is very prescriptive, often specifying “best practices” without much discussion of alternatives
The framework is overly dense, incorporating nearly every agile practice ever invented
The framework is designed as a first step for large organizations on their agile journey, but often it is also the last step
Implementations tend to be cookie cutter and not make allowance or provide guidance for change
I’m sure there are many more very good critiques of SAFe. It’s not my purpose to condemn the framework, but rather to highlight some weaknesses that I believe can be easily addressed. My goal is to consider how we can make SAFe, and frankly, many other scaling frameworks, better.
So how can we accomplish that? What can we do to improve this very full, relatively rigid, and somewhat context-free framework? My answer is fairly simple: swap in practices and processes that complement the framework and may provide a better “fit” for our transformation customers. Essentially, I’m arguing for the application of a little creativity. All of the frameworks have a planning process. But there are a lot of ways to do planning. We can vary the estimation practices like story points, WSJF, or #noestimates. We can vary how we prepare for the planning event by using extensive top down review, bottom up conversation, or LeanUX related practices.
The truth is, that we have a whole constellation of different practices that we can swap out within our scaling frameworks depending on the need. This gives us incredible flexibility to help our customers find the “right fit” for where they are at in the moment. This has some important consequences:
For engagements that begin with a very prescriptive bent (which often makes sense when teams are learning something new, think shu-ha-ri), using mixins is a great way to begin down the path of experimentation and continuous improvement
We even have the discretion, once we have learned how the framework works, to try our hand at de-scaling – that is, to remove processes that seem too heavyweight
Mixins give us the creative potential to continue to evolve our scaling frameworks far beyond what their creators may have originally envisioned
Using mixins during a transformation rollout can help us to avoid the cookie cutter implementation phenomenon
All of the practices that I propose as mixins are novel and innovative. Most have proven their value on their own in the agile community. It is the recombination of these ideas with Scaled Agile Frameworks like SAFe that I find so interesting. It feels like something very new. It’s an exciting challenge, are you up for it?
One of my favorite cars that I ever owned was a 1967 Ford Falcon. I bought it for $600 when I was in college. It really wasn’t much of a car. It was a 2 door coupe built on the same frame as the classic Mustang, but without any of those muscle car good looks. It was the kind of car intended to be a hot rod for my grandmother. It had a straight six cylinder motor combined with an automatic transmission that was best described as apathetic. It had all the fundamentals you need in a car: an engine, brakes, doors that open and close, and a horn that went “Beep! Beep!”
I remember the first time I stepped back and looked at it after I bought it and thinking, “Well, I’m going to have to change this right now.” Of course, being a college student I had to do everything on the cheap. So I ran down to the auto parts store and bought a bunch of cans of spray paint. I taped up the windows and the headlights and proceeded to paint the entire car bright canary yellow. Sufferin’ succotash! Was that car ever bright! Unfortunately, so was the car parked right next it (Oops). Then I bought a genuine race car hood scoop. You know, the kind like Mad Max had on the front of his car? Well, I grabbed a drill and bolted that baby right onto the hood (no, not the motor, the hood). That hood scoop didn’t actually do anything but look cool (and act as storage for my friends used beer cans). Then I put some old fat used tires and some moon rims on the wheels and I had a genuine, bonafide, race machine.
Now granted, I really didn’t change the motor at all. And those beer cans in the hood scoop rattled a lot whenever I turned sharply. After all, it was still just grandma’s skinny little straight six. But you can’t argue that I didn’t have one of the most distinctive looking cars in SE Portland at the time. There was something empowering about being able to make any old cheap modification, large and small, just for the fun of it. So I just kept at it. Somehow I only managed to get pulled over by the police once – and that was for driving while simultaneously eating a very large bag of M&Ms. Guilty as charged: it was an “M&M DUI” – Driving Under the Influence of M&Ms. Yes indeed, those were wild days.
I still like to customize things. Whether it’s cars, boats, or my house, I just can’t seem to keep things stock. I guess I need to tweak it a bit to make it mine. Perhaps I need to fine tune things until they fit just right? And so it goes with some of the processes that we use. I don’t think I’ve ever done Scrum the same way twice. And you can rest assured that I’ve never been able to implement a framework without bolting a metaphorical hood scoop on it or otherwise changing it to better fit the needs of the teams.
I don’t really understand how people can refer to any framework as strictly “cookie cutter” or standardized. That just doesn’t really match with my experience. You see, we always have to customize things. No matter how dogmatic we may be, there are difference issues and impediments that beg for us to make small changes. And that’s OK, we need to be able to change things a little bit here and there. There are three reasons I believe that the customization of frameworks is important.
First, sometimes when you look closely at those frameworks you will find that there are multiple practices that can be used in the same place. I’m thinking of the myriad different ways that we can facilitate planning meetings for example. So you have a choice, you can use the stock practice as proscribed in the framework, or you can use a custom variety of your own. It’s kind of like customizing my old Ford Falcon and turning it into a hot rod.
Second, frameworks also have gaps. Again, close inspection of frameworks will reveal gaps in the recommended processes and practices. Not everything is completely spelled out, that’s why they call it a framework to begin with (there are bits that are intentionally left blank). It’s supposed to be skeleton upon which you hang your organizations processes. The processes that are already described are what many might call essential, but they are by no means all of the processes that you can have. You can certainly add more and you can certainly innovate in the way that those additional processes are integrated or combined with the framework. If you want to hang a stained glass window in the rear window of my Falcon, be my guest.
Third, frameworks are intended to serve as the foundation or soil within which the seeds of innovation can take root and grow. Most agile frameworks are all based on the underlying assumption that this is the starting point from which you will evolve. Over time you will either hang more processes off that skeleton or you will change the skeleton itself to better suite your business and technology domain.
It’s only through customizing our frameworks using these tools that we achieve remarkable outcomes. Customization provides alternatives to stock practices that may grow stale over time. Customization can also help us to fill in the gaps in the process that were never anticipated when the framework was created. And finally, customization serves as the seeds of innovation that we plant in our frameworks in the hope of developing exciting new ways of working. We’re here to build hot rods, not clunkers, so it’s time to customize our frameworks.
Agile methods like scrum and XP are very exciting, especially when you are first introduced to them. There is something very common sense about the ideas in them that seems to resonate for a lot of people. I know it was that way for me. I’d looked at a lot of different project management methods before settling on XP (thank you Steve McConnell). A lot of those methods looked interesting, but XP was the first one that just made sense. For a young project manager looking for a new way to do things, it was an easy choice.
Now when you look closely at a method like XP you learn very quickly that it is actually a collection of practices, many of which have been around for a very long time. The thing that makes XP work, is the way that this particular set of practices or, as I like to think of it, this big agile bag full of cats works together. For instance, iterations by themselves have been around for a very long time under a different name: time boxes. Pair programming on the other hand, was a relatively new innovation as far as I know (although not entirely unheard of). And while continuous integration had actually been around in some form or another for a while, it was certainly best articulated and demonstrated by the proponents of XP. On their own I would argue that each of these ideas had plenty of merit, but the real magic happens when you combine them together. Each of these practices, and in XP there were roughly 13 of them, complements and overlaps one or more other practices in the set. So as a whole, you have a system of related ideas that have some redundancy and interconnection. You can see this in Ron Jeffries’ diagram of XP.
Now this gives you a package offering of interrelated ideas that many, including all XP practitioners I’ve ever met, say you need to adopt as a whole. You can’t just pick and choose the bits you like and expect to get great results. Why not? Well, I would go back to the redundancy and interrelated ideas. Let’s suppose for just a minute that you adopted all 13 XP practices, but you found that continuous integration for one reason or another was “too hard” or “not a good cultural fit” or for some other reason wasn’t going to work for your team. What might happen? Well, in all likelihood, in the short term you might not see any immediate effect. In fact, you might find that the team goes a little faster because they aren’t struggling to build continuous integration into their process. But hang on, we’re not done yet. You see there are practices that depend on continuous integration in order to work. For example, test driven development (TDD) and continuous refactoring. TDD relies on CI to give the developers quick feedback on their tests. That can’t happen without CI. So, developers are going to lose feedback on their tests, which means they aren’t going to get as much value from doing the tests in advance…and therefore they aren’t likely to keep doing TDD. Quality may start to suffer. And if they don’t have CI and TDD, then they don’t have the safety net of tests that they need to do continuous refactoring…so they are going to be less likely to try refactoring because it feels too risky. By removing CI we have undermined quality and the resilience of the system we are developing (because we’re no longer refactoring).
The impact of removing practices, especially in a pre-packaged set of methods has some rather insidious consequences. Things don’t immediately fall apart. Instead there is a gradual erosion of benefits that causes a cascade of related and also seemingly unrelated problems. You may still be getting some benefit from the remaining XP practices, but the system is now much more fragile and less resilient. You have removed some of the reinforcing mechanisms from the method that helped insure it is robust. When the team encounters a crisis, some sort of emergency in production where they need rapid turnaround and depend on high feedback, they aren’t prepared. They are slow to respond, introduce more defects and likely to struggle. At which point someone is liable to point out that this process sucks. Congratulations! Of course it does, you made it suck.
This is the reason that adherents of pre-packaged methods tend to sound so religious about the unequivocal adoption of all their practices. You have to adopt all the practices, otherwise you aren’t doing XP, Scrum, Kanban, and so on. I want to pause for a moment, because I don’t think that’s the end of the story.
If we were to stop for a moment and look at development and management practices (agile and otherwise) we might find that there are practices that tend to have similarities that might cause us to group them together. Testing and QA practices like TDD, BDD, and others do share many similarities. Estimation practices like story points, ideal developer days, and others also share similarities. My point is that for any given meme or idea that we have in XP or in agile in general, there are multiple supporting practices that may fit. In addition, some practices are sophisticated enough that adoption can be measured by degree rather than in absolutes (we are 30% toward CI rather than all or nothing). My point is that there are multiple options for many of the key elements of popular frameworks. And even within many of those options there is a matter of the degree of adoption. After all, as so many agile advocates often say, it’s a journey, not a destination. Therefore, if I’m 30% of the way along the path, that must be worth something.
All of this is to say that we can substitute our own practices with some judicious caution. We’re allowed to do that, despite what the more religious might say. In fact, we can mix and match to find the elements that work for us. Now this is really hanging our toes out on the radical edge. Ivar Jacobson has something he calls essential methods. Basically, it is a catalog of development methods that you can combine and recombine to build your own framework. Now, you can still screw up. Remember that the reason that frameworks like XP and scrum have been successful is that they have concepts that are interlocking and support each other. The DIY approach is much riskier (practices may or may not support each other), but for some groups that may be the best way to go.
The important thing is to understand why these frameworks work as well as they do. They are composed of a series of practices that support each other, making them robust in the face of a world full of disruption and challenges. You mess with them at your own risk. Or…you build your own. Just know that you need to understand what you are building. If you do it poorly, it very likely won’t work.
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.
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.