There is an age-old struggle in software development between getting things done fast and getting things done right. One of my biggest concerns about our industry’s new love affair with Agile Process is that Agile rigs the rules of the game to always favor the “do things fast” side of the debate.
How does Agile rig the game?
First, Agile requires us to describe the entire project in terms of what the user can see — “user stories”. This leaves no (official) room to think about the project from a technical implementation perspective. It would be as if the construction of a house were defined entirely in terms of color choices and flooring options, with no consideration made for the strength of the foundation or the structure.
Second, Agile requires us to “commit” to completing a set of user stories each sprint, again with no official space provided to work out technical details that the user can’t see. This would be like asking your contractor to get those granite countertops installed by week 2 of the project, even though the plumbing and electrical aren’t hooked up yet.
By describing the entire project in user-visible chunks and rewarding the team for completing its commitment to code up a batch of them each sprint, we create huge incentives to “just move the cards”, rather than to build quality software. This process tells your developers that when faced with a decision to implement a card in a quick and dirty way that allows them to complete the sprint versus a better way that would push the card to the next sprint, they should always default to choosing the quick-and-dirty, finish-the-sprint method.
How do we level the playing field?
I should note that I am not in favor of always choosing the “right” way instead of the “fast” way; I simply think that the decision needs to be made intelligently and thoughtfully. It certainly shouldn’t be made for us by the artificial time pressure of a sprint deadline. Therefore our goal should be to level the playing field so that we can make an intelligent choice on each fast-versus-right question. However, because agile tips the scales towards “fast”, we need strategies to tip it back towards “right”:
- Pad your estimates. Every Agile developer learns this one pretty fast. Inflating the estimate for a user story when you know you need to do some related (or perhaps unrelated) technical work is the easiest path to working within the Agile process while still doing the technical work Agile doesn’t want to recognize.
- Include technical work in your sprint. While it is very good to write up user stories and understand exactly what the users want, that shouldn’t mean that we can’t write up technical “stories” that describe the “invisible” work that needs to be done to do the project “right”. By openly discussing technical issues and including them in your sprint planning process, the importance of these issues is automatically elevated.
- Be willing to miss a sprint. Sprint deadlines are arbitrary. Don’t let yourself feel bad about occasionally missing a sprint in an effort to complete work in a technically sound way. You are the developer, ultimately it is up to you to decide how the code should be written. Take advantage of this power.
- Communicate with your entire team. Constantly discuss the fast-versus-right tradeoff with the entire team, developers and non-developers alike. Explain the downsides of implementing something the hacky way. Explain that spending an entire sprint on implementing a single user story the “right” way will allow you to implement seven similar stories next sprint.
Agile creates rules that rig the game in favor of fast development. By understanding this, you gain the power to bend the rules back towards good development, ideally creating a level playing field where everyone on your team can have a real conversation about the tradeoffs of each fast-versus-right debate.