About a year ago I got asked by my project manager to “just give a quick intro and overview; What is agile? 20 minutes or so…” That didn’t feel to bad – but when I got home and started to prepare it struck me; it’s really hard to sum up agile!
For me agile has been become more a less a lifestyle and much of the things I argue for or fight against is about agile or being agile. And also, now that agile is 10 years old, the buzzword has gone into the next phase and almost anything good or cool that people does, related to software is branded with agile ™.
Is TDD agile? If your not doing TDD are you not agile? Standups? Boards? The list goes on and on and I couldn’t come up with an intelligent answer. Either everything had to be included to be agile or nothing was left. Like the story of the old women who collects wood:
She went out and started to pick up sticks from the ground: “I’ll manage that one”, “And if I managed that one I sure manage that one”, “And if I managed that last one I will manage this one to” …
After awhile she had way to much to carry. So she started to take sticks away again; “If I cannot manage that one, I’ll take it away”, “And if I couldn’t manage that one, I will have to take this one away too” …
So I dodge that presentation.
But the question stayed with me and itched me like your knitted Christmas stockings from grandma. Later during the autumn (or rather the winter) I got another opportunity and this time I took the chance to sort my thinking on the matter. In this post I’ll share my thinking on the subject. And yes, sorry for the long post – it’s a 45 minutes presentation. But now on paper.
Shu Ha Ri
I read an excellent book called Coaching Agile Teams by Lyssa Adkins and that introduced the martial arts thinking of Shu Ha and Ri. That is different phases that you go through when learning new skills. From the Wikipedia page about it we have a wonderful translation that sums it up, short and sweet:
“first learn, then detach, and finally transcend.”
Here’s a quick intro to the three levels:
- On the Shu level you learn fundamentals and techniques. My mind often wander to Karate Kid and the famous wax-on, wax-off scene, when I think of this level.
- On the Ha level you have reached a level of understanding of the fundamentals that you can start to challenge the rules a bit. “What if I turn my hand like this?”, “Yes, but in this situation I might try to go this way instead” The thing here is that you are using your knowledge you picked up on the Shu level and break the rules based upon that knowledge.
- Ri level means that you are leaving the rules, improvising and creating new ones as needed. But coming from, or being in the culture of the rules that you learned and challenged on the first two levels.
Wasn’t this about agile now again?
Ok, ok .. I’m getting lost here. But I think that the Shu Ha Ri model says something about how and why many agile adoptions might fail; we break the rules before we know them. Or rather we break rules without really knowing the reason of the rules. WHY is it like that?
We love our tools – and a word on diets
Moreover our industry loves and craves tools, guidelines and best practices. We are still longing for a short and sweet description that says; “do this and your software development project will be a success”. A silver bullet if you like, when I learned 1986 from mr Brooks that no such thing exists.
And really … we know this, don’t we? We’re just hoping… Oh we hope sooo much. Like people still searching for a diet (only bananas, low carb high fat, pills, TV-shop) when we in reality knows; eat less, work out more. Bam – works every time. But we’re still hoping – maybe this blue pill will do the trick. Or this bicycle thingy that folds and plays my favorite music at the same time – it will make me slimmer. I know it…
And that’s the reason for failure of many other software methodologies and processes; RUP, for example, wasn’t intended to be used the way many people used it. Nothing in RUP saying that you should have year long iterations for example. And it even says explicitly that the documentation templates was just templates, to be modified - it still we use all of them, and all of the headings as well. Just to be sure.
In fact the dreaded Waterfall method is in itself a misconception and erroneously applied model. The man that “coined” the phrase used it as a reference to a flawed model, but still our industry took to it as a fish to water. Why? Because it was something to hold on to.
“The waterfall method you say…? I’ll take it”
“But it’s flawed!! It was meant as a joke…”
“Don’t care! It’s at least something”
Dan North did an excellent keynote on this at OreDev 2011 – we he said;
“We rather be wrong than uncertain”
Scary but true.
Applies to agile processes
So when agile came along, starting with Scrum (at least in Sweden), we all went;
“Yes! That’s right! And with some rules along with it. Lets go”
So everybody started apply Scrum. Or at least tried. Or at least where it didn’t hurt to much. I have actually never seen a Scrum implementation as it was meant to be; it’s always some part missing;
- Yeah, we do Scrum, but we don’t do standups/have a board/sit together
- It was too hard to find a good Scrum-master so we have our own applied version of it.
- It’s Scrum-ish; we don’t meat our customer that often, and we have skipped iterations.
This have to do with not embracing the fundamentals that agile is based upon. Or if you like (and to finally get back to the martial arts mumbo-jumbo about ShuHaRi); we’re breaking the rules of agile without knowing why?
What is agile?
So, with that in mind, answering the question “What is agile” is not that hard:
“An approach to software development based on the values and principles expressed in the Agile Manifesto”
And the agile manifesto talks about, as you already know:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
But what do they mean in the Agile manifesto then?
Well, I will not be so presumptuous as to say that I know what they were thinking. But if we try to think about WHY they have written as they have… Maybe we’ll learn something:
We are uncovering better ways of developing software by doing it and helping others do it
What’s the thought behind this statement?
- Firstly “uncovering” means that they (and we) are still learning. This is not the truth once and for all.
- Secondly “developing software by doing it” – all the signees of the agile manifesto were developers, to my knowledge (!). They still had their hands in the dough. If that’s good or bad is another question…
- Thirdly – “helping others” – they haven’t been sitting alone and dreamt this up. It’s based on experiences from a lot of projects where they together have been involved in.
Individuals and interactions over processes and tools
Why do they write this?
Software is a knowledge creating process – nobody knows the finished product before it’s done. Not even the customer. In order to succeed we need to communicate. A lot and often.
So … therefore it’s more important to focus on the individuals in the project and their communication, than to focus on following a certain process, or use a certain tool. If you communicate well within the group – the process and tool becomes secondary by itself.
What do you do when a project is in danger of being late? You put all the smart people you need to create the product in one room. Leave them alone and let them work. There you have it; Scrum in a nutshell.
- What would change if you could talk to your end-customer/stakeholder each day?
- What is the number one thing hindering you from doing so? How can you change that?
Working software over comprehensive documentation
Oh man – this one has been abused so much it isn’t fun anymore. It DOESN’T say “No documentation” – it says; “Working software over comprehensive documentation”. Of course documentation is needed.
Why do they write this?
Working software is actually the only real metric that you could use for progress. How much software that works (that the end user can take advantage of and be more productive with for example) are you putting into production each week?
That’s why we are here; to help and delight the customer with working software. Think for yourself how happy your customer would be for a great requirements specification. … Exactly – not that much. Still, that is what is being DONE after several months in some projects.
And why is it important to put it out there often? To get feedback. Feedback is the creator of knowledge. Without it you can do changes but you don’t know if it’s the right change, or how much you should do.
I love a Michael Feathers tweet about this (couldn’t find a link to it now sadly):
“This definition of done this scares me. Code is in production or not!”
When we take software into production we know that it’s there. Ready to be used. And we’re run through our process (analysis, design, development, testing, building, deploying). All of this will give us valuable feedback to improve upon.
This is also a foundation of Lean, to move small bodies of work through the whole production chain often and swiftly. But, very important - WHY? To learn and improve your process!
That’s why even well working units at Lean plants will continue to put more pressure on themselves (decreasing WIP-limits for example) when they already work well. To further improve.
- How can you measure how efficient you are creating working software?
- What is the need of documentation from a end-customer perspective?
Customer collaboration over contract negotiation
So what is the reasoning behind this then?
Well as with the first point this honors the fact that nobody actually knows what the finished product will look like. Not even the customer. Not even in “re-writes” (trust me – I’ve been doing my share of those).
But why writing this “contract negotiation” in here? Well that the common way of “protecting” yourself against uncertainty in the software industry. Write a contract or an SLA. And really what – is bad about that? Here’s a story that I’ve took part in:
After a project at one of my client we sat down in one of the rare opportunities we had to meet the customer. They were happy – because we had delivered before the estimated time. But we started to talk about how we worked on “each side” customer vs. IT-department (yes, sadly the same company).
“So how did you do estimates? You were about 20% under budget. How can you guess so badly” – the customers project manager asked
“Well – first we make a guess and then we always add 30% just to be sure” said the IT project manager
That made the customer side burst into laugh in unison. When they had calmed down they said:
“That’s exactly the same thing we do with all your numbers. We add 30%, because otherwise we just get disappointed”
I wish I was making it up but I was in the meeting. So both sides added extra time and resources to the estimates to protect themselves. But here’s the most stupid thing about this – all that time they could have been cranking out “working software” instead. Now we were writing contracts, budgets and estimates.
Really this whole business of having a IT-department that the business side “buys” services from is wasteful in itself. It doesn’t promote a collaborative culture. It’s writing contract instead of collaborating.
- What could you stop doing if you sat next to your customers?
- What would you change to improve collaboration among different departments in your project?
Responding to change over following a plan
And the final one – which I have found to make the most profound change in my thinking. Why have they written this? This is at the heart of the philosophy behind agile; what kind of person/project/ company are you?
If problem arises with a plan you made – what are your first measures? Some people would make even more plans, stricter budgets and less maneuverability for the next project. Others would say; well that was to strict let’s give ourselves more flexibility for the next time and not plan so much in advance.
I’ve heard of companies who’s CFO’s war cry is; “no exceptions” (everybody goes through the same exact process and is treated in the same way). And on that same company there were team leaders that said: I only do exceptions all day long – that the way we roll.
So again, there’s is nothing wrong with planning. In fact, I think I have planned more when I started with agile than I did before. But I have completely shifted the horizon. I make detailed plans for the next few days or weeks and very rough ones for anything bigger than that – because I know it will change. That’s the only thing I do know about the things down the project road, in fact. Look up Rolling wave planning for more on this.
And this also comes back to feedback, which I think sums up agile in a word. To align your process in such a way that you get feedback and change your behavior to adapt to the new situation.
- If you knew that everything you have decided upon so far could change – how would you set up your project differently?
So – really what is agile?
Agile is a philosophy, a way to approach how you do stuff (system development mostly). There are not steadfast rules on how you should or shouldn’t do things.
So to “become agile” you and your team must apply this thinking and then start adjusting yourself, your process and the people around you in small steps towards that thinking.
I have found simple goal-statements, rephrased into questions, to be to great use to guide me and teams I have coached. For example this statements:
“Will this (meeting, feature, schedule, prioritization) make our customer more happy?”
“If you were forced into delivering new functionality into production every month/week/ day – what would change first to get there?”
“How could we solve the number one hindrance you see to deliver every other week”
Conclusion
This is how I see the question and it’s answer today. I’m sure I will change. Often and a lot. But that’s just part of the whole being agile thing.
I hope you got something out of this. I sure did just by forcing myself to write it down.