Scrumban as a Success

I have had the pleasure of watching several teams work with Agile methods and to try and promote the better dynamics and feedback we seek in something like Scrum and Kanban. At the moment I have the pleasure of a team embracing Scrumban.

In an earlier post I covered some of the ideas of Scrumban, a hybrid of Kanban and Scrum. To adopt the process, our team asked a couple of questions.

What tools do we need?

A short while ago one team wanted a physical board but that wandered around the office and got used for other things. I do need a board, and it needs to be electronic because we are becoming a distributed team and many people like to work remotely and in our business this can be quite productive in providing ‘thinking time’”. My out-of-the-box Kanban board showed me a To Do column but it is a bit cluttered with the ideas we have that are not ready to be worked on yet. The tool I am using has a nice addition to a Kanban board – it will allow me to manage a backlog in a Scrum-like manner. Although it won’t let me see stories inside epics or versions on that backlog board.

We are using multiple Kanban boards, sometimes with the backlog extension enabled and sometime not. There is a board for project management, where we like to think a few steps into the future and require a backlog to think about. Here we only show epics (or as we think of them “features”) and we move them around according to our main strategy and tactical approach.

We also included two new status columns, “Definition” and “Selected”, to cover the need to record when a feature is important enough that we want to work with engineering to explain what is needed, and the point at which that task is defined in sufficient detail to consider starting to build it. The project management board displays only epics. From interacting with the business, epics are king since they succinctly communicate a feature the business wants, like “Provide a gobblegrok analysis tool”. The business knows how important gobblegrok analysis is, or is not, and the backlog and board can show this priority to everyone. This encourages a mindset where business team members think about what they want engineering to build in the future so that they are not writing stories at the last minute.

When the stories are completed by the business team then business and engineering meet to understand the business stories and to add in the stories for technical prerequisites. Together, these teams will negotiate what moves to Engineering based on customer wants, engineering realities, engineering time required, and business sales priorities.

Engineering uses a different Kanban board that includes the epics in swim-lanes and expanding a swim-lane will show the stories to be worked on. Things will disappear off their board when marking them to our third new state “Approved”. This allows the product and engineering teams to distinguish between work completed and tested (Done) and work now approved for release (Approved). On this board the order of the swim-lanes (epics) is the same as the order they are ranked on the Product Management board. This shows the Engineering team the same business priority that the business is setting.

Our team also believes in being open in our communication and publishes a status not only in the chat rooms but as an internal blog on our wiki pages. This is distilled from the daily and weekly meetings and validated with the key engineering team members, and can provide the other people in the firm with a description of status and progress which is easier to understand than reviewing the boards and the the chat rooms.

What regular meetings make sense to us?

Scrumban allows the adoption of meetings from the Scrum world if they make sense to the team and improve communication, to augment the Kanban world relying solely on cards. Our team finds that some meetings do in fact make sense to enhance our communication. We are a distributed team so communication is very important to us.

The team believes a regular and daily update is important to helping remove roadblocks and keeping all the team up to date. Rather than attempt a fixed meeting time trying to get everyone on the phone, our team chooses to use an IM chat room dedicated to our “daily stand up”. This allows the team to provide an update in any location, is highly accessible and a much more efficient use of time. The team all expect to post our entries around the middle of the afternoon but without needing everyone on a fixed time meeting we do not suffer from task interruption – I can post my update 10 minutes late and still be effectively communicating. This is very powerful since it takes people an average 20 minutes to get back on track after an unscheduled interruption.

The team also dedicates a chat room to engineering questions, so that the stand up channel can be clutter free and include just the status. This other chat room is closely monitored by the team and is the way the team asks and answers more in depth questions. The advantage of a chat room for this is there is an entire team answering the question rather than relying on just one person you contacted, and avoids the clutter and confusion of an email chain.

The team also believes in the benefit of a face-to-face meeting as an entire team. This is held on a weekly basis and provides an opportunity to further communicate our status and progress. In this meeting our team does a round table over video chat to cover what each person is working on. The questions and the format are similar to a Scrum daily stand-up and once everyone is assembled takes about 15 minutes. Not only does this provide a reinforcement of the daily status, but it is nice to see everyone’s face each week and retain a personal touch between the physically separated teams.

I confess I was a little skeptical over the idea of doing so much over just IM as my prior team was very much into a regular conference call and person-to-person calls, but I am now a convert and I think this is working very well.

In summary, Scrumban might not be for everyone but for our team this is the right choice of flexibility and responsibility. It is more self-directed and that requires some team dynamics that might not be available to all teams but if you are fortunate enough to have a team like the one I work with, then a hybrid approach of Scrum and Kanban might be just what you are looking for.