Half-arsed agile

Transitioning to agile is hard. I don’t think enough people are honest about this.

The other week I went to see a team at a company. This team are incredibly typical of the teams I go to see at the moment. They’d adopted the basic agile practices from a ScrumMaster course, and then coasted along for a couple of years. Here’s the practices I saw in action:

  • having daily stand-up meetings
  • working in fixed-length iterations, called sprints
  • tracking their work as things called Stories
  • estimating their work using things called Story Points
  • trying to predict a release schedule using a thing called Velocity

This is where it started to fall down. This team have no handle on their velocity. It seems to vary wildly from sprint to sprint, and the elephant in the room is that it’s steadily dropping.

I see this a lot. Even where the velocity appears to be steady, it’s often because the team have been gradually inflating their estimates as time has gone on. They do this without noticing, because it genuinely is getting harder and harder to add the same amount of functionality to the code.

Why? Sadly, the easiest bits of agile are not enough on their own.

Keeping the code clean

Let’s have a look at what the team are not doing:

  • continuous integration, where everyone on the team knows the current status of the build
  • test-driven development
  • refactoring
  • pair programming

All of these practices are focussed on keeping the quality of the code high, keeping it malleable, and ultimately keeping your velocity under control in the long term.

Yet most agile teams, don’t do nearly enough of them. My view is that product owners should demand refactoring, just as the owner of a restaurant would demand their staff kept a clean kitchen. Most of the product owners I meet don’t know the meaning of the term, let alone the business benefit.

So why does this happen?


Firstly, everyone on the team needs to understand what these practices are, and how they benefit the business. Without this buy-in from the whole team, it’s a rare developer who has the brass neck to invest enough time in writing tests and refactoring. Especially since these practices are largely invisible to anyone who doesn’t actually read the code.

On top of this, techniques like TDD do –despite the hype– slow a team down initially, as they climb the learning curve. It takes courage, investment, and a bit of faith to push your team up this learning curve. Many teams take one look at it and decide not to bother.

The dirty secret is that without these technical practices, your agile adoption is hollow. Sure, your short iterations and your velocity give you finer control over scope, but you’re still investing huge amounts of money having people write code that will ultimately have to be thrown away and re-written because it can no longer be maintained.

What to do

Like any investment decision, there’s a trade-off. Time and money spent helping developers learn skills like TDD and refactoring is time and money that could be spent paying them to build new features. If those features are urgently needed, then it may be the right choice in the short term to forgo the quality and knock them out quickly. If everyone is truly aware of the choice you’re making, and the consequences of it, I think there are situations where this is acceptable.

In my experience though, it’s far more common to see teams sleep-walking into this situation without having really attempted the alternative. If you recognise this as a problem on your team, take the time to explain to everyone what the business benefits of refactoring are. Ask them: would you throw a dinner party every night without doing the washing up?

Does the world need to hear this message? Vote for this article on Hacker News

Published by Matt

I write software, and love learning how to do it even better.

Join the Conversation


  1. Nice post Matt. Glad you raise the point that starting TDD will result in a down-turn in output. In fact, the same will have happened when they first started Scrum – if only they could remember that far back.

  2. Your lucid post really hit the spot. I hope my team reads and appreciate your pragmatic first-hand point of view. Thank you!

  3. Are you sure the reason you see a slow down isn’t because the code base is increasingly complex to maintain and add features to?

  4. Hit a bit too close to home to be totally comfortable – which is a good thing.

    “would you throw a dinner party every night without doing the washing up?”. I’m always looking for analogies, and that one is pretty good, thanks!


  5. You’re right. I work in a scrum team that never refactors; it’s basically waterfall crammed into sprints with developers & product owners falling into ‘old school’ habits. Testers & tech writers are left, as always, to pick up the pieces by accommodating for the shortfall.

  6. Hit pretty close to home, I seem to work with developers that really worry that they have to do refactoring, and that its seen as a bad thing.

    As Lola mentioned, it feels like we have just crammed waterfall into two week sprints.

    We are new at this but I really do hope that we take important lessons like this in.

  7. Great article and absolutely bang on. I have been a delivery manager with agile teams for a year since we moved from Waterfall and for the first 2 months we were agile, including refactoring and TDD. Then our scrum master left. A director decided we didnt really need one, we all chipped in to “fudge together the bits of the scrum masters role we thought were needed and didnt bother with the rest because “we knew what we needed to be agile”.


    We are now in the process of hiring a new scrum master and completely redoing our Agile process using renewed Agile training after 4 or 5 months of total collapse and chaos where (as you so rightly stated) our velocity fell, we couldnt be arsed to refactor or TDD and fell back into chaotic 2 week waterfall.

    Get it right, do it all and keep doing it all. Its ALL needed to keep agile going.

Leave a comment

Your email address will not be published. Required fields are marked *