Are you practicing Anaconda or Hummingbird-style Scrum?
Debunking the ‘Kanban is more flexible than Scrum’ misconception
“We can’t start a new ticket today, itthe final day of the Sprint and we won’t be able to finish.”
“We just finished Sprint Planning. We shouldn’t be making changes to our Sprint.”
“I prefer Kanban over Scrum because Sprints aren’t flexible.”
I’ve lost track of the number of times I’ve heard people utter these sentences.
It bugs me to hear these misinformed expressions on Scrum Teams. Our kneejerk response is to tell these people they are not doing Scrum. But that isn’t helpful. And who cares, really? Having something that works is more important than blindly following any rule, but I digress.
Many Scrum Teams believe this is how Scrum is supposed to be — inflexible and shackled by the ball and chain of a Sprint that prohibits us from responding to changes. I call this rigid interpretation of Scrum Anaconda-style Scrum. I also started doing Scrum this way. Based on my personal experience, I believe most Scrum Teams practice Anaconda-style Scrum.
Now I’m practicing Hummingbird-style Scrum. An entirely different type of Scrum where team members are often surprised how different it is than any of the other Scrum Teams they’ve been on. They often mistakenly start claiming we’re doing Kanban instead of Scrum.
I think it’s important to be aware of what Scrum style you are practicing. Awareness of your style of Scrum can then start a conversation to determine what best fits your context and situation.
Let’s start by explaining the difference between Anaconda-style and Hummingbird-style Scrum.
Anaconda vs. Hummingbird-style Scrum
Anacondas don’t have to eat frequently. The anaconda is a giant slithering digestive tract. Imagine an Anaconda gets lucky and devours a whole goat. Anacondas can go without food for months after a big meal. The anaconda can lay low until hunger strikes. Agility isn’t necessary after their belly is full and they can just relax until their stomach is empty.
Let’s contrast this to the tiny hummingbird. A hummingbird cannot afford the luxury of resting on the perch of a branch for long. Hummingbirds have to eat every 10–15 minutes and visit thousands of flowers per day to extract their nectar. If a hummingbird doesn’t eat for 24 to 48 hours, it will die. Hence you rarely see hummingbirds resting. You nearly always see hummingbirds zipping around and nimbly moving from flower to flower.
In short: anacondas can chill after the kill. Hummingbirds have to keep moving and change direction constantly to be able to gather enough food to stay alive.
The anaconda follows something that looks like a batch process — by eating a large animal and slowly digesting it over a longer period. The hummingbird follows a continuous process of obtaining little sips of nectar from flowers and digesting it quickly.
See the comparison with Scrum already? Let’s examine what Anaconda-style Scrum looks like through the lens of a Scrum board.
Below is what the Sprint looks like immediately after Sprint Planning of an Anaconda-style Scrum Team:
The whole Sprint Backlog is completely formulated from the start. Some work relates to the Sprint Goal and some work doesn’t. Great, now we're ready to go! Let’s take a look at our Anaconda-style Scrum Team in the middle of their Sprint.
The team is doing a tremendous job and prioritizing work related to the Sprint Goal. Notice how no new Sprint Backlog Items have been created. The whole team is killing it! The Scrum Team keeps plodding on and by the end of the Sprint, their Scrum Board looks as follows:
All is good in the world again! The Scrum Team went ad fundum, meaning they drank the whole glass… ahem Scrum Board.
A completed board at the end of the Sprint is what a great Sprint looks like for an Anaconda-style Scrum Team. Everything is off their plate. Nothing unexpected happened and everything went according to the master plan. The whole Sprint Backlog has been completed and there are no carry-overs.
We can start with a pristine virgin Scrum Board for our next Sprint. Hurray, everyone rejoices!
Now let’s contrast this with a Hummingbird-style Scrum Team after Sprint Planning:
After Sprint Planning, the Sprint Backlog hasn’t been fully fleshed out. The team only discusses and plans what relates to the Sprint Goal for the first few days. The team is confident they can make the Sprint Goal, as there is more than enough capacity to pull in more work. The Scrum team believes the plan will emerge as they do the work when reality exposes itself.
Now let’s take a peek at how our Hummingbird-style Scrum team is doing halfway through the Sprint.
Brilliant! The Sprint Goal has already been completed. The team pulls on more work with their available capacity. By the end of the Sprint, this is what the board looks like:
The Hummingbird-style Scrum team completed more work than the Anaconda-style Scrum Team, but they also have more carry-overs. The team doesn’t worry about these carry-overs, as they do not relate to the Sprint Goal. Since they never plan their full capacity for the Sprint Goal nor pull in a huge amount of work ahead of time, they are confident the loose ends won’t affect their next Sprint.
Anaconda-style vs. Hummingbird-style Scrum in a nutshell
Anaconda-style Scrum teams believe the following:
The Sprint plan should be fully fleshed out before the Sprint starts.
Changes in the plan are seen as a failure.
Alterations in the Sprint Backlog are discouraged.
Work is pulled in at the start of the Sprint to fill up every inch of capacity and creating a large batch of work to process.
Completing all work in the Sprint is the goal of the Sprint, even if they use a Sprint Goal.
Hummingbird-style Scrum teams believe the following:
The Sprint plan should emerge during the Sprint. We work with what we do know to discover what we don’t know. Doing exposes reality, as Woody Zuill phrases it.
Changes in the plan are encouraged, as our initial plans are limited by the fog of beforehand — what we can know before starting the work.
Changes in the Sprint are encouraged. As we learn more, we can do a better job.
Work is pulled in the Sprint as necessary, just like happens with Kanban teams.
The purpose of the Sprint is to meet the Sprint Goal. Other items present in the Sprint are stretch goals — we may or may not complete them depending on how difficult meeting the Sprint Goal turns out to be compared to our initial predictions.
Anaconda-style Scrum teams load their Sprint with all their tickets and believe they have to finish everything they have started. At the end of the Sprint, the whole Sprint Backlog needs to be cleared. Like an Anaconda with a bellyful of goat that needs some time to digest that huge slab of meat.
Hummingbird-style Scrum Teams start their Sprint only with enough tickets for the first few days and fill in the other details as they go along. Just like the hummingbird that doesn’t plan ahead of time which flowers it will visit.
I prefer working with Hummingbird-style Scrum because when you do complex work, you need to work with what you do know, to figure out what you don’t know. Not knowing means you need to be able to swiftly respond to changes based on what you discover and learn.
Hummingbird-style Scrum gives maximum flexibility, like Kanban, in case the Sprint Goal turns out to be more difficult or a pesky production issue suddenly comes your way. We want to be able to respond to changes, not stick to the plan simply because we spent so much time in meeting rooms and subsequently fell in love with our precious Sprint plans.
On top of this, you don’t suffer from any artificial Sprint boundary for starting or completing work. The Sprint boundary only affects the work that relates to the Sprint Goal. Actually, Sprint boundary is the wrong way of looking at it. The Sprint is an inspection moment, not a boundary.
Now the question becomes, does Hummingbird-style Scrum conflict with the Scrum Guide? No, it doesn’t.
What may be surprising is that Anaconda-style Scrum conflicts with the Scrum Guide. Empiricism means making decisions based on what is known and responding based on what you learn.
Anaconda-style Scrum Teams believe they make decisions based on what is known, but they don’t for three reasons:
Fear of making mistakes. Anaconda style Scrum teams over-analyze and over-think, causing noise and misinformation to be entrenched in our plans.
Believing we know more than we actually do — causing unwarranted faith in the initial plan.
Underestimating the importance of what we don't know — the heavy weight of our initial plans acts like an anchor that stifles the ability to respond when new information presents itself.
As a consequence, Anaconda-style Scrum Teams make following the plan more important than responding to changes.
During the Sprint, the Scrum Team only commits to achieving the Sprint Goal. In Sprint Planning, you only have to make a plan for the work that relates to the Sprint Goal, as that’s the only thing you promise to deliver.
Does this sound like cheating? Maybe it does. But keep in mind Scrum is meant for complex work and Anaconda-style Scrum is inadequate for responding to changes. I prefer Hummingbird-style as it gives you way more flexibility and agility to react based on what you discover or deal with curveballs that are thrown your way.
Try Hummingbird-style Scrum out, and let me know your thoughts!