In Pursuit of Agility
Three questions every Scrum team needs to ask
In today’s age of buzzwords and process trends, it’s not uncommon to stroll into a technology organization and be greeted with Kanban charts, burn-down sheets, velocity estimates, planning poker, and other complex-sounding terms and artifacts — things that might give the impression that these teams are all incredible experts on their internal practices, dealing with the new agile world with ease and aplomb.
But the question remains:
How many of these teams would give Scrum a double thumbs-up, and claim that their work life has objectively been improved by using this framework?
The vast majority of cases see teams adopt a new methodology, only to realize that they haven’t considered the potential side-effects, added artifacts, behavioral changes among employees, and inevitable need for ongoing education.
Why does this happen?
Why do so many teams follow the framework to a dot, holding daily standup calls, kickoff meetings, retrospectives, and reviews—but not see the expected results?
I am not going to claim I have a golden method to solve these questions—the one thing to rule them all… But I do understand that in the quest for speed, it is easy for teams to lose sight of the original intent of the shiny, new Agile framework they’ve implemented.
Many enterprise Agile transformations fail not at the implementation phase, but at sustenance.
Great teams, on the other hand, realize that Scrum is a tool, nothing more — and as mentioned in the Agile Manifesto, one that values “individuals and interactions over processes and tools.” Agile development, after all, is nothing but incremental updates to a product — and how we deliver those updates is something that should be tailored to a team’s identity, instead of molding that identity to fit some rigid pseudo-framework.
With that in mind, let’s look at three key questions Agile teams need to ask themselves if they want to be successful with this approach.
Question 1: How long should the sprint be?
The length of a sprint differs from team to team, but the standard seems to be two weeks. I have, I must admit, worked in sprints that were both longer (up to eight weeks) and shorter (just one week). Now, most folks familiar with Agile practices will be okay with sprints up to three weeks or so, but any longer and the inevitable questions begin.
So what sprint length should teams choose?
It may seem that with a longer sprint length, it would be easier to enforce meeting attendance and set feedback loops. However, shorter sprint lengths can help a team during an unstable market, by helping the team focus on incremental delivery, provide for better planning, receive earlier feedback, and even get paid earlier!
Teams also need to remember that any change in the length of a sprint will be followed by an obvious settling-in period — during which the team is trained to modify their priorities per the new schedule — and might upset the team’s velocity (average number of tasks completed per sprint) in the short run.
What’s the most important consideration in terms of sprint length, then? Simply, it is imperative that a team pick the sprint length that suits their culture—whether that’s one week or three.
Question 2: How do we manage and protect the product backlog?
The product backlog is a repository of tasks and stories that the product owner uses to define the roadmap of a project. He/she refers to this backlog to communicate the end goal of the project to stakeholders.
It is imperative to keep a well-managed backlog, because it provides clarity on the overall scope of work.
Whether the team has a fixed backlog, or is working on a retainer-style project (where the relationship with the stakeholder is ongoing), product owners are accountable for the product backlog. They systematically triage the tasks in the backlog so that the priorities of stakeholders are being addressed at the right time.
Every team that I’ve been a part of, from a five-man startup to an engineering firm with tens of thousands of employees, has understood the core concept of the product backlog.
What has been different, however, is the way they have handled the backlog. Some do it well, and others not so much.
One of the most common malpractices is adding tasks to a sprint mid-sprint based on client feedback — without triaging those new tasks, grooming them, sizing them, or even actually placing them in the backlog.
In all cases, success can only be attained if the product owners and Scrum masters work together with the client and protect the development team where possible — to reduce chaos. The product and sprint backlogs should be treated as gospel — anything that is not in either does not make it into the product. The sprint backlog should be clear enough for the team to walk out of a sprint planning meeting with a clear idea of what is expected of them that sprint.
Question 3: When is “done” actually done?
A lot of self-professed Scrum teams have all the artifacts, the meetings, the roles, and the terminology in place — but do not deliver working products every sprint. In other words, they break up the development process into sprints, but do not actually have a functional increment of the software.
This is not Scrum.
During planning, user stories need to be broken up and arranged in such a way that the development team has a version of the software that has some functionality at the end of the very first sprint. The idea of having such concrete deliverables helps enforce a feedback loop, by getting product owners and stakeholders involved early in the release cycle.
An important concept for any Agile team in this regard is the “definition of done” (DoD). The DoD, in its simplest form, is the minimum acceptable state of a task so that the team can call a task “done.” This is designed in stages, from coding to reviews, quality assurance, design sign-off, and maybe even sign-off on deployment.
The DoD should be modified to fit a team’s working structure and capabilities. Teams that are vague about when to call a task “done” often suffer in clarity about the story itself. The shippable product could very easily turn out to be not shippable at best, and very buggy at worst. To ensure quality, the Scrum master should enforce a common DoD mechanism and see to it that everyone on the team fully understands the criteria.
The product and sprint backlogs should be treated as gospel — anything that is not in either backlog does not make it into the product.
A common outcome of trying to enforce a predictable velocity is that the development team rushes to meet deadlines without accounting for testing time, documentation, and project off-loading. With a robust DoD in place, however, the team becomes mindful of the entire process involved to close out a sprint.
Agile, but not random
It’s important to note here that irrespective of the method selected—Scrum or otherwise—the objective of following an Agile approach is to ensure that the entire team has visibility into the status of the project, is accountable for set deliverables, and provides a working piece of software incrementally.
One of the biggest misconception about Scrum (and similar frameworks) is that the entire team should be able to handle requests and change adhoc — sometimes in the middle of the sprint. While yes, that is “agile” in the literal sense — and it may even work in smaller teams — a lot of businesses depend on predictability: predictability that lets them sell their product better, that gives their clients/stakeholders an expectation of what is being delivered, and that lets the design or development teams plan their weeks.
No, to me, Scrum is the ability to create a product in manageable chunks. Ad-hoc requests are treated the same way as anything else — vetted by the product owner, sized and prioritized in a way that protects the development team’s integrity.
Just the start
We have seen how factors like managing a product backlog, defining “done,” accounting for quality assurance time, and even setting the length of each sprint thoughtfully can help a team function smoothly.
These are a few key concepts that are relevant to the ongoing success of an Agile framework—but there are many more that I have not delved into. Over the course of this series, I will pick a few of them apart, talking about best practices and common pitfalls. Until next time!
About the Author
Varun KV is the Scrum master at Rocket Code.
