That’s Not Agile

One set of people seems very concerned with defining exactly what Agile is. They want a particular set of practices done in a particular way at a particular level of discipline. From them we hear the constant refrain “that’s not Agile|Scrum|Whatever” or “Kanban|Whatever is/is not Agile.”

Another set of people feel that Agile is a spectrum. A given team may be more or less Agile. They focus on the values and way of thinking. If you think Agile, then you are Agile regardless of your degree of practice. From them we hear the constant refrain “you can’t do Agile, you can only be Agile.”

They’re both wrong.

Defining “Agile”

In my mind, Agile has one of 5 clear definitions (these are equivalent):

  1. Work Tiny. Work Provably. Get Done. Work Together. Learn Constantly. Risk First.
  2. A true process of iteration. Analyze the situation. Pick 1 step. Take it. Regain stability so that you can measure results. Analyze the situation again (do not assume previous analysis to be valid).
  3. A high-discipline process of eliminating transaction risks and transaction costs which changes the fundamental economics and enables new ways of working.
  4. An experimentally-derived, high-discipline iterated learning approach to working.
  5. Create optionality. Agile approaches create options and increase the number of times you get to choose which options to execute, thereby increasing the amount of information / data you can use when deciding.

Each of these applies to a set of scopes. Any given implementation provides options in some domain, improves learning and growth in some area, drives transaction costs down in some space, and depends on a low transaction risk in some set. Furthermore, there are some fundamental constraints that come from the work being done.

We can use these scopes to understand different Agile methods: each applies the same approach to a different set of scopes. We can also use them to judge implementations. But we’ll get to that later. First let’s understand the common Agile methods.

Scopes addressed by each Agile method

  • Scrum: planning & tracking, collaborating (partial), improving the system.
  • Kanban: planning & tracking.
  • Lean Startup: product innovation.
  • XP: execution, planning & tracking, collaborating, individual learning, team learning, improving the system, team development.
  • Lean software development: improving the system.
  • Crystal Clear: improving the system.

This is why I consider XP to be a complete breakfast, while the other Agile methods are good dishes that could be assembled into a meal. This is also why XP is harder to teach and harder to do: it covers a lot more scope.

Risk changes by domain

The scopes that matter vary by domain. The best way to find them is by focusing on the risk definition. For your industry, what are the main sources of risk? Where would you gain the most advantage from eliminating risk?

For example, execution risk predominates in software construction. The commonly-used techniques, when applied to even small problems, kill companies (not every time, but often). The same is not true in other professions. Bad accounting can kill a financial  services firm. But the standard practice reduces the risk to the point that very few companies die from it. Thus it is critical that any team writing software use a process that drives risk out of technical execution, while an accounting firm need only apply best practices.

To put it in terms from Cynefin, software construction is complex. Small differences in execution have dramatic differences in future bug counts and cost, and those differences are understandable when looking back, but not predictable when the choice is made. Accounting execution, on the other hand, is complicated. There are well-known ways to perform the activity that reduce the future cost of change without incurring excessive immediate-term costs.

Aside: notice something odd here?

Consider:

  • These were all created by the software industry.
  • In that industry, execution is the root of success. It is the fundamental risk, and most risk in other scopes can be traced back to a failure to address technical risk. Improving other parts of the project do not have as much impact on cost and risk as improving execution.
  • There are 3 practices focused on planning, 5 on changing the process, and only one that pays attention to execution.

This is out of balance. We don’t need competition and choice between planning approaches. Planning isn’t that big a deal in software. We need more innovation on execution.

In software, complexity in planning comes from planning how poor our execution will be and how we will work around it.

Sitting in judgment

Now for the second part: judging whether an implementation is “Agile.” First, why would we do such a thing?

  • To feel superior.
  • Because we are new to Agile, are doing something different than what you are doing, and want to establish which of us should be learning from / change to match / following the other.
  • We are both new to Agile and are interchanging new ideas. We want to establish why we do particular things and decide which of the other person’s ideas will be most useful to us.
  • Because we are experienced with Agile and a team has asked us for advice. We want to establish what they are doing and where they can improve, and provide both a theoretical and operational background for the changes we suggest.

Obviously the first is useless. And the second is as well. It is judgment that comes from fear: I judge you because I fear that I am doing it wrong. I am trying to establish a strict leader / follower relationship. It would be better to establish an idea interchange relationship.

The third and fourth have a lot of value. It is easiest to transfer ideas when they are both grounded in a framework and grounded in concrete experience. A gap analysis (*shudder*) is a good and simple framework, as are the Agile values & principles. Add concrete experience (or storytelling, which serves a similar role) and ideas can move.

In that case, we judge whether someone is Agile in order to provide a framework for understanding which ideas will be useful and how. What each thing will improve.

Remember scopes

Nuance helps when establishing a framework. Complexity is a problem, but we need nuance. Recall back up at the top those people who talked about Agile as a spectrum? They are trying to evaluate for the purpose of helping teams understand how to improve. The problem is that one spectrum isn’t enough.

An example would be useful here.

Say that you are a team that does Scrum-based planning, mostly. You use absolute estimates rather than relative, so you have higher variance than full-Scrum implementations. But you are doing much better than before Scrum so you are satisfied. You are also doing retrospectives once per month, which provide complaints to management or PMO teams. Those teams then make process changes with which you comply. You don’t do TDD or refactoring, so are building up technical debt. You are unaware that this is even a problem. You are somewhat Agile.

Now suppose there is another team at a different company. They perform full waterfall planning. This is working very well for them. They consistently make promises and deliver on them: on scope and on time. When they will fail to deliver, they adjust scope early & notify their partners. They perform retrospectives twice per week. Each one results in one change and a decision about how to measure that change. They enact those changes before the next retrospective, measure the results, and keep or roll back the practice accordingly. This has also helped them to start seeing their technical debt. They have learned to have devs write automated tests and run them regularly. They write those tests before the code, but those tests are not unit tests: they often check more than one method and more than one result. They find that code is difficult to test in isolation, so they test it “normally” (via automated small integration tests run by a unit test framework). Design changes to make something separable would be expensive. The team does regular code reviews and those find issues. But because those are performed as a check-in guard rather than as the code is being written, it is always more expensive to incorporate the feedback than to ignore it. So many suggestions don’t get implemented and learning happens at a slower pace than possible. They are somewhat Agile.

Who is more Agile? How does each team compare to industry norms or rockstars? You can’t measure this on a single spectrum.

Now we come to scopes. The first team is Agile in planning and not Agile in team improvement. Although their implementation for planning could be improved, they are living the values and will likely get there. Their implementation of team improvement, however, is missing some fundamental mind-shifts. Responsibility is in the wrong place as a result (PMO empowerment rather than team empowerment). They will not be able to get better incrementally; they have to make a transition to an Agile approach. The team is neither Agile nor very competent in software execution. That would be fine if they were accountants, but not in software. They need some awareness exposure. They will never ask for it, but someone needs to notice this gap and show them that Agility is possible in this scope.

The second team is Agile in team improvement. They’re also implementing it pretty well; there likely isn’t much room for improvement. They are not Agile in planning. But they are implementing it very well; they likely do not need to change to Agile planning. It wouldn’t provide them business advantage. They are Agile at software execution, but not very good at it yet. They will likely get better, as long as someone introduces them to refactoring soon. They are not Agile at learning and discipline. They depend on code reviews as their only technique; this is neither iterative nor disciplined / measurable. Additionally it is not working that well for them, though they may not see that. An Agile transition of learning and discipline could help them a lot, but they will likely require both awareness and some convincing (lots of examples).

Now we have a lot more information about these teams. Which stories should each tell to help the other? Which places do both teams need help? How can they ask for that advice / set of stories? As a coach or speaker, what are the topics for which each team simply needs awareness that there is a better way? What stories can I tell to give that awareness, even though I may only interact with them for 10 minutes?

Agile is not one thing. But it is one idea. There is a clear definition—hard to describe, but singular. The key idea is to understand that that idea can be applied in many different scopes. Each method applies it to some scopes; each team needs to apply it to some scopes. We should start understanding these scopes if we really want to understand Agility and how one team can help another get better.

Which is, after all, the point of all this jibber-jabber.

13 thoughts on “That’s Not Agile”

    1. Sure. But I find the Manifesto to be inspirational and free of the context that would make it operationalizable / actionable. It is, of course, the original root definition of Agile. It also places emphasis away from things (the right side) that used to be a much bigger part of peoples' context than they are today. By defining itself partially in contrast, it ends up being a difficult definition to apply as it becomes the dominant paradigm.

      There are also aspects of the thinking that have always been there, but which have risen to much greater prominence of late. For example, data-driven decision-making and customer measurement are natural outgrowths of the Manifesto but really aren't mentioned in it at all. Same with options. And so on. These have become enough of a part of the core Agile thinking that I think they are worth highlighting.

      So these days I don't tend to refer to the Manifesto that much. I find people get Agile thinking much more quickly / easily with concrete experience plus a discussion of options and true iteration. Then I highlight how real data requires discipline and direct customer involvement. Lots of this stuff is on the second page of the Manifesto (and some of it isn't). The first page is a great rallying cry, and a great way for experts to talk about what is. But I find anyone except the top 1% find it to be low on information that they can parse / use / understand.

  1. The emphasis reflects the target audience of each method which itself reflects the background of each founder.

    Note that at least in Steve Blank presentations, Lean Startup is just XP + Customer Development

    1. It represents the background of the founder. And part of this entry was sparked by a Twitter comment that "Scrum is Agile for managers and XP is Agile for developers." But I find such an assessment too simplistic.

      Although certainly driven by the knowledge / interests of the founder, today we (should) choose a methodology based on whether it addresses the scope we need. And we can usefully subset methodologies, but only if we take all the chunks that deliver in our target scope. Otherwise we end up missing dependencies for things that we do take.

      Finally, understanding methods in terms of their addressed scopes allows us to pinpoint sources of risk. We can describe why many Scrum implementations have trouble during year 2: Scrum depends on low-risk execution (so that we can iterate fast and ship at the end of each sprint), but does not address the execution scope. Therefore when we combine them into an existing team (with its high-risk practices in most scopes), we have an unmet dependency. The system works for a while, but at ever-increasing strain. And eventually it collapses or requires a major intervention.

  2. If you're so worried about what people call a tool, you probably have only one tool and see everything as a nail. Lean/Kanban/Agile/Scrum/XP/IIP are just tools and a professional has a box full of them and deploys the right one for the right job.

    1. While I agree that most people have multiple tools available (and should), I do not think that one-true-wayism is the primary driving force behind people being worried about what people call the tool. Many people involved in such discussions are ones that I know for a fact have many tools.

      To take this metaphor to its roots: if I have 1 tool in my toolbox, I don't care what it is called. I just ask someone for my tool or offer it to someone. A grunt and gesture is enough. When I've got an operating room full of 15 different variations on a scalpel (and a whole lot of other tools), I suddenly care a whole lot that we all agree on names and purposes for each one. When I'm in the operating room, I need to be able to quickly identify the right tool for the job and ask for it, without error.

    1. I think yours is a pretty good start. I think my 12-word definition is close to a doctrine, and fairly similar (also distilled from XP, but I included the people practices too). Mine, however, would need the one-paragraph to back each word pair before it would be of actual use as a doctrine (right now it is only useful to those who already understand this method of making decisions). Yours includes that paragraph.

      But to really have an answer, I'd have to knock the idea of doctrine around with some other ideas, try it in some conversations with compatriots to challenge my thinking, try using it to train / teach a few non-Agile people to start thinking Agile (test it out in the real world), and then refine it to the bumper-sticker / meme form. That'll probably happen; I might even get it into the blog after it does.

    1. I am a guy with strong opinions, loosely held, whom a bunch of people tend to listen to because they find those ideas useful. No more, and no less.

      That's one of the great things about the Agile movement. It is decentralized. No one has any more authority than any other. We don't make decisions by authority. If people like my definitions and find them useful, then they will use them. If not, then they won't. The same is true with the Manifesto, anything Ron says, etc. There is nothing that any of us can do to make someone use anything we say. And that is why it works.

      Besides, I'd much rather disagree with Ron than agree with him. We're both likely to learn something that way. And as he is the Unofficial Grumpy Old Man of XP, what could be more agile than arguing with him? 🙂

    2. And, to be clear, I do personally see a lot of value in the Manifesto. And I see value in using it as a rubric. But only for experts.

      The Manifesto requires interpretation. It was the best description available at the time for the grand vision that those people were seeing (and doing). It is not the grand vision: it is a signpost, a guide, and an attempt to describe that grand vision. And it is well-suited to help others like those initial visionaries: people with a lot of experience doing both good and bad practices to identify ways of thinking that will help filter the good from the bad.

      It is almost useless to novices or to those who are experts at the old ways and have no experience with the new. Those are the people who are trying to join Agile now; that is (part of) why so many Agile transitions are in name only. They don't have sign-posts that are intended for someone with their background. Mine are. They are far more explicit. This limits them, but it also makes it easier for people to grasp.

      And besides, the other point of this post remains: what is the point of declaring someone not Agile? If it is to help them get better, then we want the most explicit guidance we can get, in their terms and context. If it is to excommunicate the ones who "don't get it" and keep them from polluting our purity, then I don't see the value.

  3. Hi Arlo!

    Thanks for these and your other thoughts you share with us here.

    To me, the most interesting thought here is "there is only one way to do agile execution", because I've been exploring execution for about a year now, and am by now convinced that TDD and OO are not the only way.

    Could you please expand on that area? What do you see as the available "approaches" to execution? Any approaches that are less known but show potential?

    Thanks!

    1. Honestly, XP is the only method I\’ve seen for applying Agile to engineering. I\’ve seen it implemented with many different kinds of design (OO, Functional, etc); that is independent of the methodology. You can totally refactor your code to an excellent functional design.

      I would love to see more variation in this space. For example, has anyone found a way to produce software with similar risk / defect injection rate, without using test first, refactoring, evolutionary design, pair programming, retrospectives, and true units? The only variation that I\’ve seen is to replace pair programming with mob programming. No other variation has delivered anything near the same results…that I am aware of.

      I\’d love to see more experimentation in this space. What is an alternative and independent set of technical practices that can deliver fewer than 1 bug per 100 dev-days?

Leave a Reply to @jchyip Cancel reply

Your email address will not be published.