Recently, there has been a series of tweets with the hashtag #NotMyAgile. They are usually a statement or example of some dysfunction in how people are implementing agile. Many are the kind of thing that you read and nod your head thinking, “Yup, that’s not how I’d do it. They got it wrong.” But there’s part of me that feels like this isn’t very helpful.
Look, I know there are a lot of ways to screw up the agile methods. There are truly endless possibilities there. However, pointing them out doesn’t do us much good. It’s really the same as saying, “That’s not agile.”
The question isn’t really, “Is this behavior agile?” But rather is there a way to help. Or is this offending behavior really the biggest problem they face? If I’m in a company with two teams and one team is micro-managed, that’s a big problem. If I’m in a company of 50 teams and one is micro managed, it’s one of many issues, and may or may not rise to the top. Context really matters. And in most contexts there is always at least a little dysfunction. Rubbing people’s noses in it doesn’t help.
There are some egregious cases, and perhaps that’s what some folks are objecting to. Agile gone so wrong, so badly misinterpreted or misused that all agree that’s #NotMyAgile. I’ll be honest, it’s easy to run around finger pointing at the misuse of just about any practice or method. It’s trivial really. What I crave – what I really want to see, are the successful cases. So I’m going to propose a new hashtag: #ThatsMyAgile.
My agile is going to look different from your agile. My agile will vary from place to place, team to team, person to person. My agile isn’t ever perfect. It has bad days. It can even suck. #ThatsMyAgile.
Simon Wardley does a marvelous job of highlighting some of the essential requirements for understanding and defining strategy. There are five key elements that he describes in his book:
Purpose – why are we trying to do something
Landscape – the map of the business domain
Climate – the weather
Doctrine – the rules of the game
Leadership – decisions we make
The underlying premise is that you can’t have meaningful strategy without a map. All of these elements support that contextual understanding of strategy and the decision making necessary to interpret and navigate the business landscape. Otherwise, without a map you are flying blind. Wardley’s book does a wonderful job of explaining this much better than I can.
So as I’ve been trying to digest and understand strategy and the need for a map, it occurred to me that this might also apply to risk. Can we understand risk without an understanding of the landscape? Is Wardley Mapping not only useful for strategy but risk assessment as well? I suspect some might argue that strategy and risk are inextricably linked. That could be the case. Perhaps all strategy is really a very high level of risk management? Or perhaps it is just one element of strategic thinking. Because I would assume that accounting for risk is part of all good strategic thinking. Food for thought.
I’ve been fortunate to have been a part of the agile community for many years now. And in that time I’ve seen a lot of things change. In the beginning things were pretty small. You started with the team and if you managed to get to high-performing you were doing pretty well. Later as agile became more and more successful and methodologies like Scrum, XP and Kanban became more prevalent we started to run into issues as teams of teams work together. It was at that point that you saw the scaling frameworks come onto the scene. After the scaling frameworks were introduced you started to feel pain in other parts of the organization. Now if you got one division working they would struggle to work with other divisions or other functions in the organization like HR or finance. So in this latest incarnation business agility has become all the rage. Business agility promises to extend agile further through the organization. So now we start to incorporate different areas like HR and finance and marketing and sales under our agile umbrella and ideally the whole organization is working in an agile fashion.
At this point you might be well justified to ask the question, “Are we done yet?” In fact, I’m not sure that we are. There are a couple of things I think we can expect out of the next few years. First, I expect agile will become more of a cross organization feature. By cross organization I mean across companies similar to the way you see Japanese companies implement their families of companies and products. This is going to basically apply agility to the entire supply chain which will be a revolution for major industries. Beyond that I think you’ll also see agile being applied in domaine where it hasn’t typically been used before. I’m thinking of places like churches, nonprofits, any kind of non-IT organization that’s larger than a single team. Thirdly, I think you’ll start to see agile commoditized. By commoditized I mean that agile will become the kind of thing that is implemented as a matter of course in some sort of fashion that becomes nearly second nature. This means that the need for custom consulting and for coaching will go down dramatically. As agile and its practices become more and more internalized into the existing operations and becomes the status quo in companies across the world there will be less and less need for outside coaching and consulting. At this point, agile Will have become a commodity of sorts. I tried to put it all in a Wardley map:
Finally, there’s one last place that I think things will go which is to say that people of been waiting a long time to see what the next version of agile would be. Call it agile 2.0 or agile 3.0. Whatever the term, it will be the post agile thing that comes next. People have been speculating about the possibility of what the next great thing is going to be for the last 10 years I think we still have quite a ways to go another 5 to 10 years before we see whatever this next thing is going to be. At that point agile will be the status quo and it will be ripe for some new ideas to come in and make it completely obsolete. Now what exactly that is I have no idea. In fact I probably won’t recognize it until after the fact. Given that there is still plenty of room for growth and opportunity within our business, I’m be excited to see when we all go next.
Recently I’ve been reading Simon Wardley’s book on strategy mapping. I’m finding it to be some of the best writing on strategy that I’ve ever come across, so I really recommend it if you have the inclination to learn more about strategy. Simon is a very vocal critic of the typical tools that we consultants use to ‘do strategy’ with. In particular, he is especially critical of the use of 2×2 diagrams and SWOT analysis. His central observation is that strategy as we do it today, does not take into account the landscape, climate and doctrines that should be applied. Instead, many, if not most of us, are guilty of talking about strategy while completely ignorant of the landscape, climate, etc. In fact, most strategy is usually a series of gut feelings backed up by the opinions of the highest paid people in the room and nothing more.
That’s quite a damning indictment of modern business strategy as it stands today. Unfortunately, I think it is a rather accurate critique based on my own experience. This reading on strategy has gotten me thinking about risk and how it relates to strategy. When we attempt to use a SWOT matrix to talk about strategy, one of the things we are attempting to do is address risk, at least indirectly. When we are talking about strategy, risk can be something that we run toward to take advantage of or run away from or try to guard against. In that sense, risk is a key consideration in the discussion of strategy.
I find that relationship of risk to strategy fascinating because risk is a precursor to many of the impediments that organizations face. If you haven’t seen it before, I have a model for how risks evolve in an organization over time. It works like this:
Risks => Impediments => Lessons Learned
According to this model, risks are a possible impediment that we may or may not encounter. Once we have encountered an impediment (assuming we have done nothing to mitigate or manage the risk), we may learn from the experience after the fact. So, this is a model for the evolution of risk for agile teams. The cool thing about this model is that we can use risks to detect upcoming impediments (think of finding risks as possible impediment detectors).
Given that this model might hold true, how does strategy impact risks, and ultimately, organizational impediments? I think that strategy may be our first opportunity to understand the big risk picture. I suspect that in many organizations, this view is not widely shared, which is a shame. Also, if understanding the business landscape and climate is critical to understanding strategy, then isn’t the landscape and climate critical to understanding business risk as well? Perhaps we need to be using Wardley maps when we discuss risks too. It’s interesting food for thought.
I wrote a book a few years ago about dealing with impediments on agile teams. It’s right there on the upper right of the page (I’ll give you a minute to make your purchase). Well, the industry has continued on since those heady young days, and two things are still true: people still underestimate the impact of impediments, and impediments are bigger than ever.
Where agile was largely a team level affair not much more than a few years ago, now it is much bigger. Scaling is all the rage. Now we work in teams of teams or in things called release trains. Entire divisions of major corporations undergo mind-bending enormous agile transformations. We now have many different kinds of frameworks that we can use when making those transformations. One of the most popular is SAFe. If you haven’t seen it before, you should check it out scaledagileframework.com
The first thing you will see is the “Big Picture.” It is an enormous diagram that attempts to portray all of the processes and practices that you can apply to use the framework. They’re not joking about the ‘Big’ part either. That diagram is downright intimidating. Go ahead, grab a magnifying glass (you’re going to need it) and let’s take a closer look. You see all sorts of things that we are familiar with in the agile world in that picture: user stories, features, scrum, kanban. All of my favorite technical words are in there. It’s a process management smorgasbord! Did you notice anything missing in that diagram? I don’t know about you, but it seems like they threw in everything but the kitchen sink! Oh…wait…hold on a second…where are the…impediments!
THEY FORGOT ABOUT IMPEDIMENTS!
I’m outraged! Shocked! Shocked I tell you! The nerve of some people. Oh, I’m sure they make some passing mention of impediments deep in the smelly bowels of their documentation. Someplace dark, where no one will find it. Impediments are certainly not a first-class citizen in SAFe’s world. I’m so depressed. Well, I guess that’s it: SAFe sucks.
But then again, If I go look at some of the other scaling frameworks, surely, THEY will have impediments, right? Let’s go take a peek at LeSS (less.works). AAAAARRGH! Again, no impediments! But…maybe one of those more disciplined frameworks like DaD (Disciplined Agile Delivery) will make some passing reference to impediments. OH NO! Not again! None of these frameworks makes mention of impediments. They all suck.
Well, fine. Be that way. Go ahead. Ignore impediments (You fools!) See how far you get. I’m not bitter. Go ahead, call me when your precious value streams are tied up in knots. When your teams are blocked from delivering to production. You see, now, perhaps more than ever, impediments are increasingly relevant, especially when we start talking about scaled agile development. Risk management doesn’t go away just because your agile got bigger.
In all seriousness, I think that it’s worth considering where risk management does fit in the popular agile frameworks (or perhaps why it doesn’t). All too frequently I think it is lost. To some degree that is not a surprise. Many of these frameworks are so top heavy with processes and practices that it’s a miracle they don’t collapse under their own weight. Why pile on yet one more practice to the mountain that is already there? It’s just one tiny little process. Wafer thin mint anyone?
Alternatively, perhaps it’s time some of those frameworks went on a bit of a diet. And rather than trying to cram in the latest fad like continuous delivery, devOPS, etc. perhaps we should toss out a few things and try a little risk management. It could be a real lifesaver.
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.
Well Sherman, Any time I explain what Scrum or XP is, I start with time boxes. The time box method has been around a really long time. The earliest record I can find in a casual search is where they were used at DuPont in the 1980s. I suspect that time boxes are much older than that. The time box basically applies a constraint to the system. It creates an arbitrary start and end date, usually on the smaller side. You commit to a fixed amount of work and when the end of the time box is reached you are done, no matter what the completion state of the work. Work that is complete is counted as done within the time box, work that still remains to be finished is either scope that gets dropped or perhaps that work is continued in the next time box.
This technique has some benefits:
Deadlines, even arbitrary 2 week time boxes, help keep everyone focused.
Deadlines force the question of prioritization. Not everything will fit in the box.
Small time boxes create a short heartbeat or pulse that is useful for measures of capacity and throughput.
It forms a useful skeleton for the OODA improvement cycle
There are also some challenges:
Small time boxes demand that you figure out how to break work down into smaller, but still valuable pieces. Many teams find this hard to do.
Small time boxes means that it is almost inevitable that scope won’t be delivered sooner or later. How the business manages this scenario says a lot about how the benefits of time boxes are perceived.
Much of the angst of estimation is due primarily to the fact that teams are struggling to fit work to their limited capacity in ways they didn’t have to prior to the time box.
It doesn’t work if you can’t break the iron triangle of scope, schedule, and quality. Scope usually has to be compromised in some form or another in order for time boxes to work (it’s kind of what they are based on)
Like so many other things, a time box is useful in the right context, but not all contexts. I’ve seen a few projects where a time box would not work (hardware constraints, legacy mainframe applications, an organization that wasn’t willing to give up the iron triangle, etc.). All too often we force the time box on the team and tell them that they suck if they can’t overcome the challenges. Sometimes that’s true, other times it isn’t. It’s a judgement call. Beware, and don’t let yourself get caught forcing a round peg into a square hole (I’m looking at you Scrum).