From Scrum to Scrumban: An Agile Journey

In June of 2012, I gave a presentation to the PMI Agile Interest Group in Atlanta about my team’s journey from using the Scrum methodology to more of a Scrumban process.

Why move to scrumban?


Anecdotally, Scrum is the most popular agile methodology, however kanban and variants have grown in popularity over the years. In 2012, my team ran into frustrations that drove us to adapt. In the years since, I’ve recognized that some teams start with scrum and then adapt as they mature; but at the time, this was a novel discovery.

Back then, three items emerged in repeated retrospectives that led us to shift gears:

What was the result?

Based on all of the above, we decided to abandon the first-day tasking sessions and do the detailed planning for stories just-in-time. This means things only moved across the scrum board when action was wrapping up, not in advance of when we predicted action would tak eplace. Further, we decided to only start one story per pair, when the pair was ready to work on it.

We were no longer following the scrum methodology.

This we determined was what many call “scrumban,” a blend of the timeboxed ritual of scrum with the flow of kanban. This meant we maintained the iteration barriers, biweekly demos, standups, and retrospectives that we conducted with scrum in order to retain transparency and visibility. Because biweekly demos kept happening, the fact that the mindset was vastly different wasn’t immediately obvious to other stakeholders, but what we stressed was meeting deliverable dates.

The team responded well to a clearly painted vision and a target date, as long as it was reasonable. The team did not respond well to being chastised for failing to complete specific stories in specific sprints which were not tied to a release.

Does Product Management Care Which Agile Process Is Used?

On one hand, product management is responsible for defining products that will succeed in the market–not for choosing how they are built. Yet, an agile discovery and delivery process offers more opportunity for discovery and for course correction.

Selecting which agile methodology is less impactful to product management than whether to be agile at all. However, in the context of scrum vs. scrum ban, I found that Product Management can manage agile better under Scrumban than Scrum, especially when there’s a single person serving as product manager and product owner.

This is because there’s less time-sensitivity around the product owner’s need to be present “in the room” with engineering. Product owners had more flexibility to book customer calls / visits and could tag-team with development to “be ready” when the next epic required their input.

More specifically, with robust engineering practices around test-driven-development and especially behavioral-driven-development, the product owner’s information was captured during story elaboration when a feature is started. The team thinks through all the scenarios and details one or more stories to support them, with all scenarios for each story captured in structured behavioral commands. (Gherkin).

The team then gets to work and calls the product owner when the software is able to pass those specifications–and obviously, when questions come up. This process allows ample time for the product owner to engage in expectations management throughout the organization, requirements gathering, customer development, and all the other fun things a product manager is responsible for… meetings 🙂

The PO needs to be available to see stories demonstrated once they’re ready for the “Done” column – and to answer questions when they come up.

Long term, velocity improved in the aggregate by about 20% as the team found the cadence more conducive to flow.. That also makes Product Management happy!

There are of course other factors involved–such as maturity of the team; presence or absence of dependencies between teams; presence or absence of a scrum master; etc. But with all things equal, and with a team mature enough to handle it, a less prescriptive model is helpful for some teams.

See the slide presentation on Slideshare here

Images courtesy: Pixabay


Now read this

Thoughts on Innovation

I recently engaged in a discussion about innovation, which provoked me to share a few thoughts: There is no single, “complete” definition of innovation in my view. With that said… Innovation is situational. Improvement within a single... Continue →