Let’s be honest, wherever you look nowadays, you see Agile development all over. Whether it’s a software house, a consultancy firm or big corporate requiring software development they will probably recommend Agile as the way to go when it comes to developing a piece of software.
Don’t get me wrong… I agree with most of the prescriptions, but although we have already heard, read and talked about being Agile, and even if most of us have worked several times in agile environments, sometimes we forget what Agile Development is really about. And usually, that’s when things go South.
The “so-called Agile Projects”
Here at Near Partner, we are big believers of Agile – yes; we are as guilty as all the others for using and abusing the word. And we’ve been around of “so-called Agile Projects” where things were as agile as a 5-ton rock in the ocean’s bottom. Luckily, we are much more used to really agile projects where the Agile mindset is understood and implemented, wich allows us to have a nice sample of examples to learn from. And that kept me thinking:
- What are the differences?
- Is there a correlation between those projects and its success?
- Does Agile translate in bigger effectiveness?
I know you are a busy person. I know you probably have better things to do than reading another post about agile development. So, let me cut to the chase and blow immediately the conclusions:
Yes, agile projects are more efficient, have better results and relate to a bigger sense of accomplishment from everyone involved;
Yes, the end result is usually more aligned with what is needed (even if that not what was defined in the beginning);
Yes, there’s a problem with the “so-called agile projects”. So many times, it’s even worse to work in those projects than in others that don’t even pretend to be “agile”.
I will not give you the numbers that confirm these previous 3 conclusions because that’s not the goal of this post. Maybe some other time, I’ll dwell into that. So, for now, you will have to take my word for it. What I will share with you is what’s a “so-called-agile-project”.
- What makes them special?
- What characterizes them?
And so, our quest began.
We are not that special. When it comes to committing the mistakes in the following paragraphs, we’re as guilty as anyone else for having done them in the past.
Being a self-learning organization, we just try not to commit the same mistake twice (or thrice).
Since the beginning, we’ve been dissecting our projects, whether they were successful or not. One thing we do in every project is running a retrospective of the project. And it was obvious that there were projects where we were not being Agile.
From analyzing these different projects one thing became evident. Usually, the “not so agile projects” suffered from at least one of the following problems. We came to call them the 2 misconceptions of Agile Development:
- Just set it up, it will solve
- Agile is the end
In order to try to better explain what each of these misconceptions means, we’ll resort to the Agile Manifesto:
THE MANIFESTO
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
How do those 2 misconceptions we identified back there relate to the manifesto?
#1 Just set it up, it will solve
Many times, the existence of any agile methodology seems to be counterproductive. This is particularly true when those involved assume that they don’t need to put an effort anymore. The methodologies are here to make everything right.
Almost everything in the manifesto contradicts this. Actually, the agile structure, if anything, just bring a “let’s focus on the right things” attitude. People over processes means whatever you do (whoever you are) is important in the project – otherwise, you should not be there in the first place. But the process will not save you from yourself.
It’s the team’s job to look into such a fallacy.
There’s no other way. If a problem arises, you (and the rest of the team) have to think yourselves out of the situation.
#2 Agile is the end
That’s plain wrong. Agile is not the end.
Being efficient is the end.
Building the right project is the end.
Avoiding roadblocks, and hurdles, and problems to successfully deliver the project: that’s the end.
Many times, one hears:
“But we should not do that. That’s not what agile prescribes.”
or
“But I once read that in Agile we should not do that.”
or
“My [fill the blank with any father figure in your agile world] once said that was a pitfall we should avoid at all cost if we want to be agile.”
As to being Agile, the word “Agile” says it all. Things are not “always” or “never”.
Projects change. Situations change. The environment is different.
We have a brain and we should use it.
Sometimes, some ceremonies might not make sense.
Sometimes the people involved are not prepared to follow a specific course of action.
Sometimes agile may not even be the best option (although most of the time it is).
Agile is the means to get you there, not the end.
As Master Bruce Lee once said: “Be water, my friend.”
What Agile development means to you? Do you agree with our point a view? What does your experience tell you?
Share your thoughts with us!
Download the free e-Book!
Want to know all about outsourcing software development and how to set up
and maintain a great relationship with your outsourced teams? Get your free copy now!
