Agile the wrong way

Agile the wrong way

Does agile scale as well for bigger teams?

The company’s performance is downhill and higher management has decided after quite a bit of time and money spent on research that the process is to be blamed. The usual good ‘old waterfall model just isn’t working. We got to get a new VP. The new boss steps in and calls a meeting. The first item on his agenda is:

Let’s go agile!

Yes, you heard it. Let’s go agile.

Agile was this awesome new methodology that was supposed to increase development productivity and bring in a faster cycle of product development. Where in the traditional waterfall model, the shipping of the product took a longer time and any iteration required another long cycle of development, agile-enabled companies to ship products at the end of a shorter cycle and made iteration easier.

Small and mid-level businesses took up the idea and it really worked well for them. Hence the popularity increased overnight. Some of the bigger companies also tried adopting the technique, but with a little bit of their own flavour.

Everybody in the room is ecstatic! we are going agile! This is it, this is what is going to save the sinking ship. Communications are sent to the organisation and teams get ready for the new process. Scrum, sprint, stories and features, to be completed in two-week intervals - all this sounds so cool! Just like what I watched in the episode of Silicon Valley the other day.

But here is the catch. Even if your company implements the agile methodology, the overhead of estimation, budgeting and all other related PMO activities still remain. The only area where agile is expected is in the development phase where a developer is given a design doc and asked to code the features while keeping in mind the team’s velocity, burndown etc.

Image copyright

Even if development is completed on time, the product will not be able to go live due to inter-dependent teams and pre-defined release cycles. Integration testing has to happen before any product can be pushed into production. All this results in further delay and in the end even though agile was practised within the development team, it does not result in a product being released at the end of the cycle.

Even though companies claim to be following agile, the finance and estimation along with integration, the end to end testing and release cycles do not follow agile. This defeats the whole purpose of having implemented the agile methodology in the first place.

Agile has few problems. It creates many teams and the work is divided and distributed to these teams. This results in problems when integration does not go as planned and delays the project delivery. Before the PMO approves the budget, they need to study the benefits and approve the budget. Once the development is completed again the integration testing and release is again a waterfall since it is all dependent on the other teams as well.

Image copyright

The truth is, no one realises that something is gone wrong until the very late stage when it is too late to save the project. Teams spend a great deal of time in trying to come up with an estimate for the project that the real question of whether the feature being implemented is useful and if users going to use and generate revenue for the company, remains unquestioned and hence unanswered.

When features are planned, they are given deadlines. Sometimes when a feature development fails to complete within the deadline, it may cause a loss for the organisation. The focus should be on the features which impact the revenue and budget more and make them the priority. Everything else can wait.


The agile methodology was introduced so that developers get uninterrupted time to focus on the work. But today we see developers being dragged into all kinds of discussions, meetings and calls. What this does is that it takes away the valuable productive time which naturally should’ve been spent writing code.

I read a great analogy on StackExchange on why a developer should not be interrupted when he is neck deep in coding.

“How long does it take for you to fall asleep?” “X minutes” “Now imagine that when you are close to falling asleep, someone walks in and interrupts you, how long will it take you to fall asleep now? Those few seconds you had left, or will you have to start again to ‘sink back’ to where you were?” “I’ll have to start again” “Great. Same thing. Just like falling asleep, it takes me a while to ‘sink’ into focus mode, and it takes me a while to get back to it once I’m interrupted, except that I also forget half of what I was doing.”

So as you see, once you take away someone’s focus, it takes more time for them to settle back to that same focus mode. In an office, there are many distractions that come your way. But within an agile team, developer focus is super critical because developer’s time is what converts to money at the end of the product development.

This also means reducing the meeting times and ensuring that they aren’t part of too many meetings other that the daily scrum. Also, it helps to allocate some time aside to account for interruptions. Anything that needs to be discussed can be done during this dedicated time. Scrum has to be followed strictly.

Multitasking doesn’t work when a developer is working on something, there comes a ping from the manager or someone else asking for a status on something that was discussed two weeks ago. The fact is that it might not be an urgent thing, but because it was over IM, it seems like it deserves some amount of urgency. To respond back to the chat, they might need to go back and dig up emails from past couple of weeks and this results in loss of focus.

If you really want to implement agile, start by ensuring that delivery teams (Dev and Test) get uninterrupted time to do their work. If you keep pulling them into meetings, you might not see the results that you might expect from them. Agile really needs to favour the developers and not the managers for their meetings and calls.