Mastering Scrum: Wisdom Perceived or Received?
Matthew Brumagin, Accusoft Software Engineer II
Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. (Scrum Guide)
I would like to do a little bit of myth-busting of a few conventions/processes I've seen implemented because "they are best practices" instead of being based on the context of how a team works, what they work on, and what they can change.
1. Continuous Delivery
The theory of continuous delivery is very simple: release early and release often so that customers can get new features and fixes, ideally as soon as they are completed by the development team.
In fact, Agile's first core principle states: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
The word I'm going to focus on here is "valuable." If the customer is not aware of any fixes or features that are added, are you providing value? If there is any manual work associated with delivery, you may be wasting time releasing your code to production. In the case of incomplete feature-functionality, the value is also in question; additionally, you may be compounding waste when reworking large portions of code as well as the automated test coverage associated with that code (since you'll likely want to have automated tests for anything released to production).
Scrum states: "The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team's current definition of 'Done.'" So, Scrum only requires that each Sprint be potentially releasable and that the releasable work adheres to the team's definition of "done."
This is one of the harder decisions that teams face: how often is it really necessary to release? The Scrum Guide conveniently answers this, very simply: "Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback."
So, before deciding to release as often as physically possible, determine if this makes sense within the context of your team's project. Will this give the team a better feedback loop? Are there any beta customers or acceptance testers? If there are, will they test on a separate staging environment?
If you don't have a staging environment, you will ideally need to have automated tests as well as documentation as part of your definition of done, which could result in a much larger cycle time (which can make your sprints less predictable). However, you will want to weigh these against the additional overhead of managing a staging environment and production releases (which should be their own stories in this case).
Another common problem is the introduction of unnecessary technical debt. Without a staging environment, even prototype or proof-of-concept code will make its way to production. Now, instead of plain technical debt, there is a maintenance cost.
2. "Hardening" Sprints
Speaking of technical debt (which probably deserves its own article, really), there is at least one major anti-pattern as far as Scrum is concerned. Specifically, that of "hardening"/"debt"/"technical"/etc. sprints. This is the magical sprint where your manager/director/team lead/other-role-not-identified-by-Scrum swears that you'll catch up on some of that pesky technical debt.
Here's what the Scrum Guide has to say about that: absolutely nothing. But doesn't it sort of bother you? You're going to accrue compounding debt (bad code begets bad code) while you try to release feature-functionality, which then has to be maintained. To me, this is the business equivalent of becoming an Uber driver by purchasing a car on credit, then hoping that you can get enough customers to pay off the debt you've put yourself in, all while neglecting the cost of maintaining the car long-term.
So, since the scrum guide says nothing itself, we should fall back on the often-forgotten foundation on which the Scrum framework was built: Agile. From Agile's core principles: "Continuous attention to technical excellence and good design enhances agility."
The keyword here is "continuous;" you should not defer technical excellence and good design. For one, your developers will actually lose sight of all of the technical debt (even if they're creating stories for every little refactor); it's usually easiest to fix a problem that's fresh in your mind.
Additionally, after they realize these technical debt stories never get prioritized (because these aren't providing immediate value to the customer), a few things will generally happen:
- The developers stop creating technical debt stories (decreased transparency)
- They inflate stories related to that code (but they still fail to address all of the technical debt, because of the "compound interest")
- They become disillusioned with Scrum (and someone that believes Scrum can't work often self-fulfills this for the team by not communicating openly)
If you're a manager, stakeholder, or product owner and you are still thinking "but how do I know that they're really working and improving the technical quality?" I will refer you to another principle of Agile: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." This is so important that the Scrum Guide even echoes this in its core values: "When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone."
Generally, deferring technical debt may be truly necessary in order to meet external deadlines; however, hardening sprints should not be a convention at the cost of continuous attention to technical excellence. Make it a point to track the amount of time that the team's attention has been diverted from technical excellence, and overcompensate for it to pay off the interest accrued. Only consider deferring this key part of Agile Scrum within the context of your team's sprint.
3. Point Inflation
Developers also have a knack for making molehills out of mountains. In my experience technical-creative types tend to be optimistic with time because it's how they self-motivate. Many developers are the type of people that cranked out 10-page essays the day before they were due in college (hence why Scrum has such a heavy emphasis on time-boxing).
On an unbalanced team, it is common for a few power-players to underestimate the average-time-to-complete. That, combined with the fact that estimations are already inherently difficult, makes these matters worse.
A team should, ideally, compare the time that was estimated to the time it actually took to go from “none” to "done." Without this inspection, estimates will often remain the same, while technical debt, process overhead, and other factors start to inflate the actual time. I call this “point inflation.” This is one possible explanation as to why the team spends more time each sprint on delivering the same number of points. Often, the team just starts adding padding to all of the estimates, which increases cycle time, thereby decreasing predictability.
Let's imagine you pay $10 for a meal every day. On that green grassy field, they serve up some fresh meat, vegetables, and fruits. Months later, you’re still paying the same amount, but the portions have halved. What happened? The company didn’t account for unexpected costs (and will probably still continue to ignore them, because some of their customers want baked goods “like, yesterday”).
Are team members coming in earlier, leaving later, or working weekends? Does the team spend too much time (more than 10% of their capacity) refining the backlog? Does the team try to compensate for difficulty planning by going with the expert's estimate? Does the team vary a lot on their estimates? If these things are happening, you may have an inflation problem and should figure out how to get better estimates.
Consider embedding knowledge transfer or pair-programming as tasks to a few major stories; and, if you haven't already, start making regular payments on your debt. Make a habit of identifying stories with a lot of uncertainty and breaking them down into more manageable pieces. In cases where the uncertainty is based on things outside of your control, consider creating preliminary research/prototyping stories and leaving room for starting on the implementation later. Just make sure to inspect and adapt within the context of your team, sprint, and project.
This is just a taste of a few major pitfalls and antipatterns perpetuated by convention-based, out of context, Scrum practices. Do take everything I say with a grain of subjective salt, but let my main message be clear: if a convention isn't established within the context of a team, then beware. Always inspect, and only then, determine how to adapt. Never try arbitrary process changes without real team discussion and buy-in. A change is only as important as the reasons it should happen, and only as effective as the team's ability to agree with the reasoning.
Matt Brumagin is a Software Engineer and Scrum Master at Accusoft. He is new to the role of Scrum Master, but has 3+ years experience in web development using Scrum. Matt graduated from Clarkson University in Potsdam, NY with a Bachelor's degree in Electrical Engineering and minors in Software Engineering and Mathematics.