At the GOTO Amsterdam 2015 conference Dave Thomas gave a keynote presentation titled "agile is dead". While the "Agile" industry is busy debasing the meaning of the word, the underlying values are still strong. Thomas suggests to stop using the word agile and switch to agility: repeatedly taking small steps towards where you want to be and evaluate what happened.
InfoQ interviewed Dave Thomas about the expectations when writing the agile manifesto, advocating against rules and recipes, journeys of agility vs. change projects, switching to agility and how people can develop skills that will help them to increase the agility of the organizations that they work in.
InfoQ: You mentioned in your talk that agile has become an industry. Did you expect that something like this could happen when writing the manifesto for agile software development in 2001?
Thomas: I think there are probably two parts to that question. The first is "did I expect agility to take off the way it did." Then, assuming it did take off, would I have expected an industry to form around it.
The answer to the first part is "no." I had no idea that what we all did would become so significant. Largely that's because we weren't really aiming for anything world-changing.
The intent behind the Snowbird meeting was simply to explore what commonalities we could find between the different ways the 17 participants created software. We discovered that, although the day-to-day executions were very different, we all shared a set of values—things that were important to us. That's what we encapsulated in the manifesto.
We published it because we felt it was a great starting place for a discussion. We invited other developers to sign it (online) as a way of helping them to think about what they did and why they did it.
And at that point, most of the 17 were done—we moved on.
But something we did tapped some kind of need, and the manifesto took off explosively. Teams started looking at the values and working out how they could create practices that honored them. Many took XP or SCRUM as a starting point, and then adapted them to their own circumstances. This was exciting stuff.
And I think it surprised us all :)
InfoQ: I'm hearing more people who are advocating against rules and recipes for software development. In your opinion, why do people want to have this, and stick to them?
Thomas: People go through phases when they learn something. When they first start out, they have no understanding of the context they find themselves in. There aren't many decisions they can meaningfully make—all they can really do is follow rules. (If you are about to take your first parachute jump, you don't want to know about areodynamics, fluid flow, nylon stitching techniques, or the best kind of altimeter to buy. All you want to be told is "count to five and pull on this handle.")
But, as you gain experience, you start to understand the bigger picture. And with this understanding comes a growing intuition about how things work. At this point, the rules you had originally hold you back. You can see further and more clearly, and you can see how doing things differently might be better. So you start to experiment, tweaking things here and there. If the result is better, you tweak some more. It it is worse, you roll back and try something new.
So when consultants say "Do X and you'll be Agile," they are wrong. Fixed rules just don't work, because they lack context.
The ideal consultant would say "I have no idea what will work best for you. Neither do you. But we have to start somewhere, so let's try the following practices for a month. At the end, we'll evaluate what worked, and what didn't, and adjust accordingly. The initial practices may well be XP or SCRUM by the book. But six months from now, there won't be a brand name for what you're doing, because you'll have invented it for yourselves. And, guess what? You'll never stop changing it. Let's have fun!"
InfoQ: In an earlier interview with InfoQ on Agility over Agile you suggested to stop using the word agile and switch to agility. Can you elaborate on this?
Thomas: This is all to do with the fact that "agile" has become meaningless.
As the popularity of the manifesto grew, consultants and companies started to sense an opportunity. We started seeing people using the tag "Agile" with their existing offerings in the same way detergent manufacturers add the word "Improved" to their product name. Often they'd ignore the fact that "agile" is an adjective and instead use it as a noun: "learn Agile today!"
Why do they do this? Because it is easier to sell nouns (things) than adjectives (qualities of things). You can't buy blue, but you can buy a ball. If they wanted to sell "agile" they'd need to make it a thing.
But, it isn't. The manifesto is a way of thinking about things—it is values, not actions. So everyone who coopted the word "Agile" has devalued it, reducing it from its original concept into something that is just a buzz word. "Agile" is now used with software products the way "Natural" is used with food.
I don't think we can fight this. But I do think we can bypass it. I think the original values are still valid, and we can use them to inform the way we work.
I like to express it like this. Every team that develops with agility follows these steps:
- Know where you are
- Take a small step towards where you want to be
- Evaluate what happened
- Repeat
This sounds easy—it isn't. It is hard because it applies to everything, at all levels. It applies to naming your variables, and it applies to defining your architecture. And implicit in the steps is the often overlooked fact that we are never done. We don't stop the process when we reach some goal. We stop it when the incremental value we deliver is less that the cost of delivering that value.
To me, this is agility. And every developer can work this way. After a while, after it becomes second nature, then maybe groups of developers following these steps can find ways to make them work for the group as a whole. Or maybe they can find ways of making them work outside a pure software environment.
InfoQ: In your talk you stated that "When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier". Can you give some examples showing how this can be done?
Thomas: This all comes down to Thomas' rule of design:
"Good design makes future change easier than bad design."
There is no other definition–everything else derives from this.
So I add the practice about future change to my agility list because it is the one practice that helps prevent decay as systems evolve.
Take a simple case. You have HTML/Javascript code that implements a "buy now" panel. It works really well on the pages of your site that sell books.
The customer comes along and says they want the same "buy now" panel of the pages that sell service contracts.
In the old days, we might well have copied that code from the one set of pages and pasted it into the other set. Today, we'd invoke the Don't Repeat Yourself (DRY) principle and find a way to share the functionality.
But why? DRY isn't really any kind of universal axiom. Why should we follow it.
Because it typically makes future change easier. If the customer want the layout of the panel changed, we only have to change one thing if we shared the functionality. If we'd copy-and-pasted, we'd have to change it in multiple places. And, eventually, we'd forget about the copy, and things would get out of step.
Think about all the principles you've learned about design: SOLID, Liskov Substitution, contracts, MVC, and so on. The intent behind every one of them is to let you change things more easily.
Given this, choosing options today that make change easier tomorrow just seems to make sense.
InfoQ: Do you have suggestions how people can develop skills that will help them to increase the agility of the organizations that they work in?
Thomas: That is a fantastic question.
Firstly, I agree 100% with the sentiment. Agility starts with individuals, and spreads wider. It can never be "imposed" from above.
But the question asks how can they as individuals increase the agility of their organizations?
At one level, they don't have to do anything. One individual being more effective will presumably has a small positive impact on the overall organization. But the effect will be disproportionately small, because the benefits will be eroded by the inflexibility of everyone else.
To get the most from the exploration of agility, developers need to educate those around them. But how?
Let's go back to the four steps:
- Know where you are
- Take a small step towards where you want to be
- Evaluate what happened
- Repeat
Step 1. Know where you are. In this case, the "you" isn't the individual developer—it's the group that the developer is trying to inspire. So we need to find out where that group is. What doesn't work is for the agile developer to decide that their way is better and to try to impose it. Instead, use step 1 to explore with the whole team where they feel they are, and where they'd like to be. At this point, move to step 2.
Step 2. Take a small step. What is the smallest change that could be made to move the team toward where they want to be. It might be adding a daily 10 minute standup meeting to improve situational awareness. Or it might be eliminating the daily standup meeting because it is perceived as a waste if time. Decide on the change, and implement it, but only for a fixed time (maybe two weeks).
Time for...
Step 3: Evaluate what happened. Do folks feel the team is working better or worse. Why? What else could be done. Can the change be improved? Scrapped? Refactored into some other practice? You're unlikely to get things right the first time. As Kent Beck has said, embracing change is the key to success.
Step 4: Repeat. Because stagnation is death.
About the Interviewee
Dave Thomas has been programming since the 70’s, and still codes just about every day. He has written a number of books, including The Pragmatic Programmer, Programming Ruby, Agile Web Development with Rails, and most recently Programming Elixir. These books reflect the arc of his interests — programming, dynamic languages, DSLs, and now functional and concurrent languages.
