Scrumban in a Nutshell (Part II)

In our PMI presentation, Irina and I spoke about a single team's journey from waterfall to scrum to scrumban. Transition from waterfall to scrum for a project like ours which had fluid business requirements, which were discovered as we developed new functionality and provided sufficient data for re-engineering and creating new business rules, was natural. It eliminated frustration from the business stakeholders and increased team's moral, provided business results that were needed. But it was not the end because once the team established repeatable rhythm, it became clear that planning was a challenge, and the old problems we thought we successfully overcame with transitioning to scrum, came back. 

At that time, I have not read Corey Ladas book on Scrumban yet, nor was I familiar with a brilliant definition by Yuval Yeret that Scrumban takes scrum outside of its comfort zone, but we felt that we are producing waste and at the same time, throwing in too many stories we are unable to complete, our planning was obsolete before we left the planning session, so it was clear we had to become lean. So the concept of scrumban emerged for our team as an attempt for lean scrum. 

While attempting to go lean, we did not want to sacrifice the rhythm that we achieved and the cadence we established  Business stakeholders enjoyed the demo and appreciated knowing when enhancement requests will be worked on. The team liked the concept of set iterations and repeatable ceremonies. So, we wanted to keep scrum cadence and become more lean. Scrumban became our answer.

So, to reiterate, our objectives were:

1. Keep the cadence of ceremonies - sprint reviews and retrospectives were the two practices working well for the business stakeholders and the team.

2. Set up clear objectives - having a goal is natural for humans. Without meeting specific objectives and no goal to achieve, work becomes dull and besides, there is no reason to celebrate!

3. Deliver prioritized work to the customer - work has to be prioritized, discussed and agreed upon. Maintenance requests include fixes and enhancement, and some of those enhancements are critical to the business, so "first come first served" approach does not work for them.

4. Minimize waste - no reason to do planning if the inflow of stories is high, and prioritization is the hey. No need to plan if it becomes obsolete before the team leaves the planning session.

5. Provide flexibility customer needs - ability to shift priorities as new stories are submitted.

6. Minimize work in progress - avoid overwhelming your team members with dozens of urgent requests in flight. This becomes stressful and unproductive due to context switching and frustration that incomplete work creates on both sides, so the idea was to establish a flow and minimize work in flight for the team.

As you can clearly see the first three goals map to scrum and the second three map to kanban. By adopting scrumban and customizing their workflow to the specific needs of the business system created, the teams were able to provide better visualization while providing visibility the users needs and objectives the team committed to. Here's the team's scrumban board:

For a good summary on how scrumban combines scrum and kanban, I would recommend this brief yet informative posting.

There is much more to it because we haven't yet discussed measuring progress and forecasting in scrumban. Post a Comment if you'd like to talk more about it, and we'll continue the topic!