Quantcast
Channel: The Agile blog of Seedbox's agilers | Le blog agile des agilistes de Seedbox » agilers
Viewing all articles
Browse latest Browse all 3

Selling Kanban: The Dot Game

0
0

One of the teams that I scrum master for has an operational component. How does this operational division work within a scrum team, you ask? Simple: It doesn’t. When I started working with this team, the mailing department (or as we prefer to be called, Weapons of Mass Conversions, or WMC for short), we tried very hard to use the scrum framework to manage the entire team. We quickly realized that trying to use scrum for our entire team was like trying to fit a square peg into a round hole. The WMC team is comprised of 2 developers, 1 integrator, 1 designer, 1 email marketing manager, 1 deliverability expert, a product owner and a scrum master. From 30 000 feet, our purpose is to promote our products through email marketing campaigns. Last week alone, we sent over 15.5 million emails to our customers. Accomplishing this feat on a weekly basis is not easy. It requires a very sophisticated, fully customized technology platform built by our development team (DEVs) that works in concert with our highly skilled operational division (OPS). OPS and DEVs are joined at the hip. The OPS team relies on the technology platform that the DEVs built and continue to build in order to send out our email campaigns, which means the OPS team members are actually stakeholders in many of the user stories that the DEV team works on out of our product backlog. From an agile/scrum perspective, it’s pretty interesting. Unsurprisingly, scrum worked very well for managing our DEVs, but the same results were not forthcoming when it came to the OPS. We knew that DEV and OPS had to work very closely together in order to accomplish our goals, but it was becoming increasingly obvious to us that we could not use scrum to manage the entire team.

We decided to use kanban to manage the OPS. Kanban is a meta-process that allows the team to measure and manage flow through explicit policies, to improve collaboration and to accurately identify bottlenecks in its processes. We started out with a physical kanban board, to ‘test it out’. This was an unmitigated nightmare; the image of team members standing at the board with stacks of work cards in their hands grumbling at the ridiculous overhead that we had just added to their daily workflow will forever be burned in my brain. The life cycle of a work item in any given state on our kanban board was extremely low: from 5-15 mins. Result: team manages minutiae, not work flow. In retrospect, it’s pretty comical how anti-lean this first experience actually was. It was in fact, the definition of waste.

And so we went back to the drawing board… literally. That’s how you come up with your value stream, right? By drawing stuff on a board. Cool. We mapped out our workflow again. During the these meetings it became obvious that I hadn’t fully championed what kanban could do for the team – to be more collaborative and more efficient, to work smarter, not harder. I realized that I had erred in my initial approach. I falsely assumed that the value of kanban would reveal itself to the team. What I didn’t take into account was that the OPS team already had their own workflow which they managed in a specific way and when we added kanban to the mix, the team simply added kanban as an administrative layer on top of their legacy workflow. Why? Because I had failed to properly introduce kanban to the team, and as a result they couldn’t see the value, and didn’t buy in. This realization weighed heavy on my agile soul. So one evening while watching PVR’ed Big Bang Theory episodes with my wife, I began to plan my kanban 2.0 (or 3.0 if you include the physical board) workflow and sales pitch to the WMC OPS team. I decided that I was going to use “The Dot Game” to prove to the OPS team that kanban was cool and that all the kids were doing it.

kanban2.0

The Kanban 2.0 “plan”.

A couple of months ago, while attending Agile Tour Montreal 2012, I participated in a kanban workshop where “The Dot Game” was being presented. The Dot Game is a simulation of a kanban workflow scenario. Check out this PDF for details on exactly what The Dot Game is all about: http://www.netobjectives.com/resources/articles/the-dot-game.

I thought the exercise did a phenomenal job in exposing the purpose and value of kanban in a practical, easy to understand and fun way. I knew that The Dot Game would be critical in showing the value of Kanban to the OPS team, and I highly recommend this activity to get buy in from a team when trying to implement Kanban. The response from the OPS team was extremely positive. Many team members commented that they now feel that they have a much better understanding of what Kanban is for and how they can use it to their advantage.

It was really amazing to see how quickly the team improved their overall organization and their process after only three 5 minute iterations of the simulation. The team quickly recognized how setting WIP (work in progress) limits reduced batch sizes and allowed them to “stop starting and start finishing” (one of my favorite kanban clichés that I just had to throw in this blog post). The dot game helped the team to understand the importance of explicit policies, visualization and metrics, the fundamentals of kanban. And having the opportunity to reflect after each iteration of the game provoked real kaizen; the team developed a better overall picture of their work environment and the changes they could make to improve it. And finally, the team also realized the necessity to find equilibrium between demand and capacity.

Really? This simple dot game exercise taught the team all that? Yes, it did, and the team is reaping the benefits as I write this. From an agile perspective, I think that the team’s experience with our first two (failed) implementations of kanban contributed to the success that we are having with kanban today. We tried something, it didn’t work. We made adjustments and tried again. One of the first things that I learned about agile is to not be afraid to try and fail, as long as you learn from your mistakes and improve.

WMCTEAM

WMC Team

By Sean Steacy
ScrumMaster


Viewing all articles
Browse latest Browse all 3

Latest Images

Trending Articles





Latest Images