Agile is a Trojan Horse
You may have heard about Agile Development. Maybe you’re on an Agile team too. Every team I talk to talks about how Agile they are. However, this typically just means that the team releases software often, adapts to ever changing requirements, and measures progress by measuring how much working software has been produced. Yes, these are several of the hallmarks of Agile, but they dont even represent a minimal subset. Sometimes, they say they’re “little-a agile” to denote the fact that there’s no real process there. The lack of process is called out as “a good thing”. “After all, isn’t one of the tenets ‘People over Processes’? Aren’t the benefits all for the business side while making devs undergo this cumbersome burden?” Thankfully, the answer is no.
Agile done well is a Trojan Horse for developers, delivering solutions to common developer complaints while also delivering value to the business.
Understanding the Concerns
This reluctance to add process, specifically lightweight estimation with sprints, stems from several places:
- fear that sprints introduce deadlines and unnecessary pressure on the team.
- misunderstanding the benefits of planning and estimation to the developers involved.
- misunderstanding the autonomy that comes from sprints.
- overestimating the actual amount of flexibility required by the product being built while underestimating the flexibility that sprints allow.
We’ve all been there: A few weeks (or months) late on a software project with ever-growing scope and no end in sight. Deadlines are a developer’s worst nightmare, right? Described this way, of course they are. The Trojan Horse here is that sprints are measured in days, with well defined scopes, daily progress updates, and little consequence for failure other than factoring history into your next estimates. This can barely be described as deadlines. It’s more like a safe space to refine the craft of software estimation and measuring what’s left. Sprints mean lots of mini deadlines, which effectively means you’ll never encounter the deadline disaster scenario described above.
“How long will it take to build <insert nebulously defined, extremely complex thing here>?” You shrug your shoulders and say “6 months?” Disaster achieved. Given this description, estimates are an activity typically avoided by developers because they form the basis for the dreaded underestimated deadline from our previous example. The Trojan Horse here is that with sprints, you’re only estimating for 1–2 weeks worth of work. The tasks are small. Tasks that seem too big to effectively estimate can be reasonably broken down. When team members disagree on the estimate, the details are discussed until everyone agrees that the task is clear. This allows devs the freedom to pre-plan, see the road ahead of them, get clarification from stakeholders and designers, and ultimately get clarity on what they’re doing. Small estimates become easy. The picture gets clearer. Devs win by estimating.
“I never get to work on technical debt. I’m always building new features. I never get a chance to go back and improve a systems design”. Because teams without sprints underestimate deadlines, don’t cultivate backlogs, and make plans way too far into the future, people are either constantly in service of the big goal, or hop from small project to the next, with no real way to advocate for any other work. Leadership, with little insight into what’s actually left, has no way to even approve this other work because it’s impossible to predict how it affects the lateness of the project. The Trojan Horse here is that sprint planning provide a space for devs to advocate for anything they want to do. Of course, this comes with the burden of requiring them to prioritize and bargain against business value, but that’s the point. Devs learn that they can’t always work on debt and why, and business learns the same thing about feature building. The team, together, has decided what debt and what features to go after for the next few weeks. Autonomy.
“I have 5 top priorities, none of which are my top top priority. I heard that we’ll be tracking top top top priority soon”. Believe it or not, this stop-on-a-dime-and-change-directions level of flexibility is often lauded and cheered by leadership. However, it’s almost always disliked by devs. This desire for flexibility from leadership is the final domino falling from the lack of process already discussed. Because there are unrealistic deadlines, with little true scope, with teams who are “plug and play” from one mini project to the next, the only solution is to be “flexible”. The Trojan Horse here is that sprinting teams can choose to take on unplanned work in the sprint, but only when the new work is estimated and has been proven to the team to be so urgent (not necessarily important) that it cant wait till next sprint, which on average is only a few days away! It forces teams to evaluate urgency (which is about “when”) vs. importance (which is about “why”). You can always schedule something important that isn’t urgent. You can always push back on something that may not be as urgent as it seems. See http://jamesclear.com/eisenhower-box for more info about dealing with urgency vs. importance.
Adding sprints and estimation to an Agile team is as much about dev happiness as it is about productivity for the business. Devs gain autonomy, insight, direction, and mastery from the simple acts of not promising without measuring, and only measuring as far as they can see.