Ask anyone to describe agile, and inevitably they’ll use terms like sprint, product backlog, product owner, and sprint planning.
Notice a trend?
Those are all terms specific to Scrum that have become, for better or worse, part of the ubiquitous language of agile.
The reason for that is simple. The Scrum framework has won the market share wars as the most commonly used framework when organizations adopt agile.
Why Agile != Scrum matters
That popularity leads many people to conclude that agile = Scrum.
In reality, Scrum is one of many frameworks that you can use as a starting point to approach work in an agile fashion. I like to use an analogy here: Scrum is to agile as Kleenex is to facial tissue.
Why is that important? Because Scrum is only one way to exhibit an agile mindset, it is not appropriate in every situation, and it is not a complete solution.
If people think that they have to do Scrum in order to be agile, they conclude they have to have sprints, even when the nature of work lends itself to prioritizing and deploying much more frequently than once every two weeks. It also leads them to ignore the excellent technical practices found in extreme programming.
Scrum can be a starting point
This is not an anti-scrum rant. When I work with teams adopting agile, I often use Scrum to help introduce agile approaches.
Some of my friends are Certified Scrum Trainers.
The thing to remember is that Scrum is a useful component to practicing agile, It is not sufficient by itself, and it is also not required. As with all the frameworks that have sprung up around the agile community, Scrum has certain advantages and is appropriate in some situations.
How to decide which frameworks to use
A timeboxed approach (Scrum) may work for you if you’ve got a fairly significant initiative that you need to break up into smaller chunks in order get more frequent feedback and have some intermediate feedback.
A timeboxed approach may work for you if your team needs some help focusing on a specific set of items for a short time period – say a couple of weeks.
A flow approach (such as Kanban) may work for you if new work arrives quite frequently and in an unpredictable fashion such that you can’t set your plan of what to work on for two weeks.
A flow approach may work for you if each item of work you do is independent from every other item and it doesn’t add value to delay deploying a completed item in order to wait for other items to get done.
Good engineering practices (those described in Extreme Programming) are always a good thing to adopt when you work in software product development.
You may find that it’s helpful to combine different frameworks. You may plan using timeboxes, but follow a flow approach within those timeboxes and incorporate several good engineering practices.
Or, you may follow a flow approach but plan and retrospect on a regular basis.
The key is for your team to create a methodology based on the framework(s) that seem to fit your context and adapt that approach through ongoing reflection and adaptation.
In order to understand your context in a way that helps your team create their methodology, it’s good to understand the risks you face. In the resources I’ve mentioned a good tool that helps you understand the risks you face by looking at the uncertainty and complexity inherent in your product.
Resources
How to understand your product’s context
There are a variety of factors that impact the framework you use as a basis for your team’s methodology. Two of the key factors are the uncertainty you have about your product and the complexity involved in delivering it. The context leadership model, created by Todd Little, helps your team explore the complexity and uncertainty you face and establish a methodology and techniques to deal with the risks that result.
How to use Agile Frameworks with Agility
There’s a concept core to Agile Software Development not mentioned explicitly in the Agile Manifesto or the 12 Principles behind it.
Consider context over best practice.
Context plays an especially important role when your team considers what frameworks and techniques to use as you create your team’s methodology.
So when you hear questions such as “which is better Scrum, Kanban or XP?” find out what context the person asking the question is concerned about and let them know that those choices are not mutually exclusive.
There are a variety of aspects of a specific context to consider when you decide which framework you’ll use as inspiration for your team’s methodology. Here are the key choices you need to make.
Scrum
Scrum is a process framework used to manage product development and other knowledge work. Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments. That is, when the framework is used properly.
Scrum is structured in a way that allows teams to incorporate practices from other frameworks where they make sense for the team’s context.
Kanban
The Kanban Method is a means to design, manage, and improve flow systems for knowledge work. The method also allows organizations to start with their existing workflow and drive evolutionary change. They can do this by visualizing their flow of work, limit work in progress (WIP) and stop starting and start finishing.
The Kanban Method gets its name from the use of kanban – visual signaling mechanisms to control work in progress for intangible work products.
Extreme Programming
Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development.