What it takes to understand the actual meaning of agile
And how we are still stuck in waterfall thinking (most of the time)
Nowadays “agile” sounds somewhat close to “meditation”: everyone talks about it, common sense states that it’s good for you, however there is no ready-made recipe for it as it’s more about the lifestyle than particular action and thus the number of methods it can be applied in is only limited by the number of people applying it. Let’s see what it takes to go through all the discussion around agile and understand the actual meaning of it in practice.
Going through numerous opinions on the web, you might encounter several points of view that can be surprising and even confusing. For instance, that agile is the new waterfall or that scrum doesn’t get you any closer to being agile. In fact, the more you read the more you see that it is easier to understand what agile is not, than to find any clear description of what it is — beside agile manifesto itself, obviously.
So as you have actual project to manage, there are still questions remaining: how do I do it agile way? What form should it take?
Here is one recent example we had when we clearly saw that going agile is required and we were sure it would bring good result:
We took over a large mobile app development project that was going on somehow, however a lot of processes were blocked due to communication issues: almost all the decisions on the project were supposed to be approved by managers, who were too busy to do that because there were just way too many approval requests. Сheckmate.
Another thing was those endless question lists that were passed from one person to another within this remote team without being answered completely and sometimes being lost on the way.
And it was not that the team was unqualified or unwilling to work, the system was broken: communication gap resulted in unsystematic development.
As we analyzed the situation, we also found that team tried to go SCRUM, but that remained on the outer surface: standups were forced by management and thus boring, retro had no effect whatsoever as not a single improvement was introduced as its result.
First thing first: we focused on communication. To make things work we needed to involve developers and transform unworking pyramid into flat working space.
Decision making was passed to team members, who got equal rights and responsibilities for the process.
As everyone got their responsibility areas now, standups and retro started to make sense: if I have a right to decide on my part of job and I am personally responsible for it, there is a lot of involvement and there is a wish for others to do their parts of this project right so that the whole thing would succeed.
We introduced SCRUMBAN: a system that is a crossroad of SCRUM and KANBAN. The reason we chose it was that team already had some idea of SCRUM, that is suitable for project scope planning and making sure common activities are regular, and KANBAN is the best way to remove communication obstacles from which the project suffered. Basically, we didn’t force anything: we just tuned it.
The changes resulted in productivity increasing by at least 30%, better decision making and higher team members’ involvement.
What we learnt from this experience is that going agile surely means broad thinking, a lot of analyzing and taking particular team members and project into account. Agile is about things working in such way that feels natural to everyone yet is actually thought-out and tailored. Forcing anything is surely not agile, so in that sense if SCRUM is not understood and accepted by the whole team — yes, it actually can’t be called agile.
And sometimes kind of waterfall can be also present: that is when there is a large long lasting project that requires a lot of effort — in such case it makes sense to divide it into micro and macro levels, with different methodologies each — agile is good for day to day thing whereas plan-based approach goes well for large scale management.
The main thing agile approach actually teaches is in its very name: it teaches us to be agile, — and first of all to be agile in thinking and approach. Saying agile and pushing something is so waterfall-like!
Yet analyzing the team, project and seeing what would go well and result in responsibility, involvement and fast development is what agile is actually all about. It takes a lot of learning, admitting one’s own mistakes, listening and comprehending, initially it might take much more effort that plan-based management, however it’s all worth the sweat: agile approach surely brings better result in shorter time than whatever methodologies were there before. It might change in 5–10 years, but today this is the path to success.
Here at RentaTeam we’re always glad to receive feedback from you, so please feel free to contact us.
