Scrum
never give up ground
In days of old, enterprise software teams wandered aimlessly for many moons and even the IT chieftain knew not of a safe haven. Then Ken Schwaber came to lead the tribes out of the desert, to a new land of Milk and Scrum.
In this land of dogged persistence and incremental accomplishment, the ancient mud-and-blood ritual of Rugby was consecrated to a new era of software development dedicated to moving the ball down the field and never giving up ground.
A Scrum Sprint Needs a Goal
The Scrum Guide defines the Sprint Goal is a potential releasable increment of code. People jump through hoops to come up with Sprint Goals that sound like something an adult might say, while dodging the work of getting stuff releasable.
The Sprint Goal is a summary of the business value to be delivered in the increment and is intended to force the team to prioritize the periodic delivery of working software over meeting all of the requirements. The key point that many teams overlook is that the specific requirements of the individual stories are always negotiable. Even essential acceptance criteria which are non-negotiable from a business perspective are negotiable in the context of a given sprint. If you’re doing Scrum and your organization can’t support that principle, then you might as well Advance to Go and Collect $200, because you’re just playing games anyway.
Meaningful statements of Sprint Goal are unlikely to be found with teams responsible for developing and maintaining a number of difference services. Tasked with feature enhancements, fixes and new service work, the sprint goal can’t really be any more coherent than “get the work done”: sprint increments won’t have meaningful stakeholder value rendering the principle of negotiability pointless.
Time-boxed Sprints are a hybridized method of scheduling work that was developed to lift teams out of a chaotic world of conflicting priorities by locking them into meeting a goal within a timebox. If you’re doing the timebox bit without the goal part, then you might take that as a hint to consider another approach to work scheduling.
Work-scheduling in the Time Box
The Sprint time-box is the work-scheduling component of the Scrum framework. Differentiating the framework’s protocols and ceremony from the scheduling aspect is the starting point to understanding the implications of the time-box approach, which assumes a flexible attitude toward implementation details. A time-box without a Sprint Goal is a hard master.
Decomposition as the Cornerstone
The Sprint Backlog is the batch of stories pulled from the Product Backlog and prepared for work. Getting the decomposition of individual stories right at this stage is the cornerstone of Sprint success. Missed opportunities for getting stories sized appropriately will complicate implementation. It’s not uncommon for teams to shortchange decomposition, (which by the way is really hard work), and instead spend far too much energy on trying to pull a Sprint batch to match the team’s capacity. Excessive focus on this is often a misguided effort to set up a target.
The Sprint Goal is not a Target
Conflating the Sprint Goal with the Sprint Backlog and then have it somehow morph into a performance target strips the development team of options before the Sprint even gets underway.
When the whole thing is reduced to a performance target, effectively the message is that the team will be held accountable for results regardless of the source or causes of any trouble they get into. This shows a disconnect between the problems team members face and what stakeholders and managers are willing to do to hold up their end of the bargain.
Eighty-five percent of the reasons for failure are deficiencies in the systems and process rather than the employee. The role of management is to change the process rather than badgering individuals to do better.
— W. Edwards Deming
Using the Sprint to set stakeholder expectations for delivery is also a bad idea because it sets up the dynamic to encourage people to choose between living up to quality standards or meeting expectations. Never underestimate the pressure to say done.
Definition of Done
Scrum embraces the rugby ethic of never giving up ground, and for software, there is nothing so effective in achieving that as the Definition of Done, or DoD. Agreeing on a standard of what it means to be done is one of the most significant innovations in the history of software. It goes a long way as an organizing principle to build trust between stakeholders and the development team.
Canonical Scrum tells us that any story that is not fully and verifiably done according to the accepted DoD should be excluded from Sprint Review, and not included in the deliverable increment. Teams often confuse the enumeration of the acceptance criteria of a story with verifiable completeness for the sprint increment. These are two different things.
Done from the perspective of the sprint increment can and often must exclude acceptance criteria which are non-negotiable from a business perspective. Done from the perspective of the sprint increment just means that everything that is delivered can be verified, not that everything the must eventually be verified relating to the feature must be delivered at that time. Otherwise, you telling your team that your half-baked definition of done is more important than quality.
Quality is pride in workmanship
— W. Edwards Deming
The DoD is not something you just set and walk away, but more like a carburetor that needs an occasional turn of the screw to make the mix a bit more rich or lean, depending on conditions. It’s better to have a modest DoD that’s respected than a comprehensive one that is ignored.
We're Not Magicians
Making a commitment to the Sprint Goal is fine, so long as the goal is coherent and expressed as a statement of business outcomes, leaving the details of implementation negotiable. In any case, don’t take it too literally.
If the Sprint Goal is considered to be the fulfillment of all the features and requirements of all of the stories pulled into the Sprint, it’s more like a magic trick, because the Sprint ends at an arbitrary moment in time. If the goal were getting a definite basket of work completed and verified according to rigorous standards, how does it make sense that we’d choose an arbitrary time for that?
The purpose of ending the Sprint at a fixed interval is not to see if we can pull a rabbit out of the hat every two weeks, but simply to remember to stop, reflect, reprioritize and begin anew.
The Sprint Retrospective
The middle of a Sprint is much like a rugby Scrum, where it is hard to know where the ball will end up by the end of the play. After the dust settles, stakeholders and the development team come together for Sprint Review, and afterward, the team retires for the Sprint Retrospective to lick their wounds. If the Retrospective meeting is not the pivot on which the process turns, then you’re missing the whole point.
If you’re not discussing your most critical issues in the Retrospective, then when? The Retrospective is an opportunity to tackle problems and build team cohesion.
Teams that don’t take the Retrospective seriously are like railroad operators who are too busy managing the timetable to be bothered with keeping up the tracks.
Burn Down Charts
Showing the amount of work left versus time remaining can be helpful for the development team, but the burn down can be trouble in the hands of a stakeholder who doesn’t have the context to take it all with a grain of salt. The burn down tells you something about what’s done but nothing about what needs attention.
Burn down charts are particularly attractive to the micro-manager: before you know it, team members will be skimming code reviews and skipping verifications in their rush to get tickets onto the burn down. The last thing you want to do is to cut into quality to get a stinking chart looking good.
Another disease of burn downs is when the team starts doing work off the books so that the a clean burn-down is guaranteed, most of the work to be burned down being already done when the sprint starts. This sacrifices the first-order principle of visualizing the work for a third-rate goal of impressing stakeholders with faked metrics.
There’s nothing wrong with using the burn down to set the context for a standup, for example, but it’s not a substitute for understanding the work, and shouldn’t be shown to individuals outside of the development team.
Sprints are frequent enough to limit stakeholder focus to delivered increments of working software. You can tell that a project has really gone off the deep end if stakeholders who are not looking at sprint increments are looking at sprint burn-downs.
Velocity
If you’re going to try using Velocity to measure progress, then you owe it to yourself to work through the details of the parametric estimation technique behind Story Points, and the Interval Scale math that drives the Velocity calculation. Otherwise, it’s more along the lines of "…look ma, no hands…""..
Velocity isn’t even mentioned in the Scrum framework, and there are better ways of gathering performance metrics.
Scrum is a deeply entrenched framework which we often find appropriated to dress up business-as-usual resistance to change with Scrum ceremony.
So a fool returneth to his folly – though he knows it to be folly, and ruinous to him: but vice has become to him a second nature, and he cannot, even if he would, escape from it.
— Proverbs 26:11
Many teams use Scrum to their advantage, setting cadence, learning and iterating and improving while getting work done. Adhering to “standard” Scrum is not essential, but taking the time to study the canonical framework will go a long way to helping you understand how to make the most of things.
Maybe it’s because I’ve always preferred Chess to Rugby, but I prefer Kanban.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.