Scrum is Agile, but Agile May Not be Scrum: Understanding the Frameworks

For anyone unfamiliar with project management methodologies, the title of this post probably reads like a Dr. Seuss quote: Scrums are agile, but not all agile is scrum?

For experienced project managers, the title might seem like a little misleading: Don’t agile project teams use scrum?

Well, yes and no. Maybe this is why companies are willing to pay six-figure salaries for good project managers.

Let this post be your guide through the haze of complicated project jargon. We will explore how scrum fits into agile frameworks and when it doesn’t.

Agile: A Philosophy That Guides Project Workflows

Andrew Littlefield at Trello has an excellent way to think about agile vs. scrum: Agile is the diet, and scrum is a single recipe.

So, let’s work at the diet level first. Agile refers to the core ideas set out in the Agile Manifesto that prioritize:

• people over processes

• working prototypes over documentation

• customer collaboration over contract negotiation

• responsiveness to changes over adherence to a rigid plan

This makes agile particularly useful at doing things like guiding the development of a great product that’s free of bloat. But it’s not a philosophy that you can just switch to and implement.

Liberating as it is to focus on doing work over adhering to processes, agile is something that needs buy-in and support from the top, say McKinsey partners Santiago Comella-Dorda, Krish Krishnakanthan, Jeff Maurone and Gayatri Shenai.

In doing so, an organization’s senior leaders promote the culture of joint ownership, continuous learning and improvement, and ongoing collaboration among stakeholders that agile needs to thrive.

Scrum: A Methodology That Can Support an Agile Philosophy

Now, let’s take this down to the recipe level.

Sébastien Boyer, chief technology officer and chief product officer at Nutcache, has a nice line about the role of scrum in agile workflows: “Agile is a way to do things, and Scrum is a way to get things done.”

Scrum outlines the processes for how a project manager identifies what work needs to be done, who will do that work, how it will get done and when it needs to be completed, writes Joseph Griffin, a veteran PM and associate teaching professor at Northeastern University.

The methodology creates clear roles — and some new jargon that you’ll need to know. This includes:

• Product owners. This is the person who speaks on behalf of the customer (or end user) and translates their wishes into a prioritized product backlog list.

• Sprints. These are short stretches in which teams tackle the first item on the product backlog. There is typically a deadline set for each sprint.

• Daily Scrums. These are short meetings in which the team assesses its progress.

• ScrumMaster. This person leads those short meetings and keeps the conversation focused.

When a sprint is completed, the team debriefs, ships what it can to the customer or stakeholder, then selects the next highest-priority items from the product backlog to focus on, at which point the next sprint begins.

It’s the action of shipping that sets scrum apart from other methodologies, Griffin says. “Instead of waiting 12 months to deliver a final software solution to a customer using a more traditional approach, one may deliver six smaller versions of the software solution that continue to build on the previous release, allowing the customer earlier access to the software and the chance to iterate and adapt along the way,” he writes.

Within the right agile environment, the scrum methodology does a good job of getting things done. That said, the frequent meetings, the collaboration and the ongoing reassessing of a project’s progress can create tensions among team members — especially those who are new to scrum.

Tristan Green at TheNextWeb cites a 2016 study that found two in three people “said that tensions rose in the workplace after Scrum was implemented” (though the majority of those respondents put the blame on leadership rather than the methodology itself).

When Would You Not Use Scrum?

Scrum is an excellent method for organizing work in specific cases.

Christiaan Verwijs, founder of corporate training company Agilistic, says the scrum methodology is probably a good fit if you need to

• mitigate the financial risk of product development,

• collaborate with your customer on a product’s design, or

• introduce more flexibility into your development cycle.

Not all projects and not all workflows benefit from the iterative nature of scrum, though. As flexible as scrum is, it imposes pretty strict constraints on time and team member roles.

Given those constraints, Roko Roic, CCO at software development company AG04, highlights a few cases in which scrum wouldn’t be a good fit. We’ll call out two of those scenarios here:

1. Don’t use scrum to maintain working software. Four-week sprints aren’t useful for fixing bugs or getting out timely updates.

2. Don’t use scrum when the team struggles to focus. Though Roic argues that almost any team can get its focus aligned, he concedes that some organizations simply have to distribute their concentration by, for example, developing several products in parallel. Without that focus, “pretty much nothing works as planned,” he says.

Likewise, teams in which developers work independently don’t make a good fit for scrum, as we will see in a moment.

Scrum Alternatives: Other Iterative Methodologies

In cases like those above, you can still maintain an agile philosophy to project management and product development. You just need a new approach to actually doing the work. Here are three alternatives that could be a better fit for your team:

1. Kanban

Kanban boards date back to the 1940s, when managers at Toyota’s factories were discovering new models for efficient vehicle production. Most of us today know Kanban via software such as Trello.

Kanban is a deceptively simple process: You essentially create three columns — “To Do,” “In Progress” and “Completed,” or some similar naming conventions — and move tasks from one column to the next.

“By visualizing your tasks on one screen, you can identify bottlenecks, unassigned tasks, and missed deadlines at a single glance,” the team at Paymo writes. “Afterward, you can solve these issues right from the board’s workspace.”

This methodology lets a project manager throttle the number of tasks anyone is responsible for at one time. The main KPI the manager needs to focus on is cycle time, or how much time it takes to finish a specific task.

As product owner and agile developer Maarten Dalmijn writes, kanban can be a good fit for that team of independent developers we alluded to earlier. Dalmijn tells the story of working on one such team: “Each developer worked on their own project in their own programming language. The only thing in common was the API they used to develop their applications.” The team tried to use scrum, but it created too many inefficiencies. Upon returning to the team’s old kanban processes, the efficiencies resumed.

2. Scrumban

This is exactly what you imagine — a hybrid version of both scrum and kanban.

Andrea Fryrear, president and lead trainer at AgileSherpas, argues that scrumban is especially useful for marketing teams because it combines the benefits of both methodologies. It lets project managers easily visualize the workflows, but it still imposes sprints.

While Fryrear warns that implementing something like scrumban can take you into unfamiliar territory quickly, Littlefield’s piece at Trello gives a useful example of what a scrumban board might look like. His has a list of resources, a backlog, a To Do list to manage an ongoing sprint, a “Doing” board for a task in progress, a “Quality Check” board where completed tasks must wait before moving on, and finally a “Done” board.

3. Lean

Many developers will already be familiar with lean software development, which also, um, leans on kanban for inspiration, Alesia Krush at DZone writes.

The deliverable in lean is a minimum viable product, something that’s market-ready but could still benefit from further development. Lean forces the product manager to focus on the customer’s needs, prioritizes efficiency and emphasizes that pull aspect of kanban in which a task graduates from one column to the next.

Think of all of these methodologies — scrum, kanban, scrumban, lean — as tools in your agile toolkit. Just as a hammer alone is enough when building a house, you cannot scrum every product’s development cycle.

“A new experimental project is not the same as a big mature project,” Continuous Agile writes. “An application for a marketing campaign needs to move fast. Billing system development should be slower, secure and reliable.

Fortunately, many projects go through some predictable stages of life. If you think of software as having a lifecycle and not a plan, you will have projects that are more efficient at each stage of life.”

images by: subbotina/©123RF Stock Photo, choreograph/©123RF Stock Photo, rawpixel/©123RF Stock Photo