This pandemic is creating both short-term and long-term changes in the way we behave in groups. The most obvious change is that remote meetings from home are becoming the primary form of communication. For most agilists this represents a conflict, because our stated preference for 20 years has been face-to-face communication. That’s just not going to happen now, no matter what your preference. Using remote tools like Zoom, Teams and others will be the new default for the foreseeable future, like it or not. However, there is another change taking place that’s not quite as obvious, but still important: online work tracking tools.
As a consultant prior to the COVID crisis, my preference always leaned toward using physical task boards rather than electronic ones. There is something magical about the tangible nature of a physical task board that leads to better conversations and interactions. A wall full of little yellow stickies just sets my heart a-flutter. Online tools are full of extraneous detail. They have icons, text fields, bells and whistles that often get in the way of productive and useful interaction.
Don’t get me wrong, deep down I’m a tools guy. I’ve helped sell them for many years. I know online tools very well. But none of them can beat the simplicity and elegance of a sharpie and a stack of post-it notes. Let’s face it, by the time you are done logging into your online tool, I’ve already built a physical board from scratch and begun organizing the work for the day. Physical is faster. No contest.
Guess what? All that has changed now. With everyone working from home we are all going to need some sort of electronic work tracking tool. Post-it notes and stickies are like, so totally 2019. Electronic task boards are going to become the standard. You better get to lovin’ JIRA, Trello, Azure DevOps, Rally (or whatever your favorite tool is), because it’s here to stay. The only effective way to track work with everyone at home is using an online system. Period. The only place you are going to find post-it notes is on your refrigerator. I’m selling my stock in 3M. Just for fun, I’m going to keep some of my post-it notes in a box to show to my grand-kids, “Back in my day, we used to use these things to organize how we worked…”
As a young man my father would take me deer hunting from time to time. Both of us tend to be walkers. We cover a lot of ground when we are hunting. It means walking for miles and miles every day in hopes of catching a glimpse of a deer. Usually it’s a glimpse of the animal’s hind end as it was running away. The funny thing is, my dad used to share an observation, “Some of the best hunters I ever met would find a stump, sit down next to it, and take a nap.”
To an energetic young man like myself, while I could understand the point of this observation intellectually, it did nothing to dissuade me from walking every hill, valley and river in a 10 mile radius. Call it a restless personality, or perhaps a compelling drive, but regardless I was out there walking.
Of course as I traipsed along, gun on one shoulder, I couldn’t help but notice that I made quite a racket as I crashed through the brush. It’s hard to be sneaky when you are wearing a big fat pair of vibram-soled hiking boots. Add to that the many layers of clothing to protect from the winter weather, and I loudly swished my way through forest like an industrial street sweeper.
In hindsight, it was no wonder that as I moved through the forest, everything around me would cry out in alarm and go silent. I really should have been wearing a sandwich board that read, “Predator” as I blundered haplessly through the undergrowth. It would have been honest, if not helping me any.
So it should come as no surprise at this point in the story if I reveal that I didn’t see deer very often while on these long hikes. I was telegraphing my presence five miles out, so any deer that might have been around were long gone by the time that I got there. I was scaring them off a long time before I ever had a chance to see them.
To put it in the terms of my friend Willem Larsen, my zone of disruption was much larger than my zone of perception. As I stumbled, tripped, crunched and sometimes stank my way across the outdoor landscape I was creating a zone of disruption that was traveling around me in a bubble. The diameter of that bubble was probably the distance that a typical sound would carry in the woods – perhaps a couple hundred yards or more. Unfortunately, my zone of perception is quite a bit smaller. In the woods, and depending on the cover, I’m likely to only be able to see things that are 25 to 50 yards away – on a good day. And let’s forget about other perceptions like hearing, because I’m already making such a racket myself that I can’t hear a damn thing.
Now I’m making fun of myself a little bit. But try tiptoeing through that fall pile of leaves in the front yard and you’ll get a sense of what I’m talking about. It’s nearly impossible to do quietly – at least for most of us. So there is some real wisdom in that idea of sitting down next to a stump for a little snooze.
Now if you spend some time outdoors violating the personal space of animals like I do, then you might begin to see some patterns. There is the solo town crier who announces your appearance on the scene (Usually a Blue Jay in my case – they hate me). There might be a whole family of quail that starts to chatter off to one side in a semi-circle, peering at me like gophers from the brush. I think I’ve seen them all. They’ve certainly seen me – that much is for certain.
It may surprise you to learn that I’ve seen many of the same patterns in the office as a consultant. When I show up at the office for the first time, the flock often starts tweeting. As the new guy, the agile consultant, I initially cast quite a large zone of disruption. I also tend to walk a lot when consulting – meeting new people and getting the lay of the land. I see many of the predatory patterns that you might find in the wild, also present in the corporate office.
Just watch what happens when an executive travels through the cubicle farm. Often there is a noticeable tunnel of silence that surrounds them as they move through the cubes. The manager is the predator, and the subordinates are the prey – trying to avoid notice.
Have you ever been in a meeting where someone you are talking to suddenly goes silent and looks over your shoulder in alarm? Unfortunately I have (I really should have shut up). That’s the collective group reacting to the zone of disruption that is cast by a significant stakeholder. The CEO is in the building. The alerts have been raised. Cover up that ESPN hi-light reel, quick!
If I were just mocking executives and managers, this would be fun, but the implications are broader than that. Far broader. One of the founding principles of the lean movement has been to “Go to the Gemba” or “Go and See.” All too often managers end up being relatively isolated in their offices and lose sight of the actual work going on the shop floor (where ever that may be). The cure for that problem is to get them out of their offices and take them to see the action on the shop floor. The problem of course is that pesky zone of disruption.
You see, we would like to observe the worker in their native environment as if we weren’t there. We are looking for an honest view of how the work is going. Unfortunately, as soon as they perceive you, the gig is up and their behavior will change. Call it the zone of disruption, or observation bias, the end result is the same – your presence distorts the work being done.
The key is to find constructive ways for us to extend the zone of our perception beyond the zone of our disturbance. This is where I go back to what my father suggested, “Some of the best hunters I ever met would find a stump and sit down next to it and take a nap.”
I’ve noticed a phenomenon that happens to me when whenever I go on a hunting trip (or anyplace in the wild). When I leave my home in suburbia and adventure out into the wilderness, I have a hard time seeing animals. That’s probably because at least initially, I’m finely attuned to the threats and elements in my environment. In my “city boy” case, I recognize cars, pedestrians, and stop signs quite adeptly. I’m highly tuned to see such things every day. It’s part of surviving in my city environment. So I guess it should come as no surprise that I struggle to see new patterns (animals on a hillside) during my first few days on a trip into the wilderness. The good news is that I adapt very quickly. I’ve noticed by about the third day out, it’s like the animals suddenly pop out of the landscape. They were always there of course, I just needed to adjust my patterns to see them. I don’t really do anything, but my brain adapts in way or another.
This pattern matching that I’m describing is a means of effectively expanding my zone of perception. As I adapt, I can see and hear more. One important conclusion here is that we may have to allow some time to elapse when we go into a new environment. We need to give ourselves the time to begin seeing the new patterns. Once again, my father’s wisdom comes into play. A couple of days sitting next to a stump does remarkable things to improve my perspicacity.
If we take this back to the office, what we find is a similar set of patterns at play. Whenever I come into a new office environment as a consultant I’m often bombarded with unfamiliar acronyms and phrases. Initially, most of them go right over my head. Until I become familiar with the language I’m lost in a sea of unfamiliar terminology. Movement patterns are alien to me because I don’t know where people are coming from or going to. I don’t know the terrain. I’m operating with a set of patterns that don’t fit in my new environment.
So how do I adapt to this new environment. First, as I mentioned before, it takes time. I can’t rush it. I need to learn the acronyms and start to get the “lay of the land.” I also have to focus on fostering a lot of curiosity within myself. What is that word? What did they just say? Did what that person just said make any sense? It takes a strong sense of peripheral awareness to absorb all of these inputs and filter through them. I find it exhausting.
Did I mention naps? Maybe I’m getting old, but I think I’m serious. Worst case, you get a little much needed rest. Best case, they forget you are there and continue with their work. Truly worst case scenario: you wake up with a sharpie mustache painted on your face. The point is, you minimize your zone of disruption so that your zone of perception can extend beyond it. So just sit there and don’t move. Relax, it’s going to take a while. And wait for something to happen. This is how you can see how things really work on the floor.
Show up for your nap a couple of days in a row and you really might start to get a real sense for how things work. This is a rich source of information about how things really work in your organization, and it can serve as the starting point for meaningful improvement based on how things really are. The Japanese have a phrase for it: they call it going to the Gemba.
Maybe it’s all the sticky notes and the heady odor of sharpies…
The People – We attract an incredibly diverse audience. I’m not really sure why, but I love it. Lawyers, software geeks, musicians, managers, agilists, and executives. There are a wide range of people with very different interests that find this conference invigorating.
The Sophistication – People are often surprised at the esoteric topics that come up. There is a very high standard of quality to the conversations that take place. Previous attendees have often remarked that the topics were sophisticated and remarkably accessible. I guess that when you have the right people, good things happen.
The Format – Open space enables people to have the conversations that they need to have. Perhaps that explains why people are so satisfied with the Agile Management Northwest experience. If you haven’t tried it before you owe it to yourself to join us and give it a spin.
I just got done introducing another group to the the idea of agile mix-ins. The conversation was a lot of fun. There were a few takeaways for me that I think made the conversation particularly interesting: When it comes to applying mix-ins, you control how much or how little you do, and you also work within the context of the organization.
Let me back that up a little bit. First, before you try and apply mix-ins, I think it’s important to have established a baseline of working practices. This means that if you have just rolled out SAFe, for example, you should probably give yourself a PI or two to really establish a baseline of performance before trying to muck with the system. Otherwise, you just run the risk of creating a never-ending storm of change. That won’t serve you well. So allow yourself to establish a baseline before introducing a lot of new changes.
Second, Scale the change to the level of of organizational permission or tolerance that you believe exists. In other words, if the management team isn’t really on board with the change, then you probably won’t be able to introduce it much farther than the team itself. On the other hand, if the management team does buy in, then you can apply more global change at the program or portfolio levels. It’s a judgement call. Scale your efforts accordingly.
What if you were asked to put risk into some sort of framework in a scaled agile system? How would that work? Well, in many cases, you might start with an existing framework. let’s take SAFe for example, the answer might be that we do roaming in PI planning. So as far as most folks are concerned, all risk is taken care of there. That’s it. That’s all we do for risk. The problem is that in many organizations that are audited for risk management that doesn’t even come close to what an auditor is looking for.
Why is that? Well, if we look at the rules that many large companies have to operate under, they were written on stone tablets with a chisel sometime back in the 1980’s. Those rules typically specify that an organization should use risk management practices that were originally defined by project management practices at the time, long before agile was commonly accepted.
Now there’s nothing wrong with risk management per se. It’s really just a fact of life. All projects and products have risk. The question is, are the risk management practices managed in a lightweight and iterative fashion? Those risk management methods from the 1980s are typically heavyweight, if not outright overweight, and require a great deal of overhead and centralized management which I’m not sure anyone wants to do. So if you’re going to provide a system of risk management for a company that has to deal with compliance and that has to deal with auditors, then you’re going to have to put together a system that manages risk, tracks risk, and insure that risk is not idly disposed of, thrown away, or magically disappears. Risk needs to be taken seriously as a first-class artifact and a first-class citizen in these contexts. If you are a smaller company, if you don’t have to deal with audit and compliance, then there’s no reason we would ever do these sorts of things. However, if you are in a financially regulated or government regulated business like healthcare or financial services, then it’s very likely at some point that you will find yourself in a situation where you are asked to show a structured set of risk management practices that are used and have controls so that they can be validated within your organization. The question is, what do you do then?
I’ve got a question: Where do you keep your risks? If you’re doing a project of any significance you have risks, right? That just comes with the territory. Anything that is significantly challenging or meaningful has very likely got some risk associated with it. And let’s also clarify that we’re asking about agile teams. Because we all know that traditional waterfall teams would have some sort of risk register. Risk is just built-in to the waterfall model, so we don’t need to bother those folks.
But if you are an agile team, where do you keep your risks? I’m not trying to be deep about this. Simply put, if I asked, could you show me your current risks? Yes or no? Most agile teams that I ask this question say “No.” Some tell me that they ROAM their risks once a quarter. That’s nice, but looking at risk for 30 minutes every quarter hardly qualifies as effective risk management. And then guess what I ask? Where do you keep those risks you ROAMed in your last PI planning? Uh…we didn’t.
So where are your risks? Now this is the point where some people might get defensive and say that risk management is build into the agile process (insert your flavor here). To which my answer is, if risk management is built in to your process then it should be trivial to show them to me. To that, they answer that risks are always resolved immediately rather than waiting in large batches. OK, there are certainly some risks that are trivial to resolve, but there are many risks that are long term and require more than a little effort to manage. What about those risks? Can you show me those risks? No? Huh.
So what do you do with your risks? If you own them how do you know it? If I asked you what risks do you have today, could you show me?
Recently I put on a public Leading SAFe training. This wasn’t your typical training, however. In collaboration with Ron Quartel, we tacked on an extra day to discuss FAST Agile. Now if SAFe is an example of a scaling framework, FAST Agile is perhaps a good example of what you might call a de-scaling framework. FAST uses an open space style of organization to provide only the most bare bones structure and guidance. It’s really quite elegant in its simplicity.
Ron and I had both been inspired by the ideas of mix-ins – processes and practices that we can mix and match together. So, it was with that in mind that we thought putting on a combined training class would be interesting. First teach SAFe, then turn around and teach a competing framework. Then compare and contrast. Well, as it turns out, the combination was quite brilliant.
As I taught the two days of Leading SAFe training, the class built up the framework from teams, to programs, to solutions, to portfolios. Learning the roles and processes of each. By the end of the second day, I was exhausted but happy (as usual). Then Ron stepped in and proceeded to teach FAST Agile on day 3. In essence, he took everything I had taught them and tore it all down. The focus was on simplicity and self-organization. The class was totally into it – questions flew fast and furious. Everyone was fully engaged.
The contrast between the two frameworks was stark, and it raised many questions for both Ron and I. You see, I wasn’t there to sell anyone on SAFe. Don’t get me wrong, I like the framework, and I enjoy the training a lot, but I don’t give a damn whether or not you decide to adopt it. What I really care about is that you make an informed decision based on what I hope is the deepest possible understanding of the options. If you understand the values, principles and practices deeply, then you will choose to implement what is best for you and your organization. There is a tremendous amount of nuance and subtlety to the art of organizational change (that’s probably why I like it so much), so I believe that the ability to not only adopt ideas, but also to be critical of them is important.
The act of building up the framework and subsequently tearing it down again felt like a very powerful learning experience. It went beyond rote learning. Not only do we ask, “Why would you adopt this?” We also ask, “Why wouldn’t you adopt this?” That requires us to understand the ideas from different perspectives. People stayed after class each day debating the ideas for over an hour each evening. That’s when you know you’ve really got them thinking. I’m looking forward to doing it again.
“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
The Challenge
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.
Recently, at conferences, in social media, and even informal gatherings, I’ve heard statements along the lines of “[X] scaling approach is absolutely not agile for [Y] reason.” I use the word approach to avoid the question of whether we are talking about a framework or a methodology. I really don’t care about that distinction and much of the subtlety that lies there is beyond me.
Admittedly, there is a long and rich history of critiquing each others ideas in the agile community. Some examples include:
XP vs Scrum
Kanban vs Scrum
Lean vs Agile
To my knowledge, none of these debates has ever really reached any sort of meaningful conclusion. In fact, the more I watch (and even sometimes participate in) these debates, the more I feel like they are mostly a reflection of a sort of core philosophy. What I mean, is that there seem to be some common starting points or assumptions that characterize how people approach these debates.
Let me give you an example. Let’s take SenseMaking and the Cynefin framework. We can use a tool like Cynefin to help us navigate important decisions based on the assessment of contextual complexity. The beauty of this system is that you can use it anywhere. It doesn’t matter whether you are agile or not. Cynefin is simply used to help assess and navigate the environment of simple, complicated, complex and the chaotic. What decisions you make within each context will lead you to healthy outcomes. With Cynefin, you can start with absolutely no framework or required processes at all. In essence, you are building from scratch, and evolving only as necessary. Frankly it’s a beautiful and elegant system. Conceptually, it’s founded on the notion of sensing your environment and making decisions based on what you uncover. It’s a radically empirical process that starts wherever you may be. There is no default starting point for applying Cynefin. You simply use it to help you grow from wherever you are.
The interesting thing is that Cynefin isn’t the only framework that uses this “start wherever they are” approach. Kanban is also very minimalist in its rules. In fact, Kanban usually starts by simply making the existing process visible. You don’t need to change your process at all, just make it so that everyone can see it. Starting from there, the Kanban approach recommends that we consider applying WIP limits and working to understand the constraints of the flow through the system. There are no pre-defined required processes. You don’t have to do standup. You don’t have to hold retrospectives. You basically start Kanban from scratch and add those elements wherever they make the most sense. You build your agile process from scratch based on the feedback you get from making the process visible. Again, it’s a very elegant and powerful system, that’s founded on the notion of visibility (or transparency) and allows you to evolve however makes sense for your environment.
So I see both Cynefin and Kanban as sharing some important conceptual roots (while each is very unique). Both methods provide us feedback to help make good decisions in whatever context we may be working. Both also make absolutely no assumptions about what the starting point may be. You could start with a very rigid, waterfall style, process. Alternatively, you could be using Scrum. Neither Cynefin, nor Kanban care about where you start. In fact, what they really care about is not blindly applying process without some sort of feedback. So I think of Cynefin and Kanban as the “build it from scratch” or “consider context first” methods. Actually, I really like to think of these as the Buckaroo Banzai methods, you know, “Wherever you go…there you are.”
Now this also implies that you are really committed to this learning journey, with all of its joys, discovery, false starts and dead ends. Building your process from the ground up is not for the tentative or the faint of heart. Why do we have to go through all of this learning pain and discovery, when others seem to have found some practices that seem to work? Well, the argument, and it is a very valid one, is that you need to discover what works for you in your context. Trying to apply solutions that may have worked well in other places often leads to disappointment. In the Toyota way, Toichi Ohno warns us of exactly this. If you want to build a world class process, you can’t rent it. You need to build it and find out what works for you.
But what if we really could rent our process? Wouldn’t that save a lot of time and wasted effort? Let’s face it, this is business, not rocket surgery. We can’t all be so unique that we have to waste time rediscovering the wheel. Let’s take a look at another very large branch on the agile tree: approaches based on starting with a predefined set of practices or processes like Scrum, or XP.
Scrum is based on a very fundamental set of practices that creates the infrastructure (or framework or method) for continuous delivery and improvement of small units of work. Depending on who you ask, XP and scrum came into being around the same time. As I remember it, XP was the first to really land hard on a required set of practices that defined the process as truly being XP. These twelve practices were non-negotiable. You had to do them, and if you didn’t, well, then you weren’t doing XP. You’re probably familiar with many of these practices. They are foundational practices like pair programming, continuous integration, test driven development, and so on. Part of the reason for requiring these practices was that they supported each other. It’s hard to do continuous integration without some form of test driven development. The two together are kind of a magical combination – they help reinforce each other. Often, what we see happen in the real world, is that teams will struggle with and perhaps drop practices. When that happens, keeping the other XP practices working gets harder.
Scrum does something similar, but different. Scrum has a default set of non-technical practices that are required. You must have sprint planning, daily stand-ups, and sprint retrospectives. That’s non-negotiable. To do otherwise is to do “Scrum, but…” and to be mocked mercilessly by your peers. Both scrum and XP could be loosely described as having a default set of “best practices” that are required in order to use the framework to its best advantage. Now I personally hate the term “best practice” but that’s exactly what they are doing. We’ve identified the best, minimal, set of practices that you must use as a starting point, no matter what your context is. It’s a package deal and we defer to the wisdom in the package. Unlike Cynefin or Kanban, you have a very well defined starting point, and you aren’t given the option to do differently. Now, both XP and scrum are based on empirical process control (at least in theory) and they both claim that you can evolve and change the framework as you learn to use it. However, in practice, I’ve rarely seen it actually happen (Spotify being one very notable example). When you start with a predefined set of practices, it seems harder to evolve to anything else. Well, I guess Darwin never said evolution was easy.
So we have two very different schools of thought about how to think about approaching agile:
Start “where you are” and use a decision making model or visibility model to evolve to where you need to be (Cynefin, Kanban).
Start with a fixed “starter set” of best practices and then evolve to where you need to be (Scrum, XP).
I think that these two philosophies or approaches explain a lot of the conflict I see in the agile community today. The “start where you are” folks seem to feel very strongly that “starter set” approaches run the risk of being applied in a cookie cutter fashion and often incorrectly. To them these approaches are likely to lead to poor outcomes and are therefore to be avoided or even wrong headed.
On the other hand, the folks who take the “starter set” approach” are appalled by the waste involved in the “start where you are” engagements. Why in the world would you waste your customers precious time and energy on rediscovering the wheel when you already have a very capable set of practices to start with? It’s folly! These practices are tried and tested and there are very few exceptions. To ask the customer to invent their process on their own is just a high risk recipe for disaster! Therefore, to do anything other than the “starter set” approach is to be avoided or…well, you get the picture.
I think the argument only gets amplified when we start to include scaling frameworks in the conversation. As I look more and more closely at the scaling frameworks, I start to think that I see their roots in each of these different approaches. For example, SAFe has its roots firmly in the “starter set” camp. SAFe is most definitely a framework of prescribed “best practices” that are intended to be applied universally. There is some allowance made for the size and scale of the organization, but the gist is that everyone does SAFe. On the other hand, there is LeSS which seems to share its roots much more closely with the “start where you are” approaches used by Cynefin and Kanban. In LeSS there is more emphasis on using tools like systems diagrams and root cause analysis to discover the right means to change the system for scaling. So LeSS feels to me like it leans a bit more toward the “start where you are at” approaches.
Of course, the adherents of each approach think the others are nuts. I think some of that is due to how each sees the world. They are coming from very different starting points. I’m not sure they’re ever going to agree with each other. Fortunately, I’ve seen both approaches work well for people. And I’ve also seen them both fail miserably. Often it had little to do with the frameworks, and a lot to do with the people. So I guess we count ourselves lucky and try to remain calm when they point quivering fingers at each other and proclaim loudly that the other is “Not Agile”.
Posted by Tom Perry 
Agile Tools 