I definitely love that talks with people new to agile. I bet you came across that guy, great developer, really “star” in your company, who started the discussion with “Agile is a crap…Why do we need all this overhead,why I can’t just code?”. At that moment I usually open my mouth, having the intention to say something, but instead I remain silent, my face become red, blue, green and then red again. I would better keep my thoughts at that moment off this post 🙂
So, let’s talk about the misconceptions about agile I come across. Some of them are mine, as I am not a genius and started with agile as all of you.
Agile has a huge overhead – all these meetings, planing, retrospectives…
The first place is definitely for this idea, as it the most common one.
How we can be efficient with all that heavy process? (Don’t smile, developers really think “agile” is heavy, as they have to work 🙂
Efficiency is defined as a ratio of the output to the input of any system. To improve efficiency, we can maximize output and/or minimize the input. To maximize the ratio we can minimize the input, but it is definitely not what we are going to do. All the concerns about agile are somehow connected with the efficiency, so let’s discuss them one by one.
When we are talking about that overhead mean the efficiency of people’s time utilization.
If you have an ideal situation: all the tasks are identified, well described. All these tasks have no dependencies on each other If the tasks for each team member are well identified, they do not have any dependencies on each other, no roadblocks, no need to design something and collaborate with each other – you do not need meetings overhead. Things will just happen 🙂
For the teams, which time box their meetings appropriately, the overhead of all Agile meetings is no more than 10-15%. Let us check that.
One of my current teams hours statistics in a sprint:
- Planning meeting – 2h
- Daily meeting – 15 min
- Backlog grooming – 1-2h
- Demo – 1h
- Retrospective – 1h
Total for 2 weeks sprint: 8,5h – 10,6% of Sprint time.
This is a small price to pay to improve the utilization of the remaining 90% of the time. Even if you overlook the innovation aspect of collaboration, most teams are able to cut down their effort significantly through dialogue and discovery during these meetings.
No documentation, just write code
When we were talking about the changes in our processes one of the first things team said is that finally they would not deal with huge requirements and design documents. It is true, as the documentation we create now changed a lot – we create the documentation, which is needed for the development. Agile promises to remove the huge documentation overhead, so the team will be able to use this time for delivering features.
In practice, there are a lot of the practices, which appeared in our work routine, which get that time away. For example, continuous code integration does not just happen 🙂 So a part of time, saved from waterfall we have to invest in these activities.
Getting back to the documentation – agile does not mean that we won’t create any documentation. We create the documentation, which we need. How to find out what documentation we need? Just try. If you can’t work without DB scheme – create ot. And so on. You’ll find out, that in the end you have a big package of documentation. And it’s extremely valuable because it was created because of your team’s participant’s initiative and they are more willing to keep it updated.
Customers won’t participate in all our meetings, they have no time
Agile means the close collaboration with the client, and the biggest concern of the teams here is whether we could get customers who were willing to provide that feedback, work with us so closely.
In practice, clients are excited by the prospect that they could influence what we produced. Finally they don’t have to wait months before they get something they can try or for the update of their product. They have the opportunity to evaluate their ideas.
And my favorite one: N times More Features Delivered Faster
Management know for sure, that waterfall had so much overhead around project management, product requirements that is slowed your team performance. I am sure, they know. Because you was the person to tell it to them, when you tried to push the agile ideas into their heads. You told them that agile will remove all that overhead freeing up more time that could be used to deliver more feature content. So you can see a money counter in their eyes counting the profit…
They start expecting that you’ll have a blow of the velocity immediately you start adopting agile. Ok, they are smart guys – not immediately, of course, in a month or so. And when the team does not show the increase in productivity – they are disappointed.
The case is that there is no magical thing which will help our average team become a super-star. Agile is just an instrument, team, people are the case.
@tisquirrel 