Skip to content
Home » Blog » So Long Scrum. Hello Scrumban.

So Long Scrum. Hello Scrumban.

  • by

Over the previous 5 years I’ve used Scrum with a number of groups at a number of corporations. It was an enormous enchancment on the waterfall processes it changed, however there have been at all times some nagging points. Recently my staff switched to Scrumban, a Scrum-Kanban hybrid. Here’s why we switched, and the way it’s labored for us.

A Batch Process in a Real-Time World

The Iterable app runs on the cloud and we launch repeatedly. Using Scrum in a CI/CD world has at all times felt awkward. With steady supply there isn’t any “potentially shippable product” on the finish of the dash—actually, by the top of the dash, most of your work has already shipped. With no doubtlessly shippable product, there may be little motive to force-fit the staff’s work to dash boundaries.

Scrum additionally brings pointless ache round “unplanned” work. Mike Tyson summed this up properly when he stated, “Everybody has a plan until they get punched in the mouth.” Scrum treats unplanned work as a grimy phrase, however I disagree!

We put herculean effort into CI/CD automation so we will launch quick. We can discover a bug within the morning and repair it that afternoon, so why would I take advantage of a planning course of that daunts this? You can work round this in your Scrum staff by under-committing throughout dash planning and pulling in objects as they arrive up, however when you’re routinely altering your dash commit then that’s probably not Scrum anymore.

These two points inform us that Scrum will not be one of the best match for a CI/CD world. So what’s?

Enter Kanban

Kanban was developed for just-in-time manufacturing. It lends itself properly to a CI/CD-based software program growth atmosphere, the place work will be launched real-time, because it’s accomplished. Pure Kanban places much less emphasis on up-front planning and focuses on excessive throughput whereas limiting the quantity of labor in progress at any given time.

Work (Jira tickets in our case) progresses by quite a lot of steps from “Ready for Work” to “Done,” and if too many tickets wind up in the identical step (often it’s “Awaiting Code Review”), then we’ve hit a bottleneck and we will rapidly deal with it and get the pipeline transferring once more.

Where Kanban falls quick is planning, and that’s the place Scrumban is available in. We’d wish to have simply sufficient planning to steer the ship, however not such strict planning that we mindlessly crash into any rocks we didn’t see earlier than setting our course. We add in an ordered backlog of upcoming work, and have a weekly 90-minute planning assembly to debate priorities for the week and transfer tickets from “Backlog” to “Selected for development.”

This weekly plan has some vital variations from a Scrum dash. Unlike a dash, we don’t attempt to power all the things into the one-week boundary. We know that if somebody plans to choose up two tickets that take three days every, a kind of tickets will roll over to subsequent week.

We additionally settle for that unplanned work might come up throughout the week, and so we’d modify the plan as we go. In Scrum, which means we fell wanting our dedication. For us, it means we labored on probably the most helpful objects day-after-day, even when a few of them got here up after planning—often manufacturing bugs or pressing buyer requests.

At the top of every week, we’ve a assessment and retrospective assembly, once more borrowed from Scrum. We talk about what we’ve accomplished, share demos, stroll by code, speak about what goes properly, and what’s not. Each week we additionally have a look at the variety of tickets accomplished, as a stand-in for story factors and velocity.

Mercifully, we do not need to determine easy methods to depend story factors for one thing we “almost finished” (do the story factors depend to this dash’s velocity or subsequent?)—we solely depend the finished tickets and as long as we’re on observe, all of it averages out ultimately.

Nuts and Bolts

The Backlog

Iterable makes use of Jira throughout engineering, and, being good staff gamers, we observe this normal. We created a Kanban mission in Jira and enabled the backlog (within the board setup display, beneath “Columns,” drag the “Backlog” standing into the “Kanban Backlog” column like this) and enabled the “Epics panel” (a easy toggle on that very same display).

We modified the cardboard format to incorporate the date the ticket was created and the elements. Here’s how the backlog appears to be like:

Day-to-day Work

We tweaked the default workflow in order that we’ve 5 columns: “Selected for Development,” “In Progress,” “In Review,” “Awaiting Deployment,” and “Done.” We use the Jira git plugin which routinely strikes a problem to “In Review” when a PR is opened, and to “Awaiting Deployment” as soon as it’s merged. Unfortunately, we nonetheless set off deployments manually, and as soon as a developer has performed this deployment they transfer the ticket to “Done.”

We modified the cardboard format right here to incorporate the elements. Here’s our day by day working board:

Tickets and Planning

We are usually not strict round problem format and we don’t create Scrum-like tales. We do group tickets for giant initiatives into epics, however more often than not we simply use elements.

While we observe tickets and growth work in Jira, most of our planning is definitely recorded in a working Quip doc. Each week we add a brand new part, and our agenda is at all times: “1. Review current state, last week’s progress,” “2. Upcoming items,” and “3. Plan for this week”.

Here’s our human-friendly planning doc from just a few weeks in the past:

When reviewing final week’s work we create a Jira launch, which gathers all the finished tickets and removes them from the board. We may share some particulars of accomplished work and talk about something that’s rolling over to this week as wanted. If there have been non-Jira objects from the earlier week similar to, “remember to fill out the survey for the offsite,” we’ll test in to ensure we did it.

“Upcoming items” is a placeholder for reminders. Most of that is entered throughout the earlier week, so by the point we sit down for planning, it’s a record of issues we have to keep in mind for the approaching week. It usually has issues like, “Bulk event endpoint—promised to a customer by end of Feb,” (so we keep in mind so as to add this to the plan for this week) or “Jemiah on PTO next week” (so we keep in mind to plan accordingly).

Finally, beneath the plan for this week, we record out the broad strokes of what every engineer is engaged on. Items with dev work, like “Continue ingestion format changes,” would have detailed tickets tracked in Jira. Other objects like “Talk to Wayne about API” are simply reminders-not tracked in Jira.

What’s Next?

The Agile Manifesto tells us “respond to change.” When Scrum changed waterfall, altering launch cycles from months to weeks was an enormous step ahead. Now, with CI/CD changing into the norm, it’s time for engineering organizations to reply once more. We’ve taken a primary step, and as with all Agile course of we are going to proceed to assessment, react, and refine as we go. Now I encourage you to make the leap, strive it out, and see if Scrumban is best for you!

Leave a Reply

Your email address will not be published. Required fields are marked *