Agile Scrum: Delivering Broken Software Since 1991

September 28, 2011

Update: This is quite a long article. If you’re looking for a quick read, it breaks down a bit like this:

  • The first third of this article describes Scrum
  • The second third describes how it gets subverted to produce broken software
  • The final third is where the practical advice for avoiding this is – whether you’re an Organizer or you’re an Activist Developer – you could potentially just skip straight there if you’ll be bored to tears by the first two sections…

Update 2: There are active and interesting discussions of this article on HackerNews and Reddit

I have a lot of love for Scrum, the software development process. I have my own little box of Index Cards and Sharpies, and I have sized Backlogs for many of my side projects. Scrum has potential to empower developers more than almost any other set of techniques.

But in almost every implementation of Scrum I’ve seen in The Real World™, managers are incentivized to help their team deliver broken software to a deadline, and usually end up succeeding in the former and failing in the latter. And when implemented like that, a system that should be an absolutely overwhelming win for developers becomes a tool to beat them around the head with…

Scrum Basics

So here’s Scrum, simplified, and as it’s meant to work: You have a Backlog of work to complete, broken down in to Stories, which ­are distinct pieces of work that should take a few hours to a few days to complete. These are frequently displayed on a Story Board, real or virtual.

You have some actors:

Role Also Known As Responsibilities
Product Owner
  • Producer
  • Business Analyst
  • Internal Customer
  • Generating Stories for the Backlog
  • Prioritising Stories already on the Backlog
Scrum Master
  • Project Manager
  • Managing the Scrum process
  • Removing development impediments
  • “Facilitation”
Team Members
  • Developer
  • Designer
  • Tester
  • Sys-Admin
  • Breaking Stories down in to Tasks
  • Estimating Story complexity
  • Doing the work…

(Any time someone tells me that a Cross-Functional Team means the QAs and Designers should be programming, I try to explain to them that they shouldn’t be anywhere near the development process – it’s better than jabbing them with my Biro. Generally – and a little sadly – you’ll only hear this rubbish from Agile Consultants.)

You have a Sprint which is a short-ish time period, typically two-three weeks, and you have Story Points assigned to each Story based on complexity, which are specifically not time-based estimates. You have a Capacity, based on your Velocity, which says how many Story Points you have historically completed per Sprint, and thus how many you expect to complete in the next one.

Now here’s the awesome part, in theory, for the Developers. The Product Owner prioritizes every story sequentially. And in this way he/she gets to ‘spend’ your Capacity – and only up to your Capacity – each Sprint on the Stories they want to get completed. They’ve got a budget, and they can only spend that budget, and no more.

And any time a piece of work that’s super-duper-mooper important comes in, someone writes a Story for it, and the Product Owner places it where they want in the Backlog. If they place it above any of the work you’re intending to get done this Sprint, something has to drop off the bottom. As a Developer, you can illustrate this beautifully, in front of them, by removing Story Cards from the list of items you are intending to complete this Sprint.

(Some people say that this should never happen – once the Sprint is planned, it’s sacred, and that any changes to it need full team buy-in – any significant number of changes need a complete replan of the Sprint. I’ve not seen this so far in practice, but it sounds intriguing.)

This empowers Developers tremendously. Stories cannot be ‘snuck in’ or their lack of completion put down to Developer laziness or disorganization.  This gives Developers all the right kind of accountability, and removes from them the responsibility for owning a time-machine when Feature Creep starts to bloat a project.

When it comes to crunch-time on a project, the Developers can show that they’ve been working efficiently, effectively, and to deadline, and push back against the idea that they should be morally obligated to start putting in long hours because they “didn’t get the work done”.

But…

If the Organizers (the ScrumMaster, and in most teams I’ve worked on, the Product Owner) of the team is unhappy with how new Stories will affect a deadline, they can – according to the Agile canon – change three things:

  • They can change the scope of what needs to be delivered by de-scoping Stories they think aren’t so important;
  • They can add extra Developers with the (often misguided) hope it’ll increase capacity;
  • Or they can change the deadline.

Which bring us to the central problem, and what this article is really about: The Organizers are rarely empowered to change any of those thing, so they change the one thing they can, but shouldn’t: the build quality.

How Under-Empowered Organizers Can – and do – Screw Up Scrum

The Organizers’ incentives are broken in most organizations. The Organizers are incentivized to get projects out of the door on the original deadline, at the original price (ie: staff levels) – if they deliver this, they’ve done their job well. When bugs, corners cut, and ungodly amounts of Technical Debt start to surface, all too often this is attributed to Developer incompetence…

(In the small number of software projects with sufficient number and quality of dedicated test engineers / QAs, observers will notice how what constitutes a bug of release-blocking severity starts to change as the deadline approaches. But in the unlikely event you have enough testing resource, you’ve probably also got a fairly enlightened organization supporting your work…)

Taking Feature Creep and Unexpected Events as a given, there will come a point in the life of almost every project where it becomes clear it can’t be done to the original estimate, with the original resources. This appears to be an absolute constant in software development.

And this is the point where the Organizers need to find a solution. The most appealing solution is to find a magical wand that will somehow increase perceived Developer productivity or Velocity, and this is where Scrum usually suddenly morphs from an incredibly useful tool for Developers and Organizers alike in to a world of pain.

How do you magically increase Velocity? Here’s how: any tickets the Developers have created that represent code quality are history. Code quality is a “nice-to-have’ if this project is going to be delivered on time, sorry. If dropping the automated testing tickets means the project can be ‘released’, and the alternative is a delay or the Organizers having to ask for more resources, all too often those tickets are toast. Finished a feature, but now it needs proper documentation?  Suddenly it can wait until after the release.

Before you know it, the project is leveraged to all hell on Technical Debt, and the result is a shitty product.

This is Scrum’s biggest failing – the one knob that many Organizers are empowered and incentivized to twizzle is code quality, and usually only in one direction.

But…

If your Organizers are experienced, talented, and confident, and have buy-in from the rest of the business, the effect of this will be minimized. Developers will be shielded from the heat, and allowed to get on with building an excellent project. Teams like this exist – a client I’m currently doing some work for are really good at this – in no small part due to absolute buy-in in to Doing Scrum Right that goes from the Board level downward. This is rare, though, and even they don’t always get it right (but they do offer free pizza, time off in lieu, and heart-felt thanks when Developers work weekends – time off in lieu dwarfing the others in importance).

Rescuing the Scrum

The Right Solution

The right solution to this problem is unambiguous business and customer buy-in and visibility – a situation where the business allows and trusts the Developers to be the guardians of code-quality and estimates, and it deals with “business realities” regarding deadlines – by managing resources and customer expectations properly.

The right solution to this problem also involves incentivizing the Organizers properly by making them accountable for code quality – both via honest feedback from Developers on the level of Technical Debt added, and from a perspective of how much continuing support the project requires after it’s “released”.

The Activist Solution, for Developers

In lieu of being able to do the most, there are some activist options for Developers wishing to take matters in to their own hands:

Firstly, stop highlighting time spent maintaining code quality. If your test and documentation tickets get consistently de-scoped, stop displaying them differently, and start padding out your estimates to opaquely contain them. Task estimates belong to Developers, and to Developers alone. If Organizers challenge them, offer to put their estimate on the story too, and “we’ll see how long it takes”.

This is – obviously – antithetical to the Agile ideal of transparency and clear communication. But so is squeezing code quality to make releases. Be like the Internet, and simply route around the damage – you have a responsibility to your co-Developers and to the customer here as a software professional.

Secondly, if your Backlog doesn’t highlight that adding items to it knocks items out of the Sprint, do something about it. Make sure that views of the Backlog contain a marker that shows where the team capacity for the Sprint is. Move that marker to reflect the work that can actually be achieved every time new Stories are added to the Sprint.

Essentially: start encouraging your Organizers to confront as early on as possible that the work that needs to get done may not fit in the time available. The sooner that that crops up as an unavoidable issue, the more time there is to find a real solution. The longer everyone ignores the problem, the more likely it is that the closing Sprints will become Developer Death Marches™.<

Thirdly, start keeping a note of areas where you've had to sacrifice on code quality, and where you’ve created Technical Debt. Create Technical Debt stories to represent this, and insist they go on the Backlog, even if “they’ll never get done”. Find the person who is pushing Agile in your organization, and if they're even slightly empowered, enlist their help on this. Find the person who has ultimate ownership of the wider codebase, and make sure they have visibility of the Technical Debt you’re creating, and why.

Some level of Technical Debt is acceptable when you have a tight release schedule. But hiding the creation of Technical Debt is criminal. Make sure it’s out in the open for everyone to see.

Fourthly, start and relentlessly pursue a discussion on what Done means to your team. When is a piece of work truly Done? Is an untested feature really Done? Is it really releasable? What are the impacts for the company and customer on releasing code in which you have little confidence? Hammer out a team statement, with as much Organizer and business buy-in as possible (if you don’t have one), and print it out and stick it on your Story Board.

The Final Option, for Developers

Leave. The world is crying out for talented developers, and if you care enough about the software development process, you probably fit in that category. There are many places making bona-fide efforts to do this the right way, and a few well-placed questions at interviews (“How does the business deal with it if not all stories have been completed in a Sprint?” – I had a potential client tell me that all work HAD to be done or developers didn’t go home… every Sprint) should help you work out which is which.

{ 21 comments… read them below or add one }

Leave a Comment

{ 1 trackback }

Previous post:

Next post: