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 |
|
|
| Scrum Master |
|
|
| Team Members |
|
|
(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.
/signed
Especially for organizations in transition from waterfall or even Scrum-Butt to real Scrum it's important to change the mindset while creating tasks: Highest possible code quality and test coverage should NOT be mentioned in a separate task, but be contained in each single task that leads to a Stories completion.
Really interesting article.
I can imagine there are a lot of companies that don't sell Scrum right. For example: teams are still ordered to fulfill a fixed scope in a fixed amount of time. As a team you can't fight that. It's not the fault of the team.
But from your article I understand 'Low Quality Code' and 'technical debt' are always the fault of Organizers. I don't agree on that.
A team estimates (led by their scrum master) how long they will be working on a user story. It's their responsibility to take everything account that's needed. They know how much time has to be spent to get the code right.
The Product Owner just gets the estimates from the sprint planning and knows how far the team can get. The team said they could do a particular user story in 5 points right? If that's 5 points with crap code as a result… well, maybe it was a too optimistic estimate with no space for good code.
Reading your last line again, I should discuss this at Hackernews, so I moved my comment there 🙂 http://news.ycombinator.com/item?id=3047113
As a Product Owner running scrum in an organization for two years, the crux of the articles sounds like You're Doing It Wrong.
What you describe is not the Scrum process, but rather a development process dressed up to look like Scrum and it's called Scrum, but not actually following the rules of Scrum. Sprint backlogs are locked. You don't add items to it once it starts. Plain and simple. If you do that, then you're violating a basic tentant of scrum and it stops being scrum and starts being something else.
Say no.
I agree not all teams are empowered to do this, but management is just fooling themselves otherwise.
The problem is that deadlines and budgets are easy to measure and communicate, quality is not. Of course you can put measures in place but they lack the power of dates and money. Organizers do indeed need to push back to the business and not be afraid to say 'No' – it's easy.
I agree with one of the comments, the problems described are not specific to Scrum, they apply to any development method.
May I ask how long your Sprints are? I thought that sprints would be between one and four weeks (two or three weeks where I work) and then it makes sense to lock the sprint: new features can only be added in the backlog for after the sprint. Also both our Scrum Masters and Product Owner insist that a high Level of Done is maintained, which includes comprehensive tests for each feature and all-green regression tests.
This touches on a kind of software development that I refer to as "screw your neighbor"
Which is the act of creating code debt due to the need to 'get it done' and then pass on that debt for the next guy to cleanup when they get a story that has to touch that code.
Whenever I find code that was obviously implemented in this manner and I try to find out why, the excuse is often that even though that code sucks it delivers value.
Very enjoyable read. Thanks for this illuminating post. I agree that these dangers exist. This is "real world".
As a ScrumMaster, I feel it is my duty to fight the powers that be and stand by the developers in their insistence on code quality.
However, if the organization does not truly empower the developers, or the ScrumMaster, it is indeed an pointless battle.
I think every organization is different, and what truly matters is the org's commitment to Agile.
The heart of the problem arises from the fact that in many projects the people in-charge of estimating the time/effort are NOT the people building the product (the team) but rather the senior management on vendor and customer sides! This means the estimates are often unrealistic and force teams to increase velocity (overwork for no extra pay) or cut quality. This tends to happen more often in smaller firms (struggling to retain customers), in organizations where the Agile team is but only one of many software development teams, and in out-sourced environments where the customer may push for fixed-bid contracts.
The ideal solution of course, as you point out in the article, is for the team to actively secure senior management buy-in and ensure that they have a say in providing some realistic estimates. One finds a lot less of this problem in 'all Agile' organizations where everyone from the CEO to the new-developer-on-the-block knows Agile basics and their own role in the process 🙂
"This is [every develop framework's] biggest failing [when used in a short-sighted organization] – the one knob that many Organizers are empowered and incentivized to twizzle is code quality, and usually only in one direction."
There, fixed that sentence for you.
If you define a situation where the people doing the work do not have control of the scope of the work and time for doing the work, it doesn't matter what development process is used, quality will suffer. And if, as you say, people are incentivized to meet this unrealistic restriction, quality will suffer. To call this a fault of Scrum is a bit silly.
Your solution points are great advice! Keep teaching that courage and trust are needed to create high quality products!
Regarding the idea that sprints, once planned are "set", rather than follow the idea that a project manager can add something to the top of the sprint at any time is how our company works. We feel this works for our company because it promotes the idea that sprint planning is important and it prevents the developers from feeling like their job is constantly being changed. As we all know, when you task change you lose a lot of focus and time. Changing sprints 'on the fly' usually leads to a lot of lost time and it stresses out the developers.
I am a bit surprised that the focus here is on Scrum or Agile. Why? What was so different before?
Say "Software Business – Delivering broken software since the very beginning"
In my opinion (backed up by 22 years experience within software development and management of it) it is about the culture of your organisation, not what development toolkit you are using. If your team has code quality as an intrinsic value that you as PM share with them, then the conflict interface (quality vs. delivery scope or/and date) will be between the PM and the Owners. … and this is how it's supposed to be.
Did you expect Agile approach to be a silver bullet changing everything just because you use the word scrum, have a backlog and daily stand-ups?
Don't blame Agile for lack of the culture or spineless managers. What Agile is really good at is to make these problems visible.
Very well written. Looks like you have a lot of experience working with the Agile Scrum methodology. As a business analyst, the first agile project that i worked on, failed miserably because the exact same reason mentioned above "empowerment". We were all asked to just do our jobs, and any highlighting of issues, leaks was not encouraged for some very weird reason. The result was a big failure.
I am guessing ideal conditions exist no where, but then recognizing and accepting that there is a problem is half the battle won. Thanks for your inputs.
-Amit
Great post. Another point worth mentioning, is that one of the intermediate steps in the "Do a lot of coding -> Acquire Tech Debt -> Dont get to address it -> Deliver a product" is that coding gets much slower when you're constantly fighting bugs from poor design leading to the code debt, which can lead to delays in delivering an mVp (with stress on the V). I've found that a fairly reliable warning of code debt is that time estimates on stories start getting missed, some by a couple of days. The reverse can also be true as code that is well factored can make future stories that depend on said code, easier to develop. Conclusion: taking the extra time to remove code debt with an eye to future stories actually lets you go faster.
Another boat-sinker for the Agile process is assuming that you own all the resources assigned to your project. You don't, and unfortunately this leads to college-professor syndrome: Where each college professor (manager) thinks that you can focus 100% of your time on their class (project).
The key thing about Scrum is that it's essentially a culture of quality.
And if your organization doesn't truly value quality then your poor old organizers will forever be pushed back forth between what the business demands VS what is good for the business (quality).
The best way of solving this problem is probably removing the organizers and allowing business management to experience 'software' related pain directly without any filters. That's feasible in a small company environment and that's what you usually see in a start-up but in a larger company it's likely to be pretty painful.. but highly amusing 😉
Sorry but I have to disagree with you here. Scrum does contain a mechanism whereby the PO (or anyone senior to them) can insert an item of higher importance into the present Sprint.
A good PO and/or Scrum Master, explaining the deleterious effects of doing so, will often dissuade the person from doing this in favour of placing the item on the Product Backlog with a very high priority.
I'm surprised that the PO and SM are insisting on the high level of done. A good Scrum Team will define the requirement of "done" themselves.
Scrum teams must be self managing for best effect. That's how you empower and enable Scrum.
I completely agree. The hardest battle any SM will ever have is in ensuring buy in from the senior executive management.
A good SM will run interference if anyone tries to interrupt a Sprint. Scrum allows for it to happen but the effects are so deleterious that a good SM will have no trouble explaining why it's a really bad idea.
If, in the face of simple facts, someone with authority still decides to interrupt a Sprint without a massively compelling reason (and they do exist) then you have an individual, or a company, that does not buy in to Scrum. The life of a SM just got MUCH harder 🙁
The biggest problems I encountered were not so much the situation as described; we were working together with ‘mature’ SM’s and PO’s. More so, that the enveloping Resource Management (RM) of the whole resource pool over all teams, couldn’t get used to the fact that individuals of a well organized team, could no longer be moved around from one team to another, because that actions interfere with each the team’s own characteristics. But still, RM had the empowerment to do so, at that point in time. Maybe, in near futere RM have spare time to look out of the window.
Good article though.
With due respect it seems that you did not understand the role of scrum master. Scrum master is not a project manager, it is worth studying Scrum manual for better understanding.
Having worked for a few years in Agile/Scrum environment I have seen many of the week points enumerated in this article.
While one company started a correct Scrum implementation, it quickly deteriorated after departure of some key people. It is more often that some kind of “tailored” Scrum implementation is place and according to Scrum manual if any of the key parts of the process is missing it cannot be called Scrum.
It seems in particular the Scrum master’s role is not well understood and the managers tend to impose hierarchical structure where team leads act as scrum masters. If correctly implemented Scrum can lead to a great team spirit and enjoyable working environment, it is often not so due to pressures and interference from the management.
I work in a company which adopted Scrum & Agile.
Thus writing projects is a waste of time.
We have business analysts which are having smoke after smoke and doing not much more whatsoever.
We are now having “Developer Death March”.
Deadline for alpha was 2 weeks ago and we have real hard problems even forcing the stuff to compile.
And yet, scrum managers think agile is the best thing that could happen to the company…