Scrumban: Our Blend of Agile
Remember when you had to subscribe to an entire cable package just because you liked one channel from it? You had to decide if the Real Housewives of LA were important enough to sign up for Bravo plus 50 other channels. Is Spanish soccer that great that you need to order a beIN sports package, which also comes with channels showing curling?
The ‘cutting the cord’ trend was long in the making, now we can pick and subscribe to just the channels we actually want. So if we can pick and choose with cable why can’t we do this with Agile? It has some packages that we are asked to follow, but what if they don’t entirely fit the bill? Is it possible to take the practices we like and cast aside the things we don’t?
Our Engineering setup means that our teams are working to support and enhance both new and existing products. For greenfield projects, a scrum model is best suited, but Earnest teams also have to deal with emergent work which often appears. And scrum doesn’t like interruptions, so what to do? We need to plan and adapt as we go. With important interruptions taking priority we need a system that’s flexible without affecting our discipline.
Before I describe our house blend, let’s cover the options we didn’t go with, and why.
Why Not Scrum?
Great question. Agile at Earnest is definitely a blend of practices–but not by chance. We operate in a world where requirements and priorities change constantly, and we have to move with it.
Going with a commitment system like Scrum, where the work is locked in place and can’t change during a sprint, doesn’t mirror reality. What happens when Legal presents a pressing matter? Or when Product receives feedback that changes the direction of delivery? What if a partner system pushes through an upgrade that takes availability down? Pretty hard to stay with a sprint commitment!
What does commitment really mean if you can’t commit? By definition, it’s waste if it’s not adding value, according to Lean principles. And how many can really “commit” to pure Scrum if their teams support the live product? It’s a rabbit hole, with many exit paths of course. We could split teams by Development vs Support, but how do you keep support engineers happy, engaged or current with the code?
Our constraint/challenge, is how can we handle emergent work while executing on a plan? I’ve often heard this one “Let’s try planning for the unknown”…hmmmm. Or “cancel the sprint and start again” in order to re-prioritize. But we’d rather cancel Scrum if it’s not working for us.
Why Not Kanban?
Due to the nature of emergent work, a priority can flip in an instant (that doesn’t mean it has to). In a Kanban system, the backlog is constantly refined and the highest priority is worked on first. We like that…so we use it. We expect and allow for interruptions.
Kanban teams don’t size tasks because it’s deemed as waste. Only the highest priority is worked on so why size it? If you don’t get any value from sizing, then don’t do it! But we are able to understand a team’s throughput if all stories are sized. It’s great data for measuring team performance and planning ahead. So we size everything.
Our Red Blend of Agile
So now we’re in this blend of 80% Scrum practices with 20% Kanban. Some people might be pulling their hair out by now, but let’s not forget that Agile is a blend of different practices. 17 people got together in 2001 and took the best parts of existing methodologies to make a better one. We’re just taking it a step further.
Scrum vs. Kanban
We size our backlog upfront (using XS, S, M, L, XL) because we want to know the effort it will take to get something done. That way, we can set expectations and hold ourselves accountable. After T-shirt sizing, we apply a 2x points scale (1, 2, 4, 8, 16). Our T-shirt sized buckets are roughly double the effort of the previous one. i.e. a small should be twice the effort of an extra small and so on. This points scale matches our bucket sizing. Sounds simple, doesn’t it? We’ve also found that this format tends to not short sell our backlog, or undermine our predicted dates.
Points Matter
Points scales are said to be an arbitrary measure, but they are so important. It always puzzles me why teams would apply Fibonacci (1, 2, 3, 5 & 8) to their T-shirt sizes. Cue an exaggerated example:
“Well, a small is double the effort of an extra-small, but the medium is just a smidgen bigger. A large is a lot more effort than a medium, but according to our points scale, is the equivalent of adding a small on top. But… when you break a large story down it will often grow bigger than the initial size.”
Confused yet? To summarize, when you break a large story down using Fibonacci, the sum is greater than the parts. This is how you short sell your backlog!
We believe it’s better to be approximately right vs. precisely wrong. We bucket in approximation, so we don’t hang around getting caught up on the debate between a small vs. medium or large vs. medium. Earnest’s delineation is clear and our T-shirt sizing is simpler than Fibonacci.
Plan and Adapt
We have grooming and planning ceremonies before we go into 2-week iterations. Like most teams, we follow a weather forecasting system–using past behavior to predict the future. I cannot stress enough that it’s a prediction. I’ve seen teams get hung up on commitment, where they deem themselves to be failing if every story does not cross the line.
We don’t commit at Earnest, we plan. It’s a pillar in the Agile manifesto to respond to change OVER following a plan. Scrum is such a contradiction in this regard. Not allowing changes is just as bad as not planning. Normally it's engineering who have to commit while interruptions can come in from other areas. (We’re solving for interruptions at Earnest right now!)
Priorities are set going into an iteration. We plan the volume of work based on past performance, BUT we expect and allow for change. Any changes are evaluated against the current priority. Of course, change comes with a cost to a project’s velocity, however, when you track these changes, the metrics can account for it.
Did Someone Say Metrics?
If continuous improvement is your goal (and it should be), then you will have to take a measurement to achieve it. If you don’t then how else can you quantify improvement? We size our stories, tasks, and bugs to understand the scope, then measure a team’s velocity using burn up charts.
Cycle time is a great way to uncover bottlenecks in your process. Looking at time spent towards development, code reviews, quality checks, deployments, etc. allows for data-driven, objective feedback. As a team, you can go through this in a metrics review, or take it into your retrospectives. We host our retrospectives on a 2-week cadence.
Metrics should never be turned against the team in a finger-pointing exercise. I always ask teams to “point the finger inwards” and ask what you could have done (or can do) to help improve things. We’re not trying to accuse anyone of not giving their best. The purpose is to find ways to help each other and improve as a team. We’ve improved requirements gathering, staffing, bottlenecks, dependency planning, and more through this process.
What metrics are your teams using, and more importantly, why?
What’s Next for Earnest?
Right now we’re rolling out a revised portfolio planning process. We want to incorporate our past project learnings to bring about a more collaborative, streamlined approach which will reduce interruptions, reduce lead time, and improve the quality of the product.
If you want to talk about our revised Agile process or learn more about the Earnest Eng team, we are hiring!
