V1, Because We Embrace Change
by Alexandru Bolboacă and Maria Diaconu
Does Agile Work?
Short Answer:
The optimistic version: Yes. No.
The pessimistic version: No. Yes.
Philosophical Answer:
If you become a Buddhist, will it end your suffering?
If you learn martial arts, will you be able to always defend yourself?
If you learn the rules of chess, will you become a grand master?
Long Answer:
Agile is a phylosophy based on 4 principles:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Like any phylosophy, Agile works or not depending on how you understand and apply it.
From our experience, many people don’t try to understand in depth these principles and apply recipes. The trouble with recipes is that they hide one of the principles not stated in the Agile Manifesto, but one that all practitioners come to understand:
Software development is hard.
Software development is painfully hard. It’s so hard that any software project today has 60% chance of failing. Software development requires skill, determination, discipline, energy and a continuous fight with yourself (as a professional or as a team).
The Agile Manifesto is merely a set of conclusions that derive from this observation. Software development is so hard that we cannot put it into a box (called process) and forget about it – we need to monitor it continuously. It’s so hard that in the majority of cases, one person cannot do it effectively – we need teams that work together as one. It’s so hard that we need to learn continuously to be able to finish a project – about the project, about the technology, about the customer, about the end users, about the techniques and about themselves. And, if this wasn’t enough, we need to accept that we cannot predict the future and that we need to allow change as effectively as possible.
For us the subtitle of the Agile Manifesto is:
Welcome to the desert… of the real.
What Makes Agile Work?
Short Answer
Optimistic Answer: How you apply it.
Pessimistic Answer: Nobody knows exactly.
Philosophical Answer:
Can you step in the same river twice?
Long Answer
We believe in the Agile principles, because they’ve always made projects we were involved in work better. This doesn’t mean they are the best or that somebody else will not come with something smarter. This doesn’t mean they always work and it doesn’t mean we’re the final proof that they work. We’re almost certain that by the time we will get such a proof, an improved method will emerge from practice.
We’ve applied various agile flavours, from Scrum-ish, XP-ish to Kanban-ish and they’ve all worked well in the corresponding context. And for us, the key to the whole applying agile thing is: provoke change instead of fighting it, learn from change, allow yourself to make mistakes and build a team (David Hussman calls it “community”) that wants to work on that product and that wants to build the best software ever for the end user. Go beyond labels, titles and names to what really matters: excellent working code, excellent communication and collaboration in the team, excellent understanding and involvement in the product building, excellent understanding of the real needs of the end user and of the business around the product. From our experience, this is what makes agile work.
It may sound idealistic, but it shouldn’t stop us from trying to get as close to it as possible.
Can Anyone Help Me Implement Agile Successfully?
Short Answer:
Sometimes.
Funny Answer:
How many Agile Coaches does it take to change a lightbulb ? – Just one. But the bulb has to really WANT to change. (adapted from a psychologist joke)
Philosophical Answer:
I can only show you the door, you have to walk through it.
Long Answer:
First, the question is wrong. You should wonder if anyone can help you improve your way. You must be doing something right since you are in the business, so you shouldn’t think about implementing agile but about improving.
Let us tell you a secret: no Agile Coach knows what’s best for your team when he/she comes to help you. Really good Agile Coaches will never give you a recipe of things to do to improve your ways. They will spend time with you, show you some practices that work for other teams and create the opportunities for your team to try them and to decide if they work or not. What you really need to build is the capacity for changing and learning rather than the capacity to follow a recipe.
We know teams that do Scrum but don’t do daily meetings and it works very well. (We can already hear the horde of Scrum preachers shouting at us). It works because those teams communicate effectively all through the day. Who is anyone to go to such a team and say: “No! You MUST DO daily meetings or you’ll be expelled from the Scrum heaven!” ? But if you don’t have the capacity to communicate effectively (something we see far too often in Romania), you must start somewhere – and the daily meeting is a way to start.
We know teams that don’t estimate. Estimation can be seen as waste, since you try to make an (hopefully) informed guess on the time it takes to complete something. Wouldn’t you care more about completing at least a part of that something? We would. However, this is possible only if your customer trusts you completely. You can build this trust by showing progress in the good direction, which you do by releasing good quality software as frequently as possible – our definition of quality being something that’s as close to “What the customer really needs, when it needs it” as possible. And doing this is very very very (did we say very?) hard but can be done using some practices – early feedback, pair programming, refactoring, clean code, TDD are the ones that worked for us and other people.
Therefore, the answer is: the right person can help you improve the way you work. It depends on the coach how effectively the experience is passed on to you and it depends on you how much you get out of it.
Should I Start Applying [Practice X] Now?
You should definitely try it. If it’s something hard (like TDD), you should practice a lot and/or get some help. You should learn how others are doing it and especially how the masters are doing it. We’ve only spent about a week with J.B. Rainsberger, but he’s been doing TDD for 10 years and he opened our eyes on many things that we can try now. We believe that one of the reasons TDD doesn’t work for more people is that only a few people are practicing enough. It’s the same with every technique. So yeah, definitely try it.
Does Agile Mean Anything Anymore?
We think that we’ve shown in this article that it does. Maybe we should stop calling it agile and create a supersecret word for it that will be used only by the real masters, which will of course exclude the marketing departments, corporate software process tool vendors and other similar categories of people. Or we should do the sensible thing and stop caring about how it’s named or how to call it and try to make our teams better, one step at a time, a small thing every day. Given enough time, you will notice the difference, and that’s what’s really the point of it all.
The Romanian Ending [sorry, non-translatable joke]
Și finalul – banc sec pentru programatori:
Am venit să vă facem Scrum
Nu, nu, nu ne ardeți!
Ba vă arătam un burndown!
The English Ending
Spoon boy: Do not try and bend the spoon. That’s impossible. Instead… only try to realize the truth. Neo: What truth? Spoon boy: There is no spoon. Neo: There is no spoon? Spoon boy: Then you’ll see, that it is not the spoon that bends, it is only yourself.
We’re Alexandru Bolboacă and Maria Diaconu, and we love to learn, to practice our craft and to solve problems. We write sometimes – less often than we would like. Loved or hated what we write? Let us know.