You are here

Agile is dangerous, apparently.

graham's picture

A friend of mine posted a link to this article on facebook: and the comments were promptly filled with engineers of my acquaintance agreeing vehemently and in one case suggesting that the looming Agile Spectre would make them consider leaving to get something less well paid rather than be so mistreated.


My job is Atlassian Software Expert (or admin, or SME or Super User, depending). Atlassian products are built to support Agile and DevOps. So naturally I was a bit skeptical at the (not totally unexpected) reaction. If the whole concept is so toxic it regularly sinks companies why is Atlassian so successful? The article is well written and addresses a lot of problems, my observation is is that they aren't actually to do with Agile. I suspect if a companies stock dropped 90% in two years there might be more than one factor at play.


TL;DR - Agile takes a long time to show consistent benefits. Agile isn't evil and doesn't destroy your company. Agile does promote interactions that techies generally dislike. Making unrealistic demands of your workforce causes emotional burnout, Agile can be used to make unrealistic demands, so can any other working practice. Agile is not the cause of you losing your personal space. Arseholes are everywhere. You aren't being personally attacked by a concept. 

Agile causes stress, not exactly...

Personally I think it's immensely important to manage stress in the work place. There are many things that cause stress but deadlines are pretty high up on the list. Having a two-week recurring deadline does seem like a bad idea, right? That's because you haven't understood that sprints aren't deadlines, they're defined periods of time where you estimate (ie guess) how much work you might achieve. If you are attempting to do Agile properly it's an all-or-nothing decision. It's not one that should be taken lightly and definitely not used to try and improve reporting numbers and deadline-meeting in the short term, why? Because if you are doing it right your numbers will look awful for months if not a year or so and you will consistently overshoot your sprint. Not once or twice but lots. The point is that over the course of Quite A Long Time you get a sense of the average amount of work done in terms of it's complexity. People will work at their level of comfort and there for, in the long term, more productively. This is a lesson businesses repeatedly fail to learn and why Agile is such a contentious concept in development communities which fail in thier part to realise that Agile isn't the problem, not doing it properly is the problem. Not doing it properly and expecting immediate results is madness. It's especially important to realise this if you are the victim of mismanaged implementation, it's not the process at fault it's the people who have decided to make it happen for the wrong reasons and/or badly.

It's perfectly fine to be of the opinion that Agile is fundamentally flawed and if you find yourself stuck with it when you hate it I'm genuinely sorry for you, and I hope you find a way out. In this sense it can cause stress as it doesn't suit everyone, but it doesn't in and of itself cause people to burn out any more than a business dress code causes mental trauma in people who have never had to wear a suit before. Some flexibility is necessary to keep in work. 

Sprints are not deadlines, deadlines are deadlines

When you put people under the cosh to have all stories completed by sprint end this is going to cause a lot of pain. Sprints, initially, should be quickly estimated and left to run. If your stories aren't complete by the end of it you look at the reasons in the retrospective and you plan less work for the next sprint. Then iterate. If you are pulling your engineers into performance meetings because they have five story points against their name come sprint end your problem isn't with Agile, it's with your performance management policy. If it's business critical that work is finished by x deadline and there isn't capacity to do so, your problem is your business is overstretched and no working practice is going to change that unless you figure out why it's happening (you might not have enough staff or awful tools or indeed the wrong process but changing it fundamentally at this point will not help). This happens anywhere, deadlines inspire stress. The solution: react by extending your deadlines (not sprints) out to meet the cadence of your teams and manage the expectations of your customers. Measuring cadence is what Agile does well as long as you give time for the cohesiveness of the teams to establish. As your general sense of what you can manage solidifies the estimations will become tighter and more realistic. You can set deadlines with some confidence of achieving them. If your deadlines are set by external forces and you cant meet them something needs to be added so you can. It's not a problem Agile has set out to solve. If you want to squeeze every large ounce of day-to-day productivity from your workforce, you're not doing Agile. You're Amazon.

The trend is your metric, not the numbers

The most common mistake I've encountered is that of ascribing a tangiable time-value to story points. This goes against the basic principle of Agile and is the root cause of most of the other problems. Businesses like metrics, they like to see numbers change each period, upwards for some things (productivity, profit) and downwards for others (rework, loss). Agile acknowledges this and suggests that you measure the change rather than the actual numbers. This is because everyone has a different idea of what they can do, and groups of people who work togther form consensus over time. 

Fear of missing out will kill you, not Agile.

One repeated criticism of Agile is the lack of personal achievement measured in your personal contribution to A Thing. If this is why you hate Agile I'm going to suggest that Agile isn't your issue. Your desire to be the creator is. Agile (and DevOps) addresses the issue of gatekeepers, Lords Of The Product and routine information concealment. This hits people right in the imposter syndrome and if the only fulfilment you can get out of work is being the one that wrote The Thing and is the only one who knows how it works then I suggest you invest some of your frustrated energy in addressing how you obtain your self-worth. You may feel that you don't have to because you are smart, good at coding and already know a lot of things but trust me learning to listen to other people is the greatest productivity booster you'll ever have. Learning to take criticism makes you more valuable not less, you'll feel more involved too. You just won't be a Rick (, this is a good thing.

Things that agile isn't but often is often associated with

Open plan offices/lack of personal space

Micro reporting

Working from home

Company-melting crises


If you really need your own office I suggest you look at a company that lets you work from home. Ain't nobody got time or money to give everyone a cubicle, office etc. Invest in some good earphones. Learn techniques to manage and reattain your flow. Recognise you own behaviours that break flow and exploit them. Interruptions are a reality of work, learn to manage it, it's possible. It's all useful, transferrable skills into the bargain.

Micro reporting comes out of the tools often used with Agile. This is where I agree the wrong thing is emphasised routinely even when it's otherwise being done right. That said you'll always have important people who need to know so it's unlikely to go away. FWIW all my experience of invasive micro-reporting came from non-agile environments and was costly in time as there were few common metrics necessitating time spent actually creating the reports. In the better agile environments teams produced good-looking reporting that satisfied most important people and didn't individually blame anyone, often automatically.

Working from home. I've been amazed that engineers who dislike open-plan offices and talk keenly about flow and productivity seem to actually *hate* working from home. All I can surmise is that this means that *they* should be left in a room uninterrupted but when they need something they should be permitted to interrupt someone else. All engagements must be their way, on their terms. It's only fair isn't it? The mind boggles.

Companies do tend to try and implement agile when things are looking bad because someone has sold them whole cloth. Agile doesn't solve massive downward trends in productivity or your app falling flat on it's face. If you believe someone telling you that you only have yourself to blame. My personal experience is that it's most successfully implemented by companies that are stable, profitable and ready and enthusiastic for a change or new companies that haven't got a process yet.

If your company is going downhill fast switching your entire working culture is only going to increase that velocity. You problems are too complicated for an off-the-shelf concept to solve. None of the actual Agile principles say it will, only consultancies looking to make a buck out of your crisis. Companies meltdown all the time, they do it while doing waterfall (whatever *that* is exactly), extreme programming, do-it-all-inna-wiki, working from bedrooms, having desks with wheels, doing agile at scale with three-day sprints.

I guarantee none of those things are the root cause of failure and I'm sure no company had a significant percentage of their developers leave due to agile being implemented. Pointing at a company and saying "look they died on their arse and, ooh, did agile" is the sort of anecdotal bollocks most of the critics I've seen wouldn't tolerate in any other context.

If you don't like agile, don't work for companies that do it, simples. It might dramatically reduce your employment prospects but if you're right those prospects should bounce right back up after most of the IT sector collapses because everyone is like you and won't do Agile because it's toxic and literally kills people. Once that's all sorted out you can all go back to building your "Thing That I Made, me, just me" in the company of other people that aren't as talented as you and don't deserve credit for Your Thing.