We recently held a for the general public providing an Introduction to Kanban and Scrumban. While I don’t want to repeat the content that I shared there (there’s a link to the presentation here), I do want to cover a few items that I think might be worthwhile. The big thing to remember, though, is that is an introduction to the topics, not a master class. So if you’re familiar with Kanban and Scrumban this might be old hat…

A  Brief History of Lean

I began with a quick introduction to lean manufacturing and the history behind it. Much like the Waterfall process, most people don’t know the “origin story” of these things, so it’s useful to share.

Following World War II, the Japanese economy was in shambles. The Allies were in control and trying desperately to rebuild a country devastated by more than a decade of war. General Douglas MacArthur called in an engineering process specialist named to help Japanese industry get back on its feet. Deming trained many industrial leaders on “lean manufacturing” techniques which, in turn, drove further improvements and helped turn the Japanese economy around. One of those improvements was the Toyota Production System (TPS) created by .

Ohno and his team began by identifying seven wastes in production systems and working on ways to eliminate that waste. And one tool that helped them do that was by using a Kanban board.

Kanban

(看板) is a Japanese term that means “signboard” or “billboard”. It’s a way of visualizing our work. In the original form, Kanban cards were used by one station to request more items from another station upstream. This meant that demand drove production and was as lean as it could be, eliminating much waste.

Today, many teams use Kanban boards to visualize their work (one of the four principles of Kanban). They can do this with online tools – , , or some other tool – or via a physical board in their team area. The board should have columns that show the different stages of your workflow and impose work-in-progress limits (or WIP Limits). These help us not only visualize where our work is at any point but also helps focus the team on completing work and not just starting it. The adage “stop starting and start finishing” is critical to a successful implementation.

The potential problem with software teams saying they “use Kanban” for their software process is that it isn’t a process. It’s a lens through which you view your work and workflow. So whenever I hear a team say they’re “doing Kanban”, I tend to perk up my ears as that usually means “ with a board”. Three columns named “Backlog”, “Doing”, and “Done” isn’t a process – it’s a “To Do” list. And Kanban can visualize any process – including Waterfall. I don’t think anyone would agree that a Kanban visualization of a Waterfall process is in any way lean or agile.

Scrumban

Scrumban is a hybrid of Kanban principles and values with a Scrum approach to development. I I like Scrumban as it provides a scaffolding for the workflow but allows a team the flexibility and freedom to focus on delivering value, not spend time in ceremonies. And while those ceremonies have value for new teams, high-performing teams may find them somewhat burdensome. Scrumban allows us to have the best of both worlds.

Normally three of the four required ceremonies persist in a Scrumban implementation. Daily stand-up/Scrum where the team “walks the board” is practiced. Sprint demos/reviews are still held to demonstrate the value we’ve delivered over the timebox. And teams should always retrospect. Not only is retrospection a required Scrum ceremony, it’s principle #12 of the . The only one that “goes away” is sprint planning because that becomes an “as needed” ceremony.

Typically, teams using Scrumban will have a column called “Ready to Pull” or similar. This is the equivalent of the sprint backlog, but as teams don’t necessarily work in timeboxes, the column isn’t a commitment to deliver over the next two weeks but rather a prioritized list of work that we can start working on once we have capacity in our “In Progress” column.

There’s obviously a lot more to practicing Scrumban effectively, but I’ll leave that to the webinar. If you still have any questions about it, please don’t hesitate to email me.

@ Velocity

As I’ve said in previous posts, a lot of what we do here at Velocity Partners depends on our clients. What I see, though, are some clients who are “doing Kanban” but it’s not really a process. It’s “cowboy coding with a board”. I recently traveled to South America to give a basic Kanban workshop to our teams in Uruguay and Argentina (Colombia and Venezuela are my next stops). So our teams – and especially our team leads – know what a good Kanban or Scrumban system should look like. This helps us ensure our clients achieve the best chances for success by doing things correctly. Capturing the right metrics and knowing what a good process looks like are the first steps to delivering value.

Closing Thoughts

I’ve talked about Kanban and Scrumban before, especially as it relates to the kinds of teams that I think are good matches for using that kind of streamlined process. In general, there are teams whose work is well-suited to it and teams who should stick to a more standard approach to agile. In the end, it’s up to the team and the coach. But knowing what might work and what might not work can go a long way to helping your teams succeed.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends)

Bill.

PS – Please make sure to register to receive updates on future Velocity Partners webinars by subscribing to our newsletter. We publish a lot of Velocity Partners information there, including details on upcoming webinars.