Checks and Balances in Agile Development

Recently, I worked on a sprint as part of our company’s scrum process. This sprint was somewhat unusual in that I was the sole developer. Not only that but I knew most of the specs in my head, so our product manager and I agreed it wasn’t necessary to write acceptance criteria for the user stories I would be working on. Since I wrote the acceptance criteria, it made sense that I would be the one who ultimately signed off on the user stories.

I hate bureaucracy so I was excited about how “lightweight” this process for the sprint was. But I found something kind of interesting.

When I was wearing my developer hat, I realized how much I enjoyed taking time to learn about other technologies. I had made a commitment to my teammates to get a certain amount of work done by a certain date, and we came up with estimates to make sure that the work was achievable.

But once I was doing it, my human nature started subconsciously looking for ways to “cheat”. I still wanted to get the work done, and done well. I wanted to be acknowledged by my colleagues for having delivered what was expected with high quality. But I also wanted to sneak in extra time so I could do more tech learning on the side.

I’m not looking to slack off; in fact, as a part owner of the company, I have every reason not to. So what I write about here is not my bad intention, it’s just human nature.

So with my goal of trying to free myself up to learn on the side with the constraint that I needed to get my work done, I started looking for ways I could shortcut my requirements. I wanted to spend as little time as possible on getting my user stories done.

Because I wrote the acceptance criteria, the scope was flexible! Because I’m the one that ultimately approved the stories, I simply declare in good faith when I’m done!

Well, ultimately, I decided to “come clean” and write this blog post. I committed no sin because I prioritized my deliverables and finished them on time. And if by sprint’s end, I hadn’t finished everything, I’d be putting in time on the weekends. So, in all ways I was still accountable for my original deliverables.

But what it highlights to me is how important it is to have the checks and balances in agile development…and probably any endeavor with multiple people.

Checks and balances in agile means there’s no unilateral decision making by a single stakeholder. I, playing the developer role, do not get to set the scope, do the development, decide when I’m done, and sign off on the quality. No matter how well-intentioned and talented I may be, human nature eventually introduces a certain “good enough” factor into the equation.

But if a product manager sets the requirements, and it’s my job to execute those to her satisfaction, then I can’t cheat, can I? If I try to just do a more limited scope, the product manager will call me out on not implementing all the acceptance criteria.

I’ll still have my desire for more free time in the back of my head, but now it’s transmuted into “how can I implement these acceptance criteria faster?” That’s going to make me a more efficient developer. That’s a good thing.

But even in this model, there’s still one aspect of unilateral decision making. I get to decide with no checks and balances how to implement the solution. Maybe I can get it done faster while incurring technical debt, but the product manager wouldn’t know that. Maybe I can get it done faster by hurrying through the problem without really thinking things through. The product manager wouldn’t know that either.

And so, even with development, my code should be peer-reviewed by at least one other person. Because then — just as I don’t want to look bad in front of the product manager — I don’t want to look bad in front of my fellow engineers. I want to have a reputation for writing thoughtful, clean code that addresses the root problem, not someone who just gets it done as quickly as possible, quality be damned.

Takeaways

• Software development often involves balancing “competing concerns”
• People are usually well-intentioned but human nature naturally tends toward “good enough”
• Make sure your agile process has checks and balances to limit unilateral decision making.