Every young American grade schooler learns about the Systems of Checks and Balances here in the USA. It’s the idea that the top decision making power in the federal government is split into the Executive Branch (the President), the Legislative Branch (Congress), and the Judicial Branch (the Supreme Court).
In most cases, no one branch can unilaterally do anything. Sure, the President has some ability to unilaterally make decisions, but if such decisions are happening, we hardly ever hear about them.
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 “accepted” 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 have committed no sin because I have continued to prioritize my work and I remain on track, and if come Friday I haven’t finished everything, I’ll be putting in time on the weekends. So, in all ways I’m 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, but I hurry 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 engineer. 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.
- The USA government has used the same fundamental system of checks and balances for 250 years, so there must be something to it.
- Agile software development is no different.
- People are usually good intentioned but human nature naturally tends toward “good enough”
- Make sure your agile process has checks and balances to limit unilateral decision making