Kanban Practices that fuel Scrum Team Collaboration

I was a Scrum Master for a Scrum Team that was building a sales application in the energy industry. The Scrum Team had been working together for several months when I began noticing a pattern in three consecutive Sprint Retrospectives. The team would frequently discuss how they needed to further collaborate on Product Backlog Items (PBIs) during a Sprint. Several times, they committed to working on pieces of work together rather than in silos. But to no avail, they would fail at their commitment and would fall back into their old, siloed ways of working. 

Developers on the Scrum Team felt like they were often moving in different directions. Individuals would grab a piece of work, build it in their silo, and merge it into the others’ work. Working in silos was creating quite a few problems for the team. Most notably:

– Code quality and cohesion issues were running rampant. 
– Testers often were getting piled on late in the Sprint. 
– Arguments over design decisions came late and were often heated debates. 

This ‘team’ resembled more a cooperating group of individuals than it did a collaborating Scrum Team. Despite the commitment to working more together, it never seemed to come to fruition.

As Scrum Master, I felt like I was failing the Scrum Team. But what could I do to help bring transparency to these issues and give the team a better chance of working together moving forward?

During a subsequent Sprint Retrospective, I shared with the Scrum Team the trend of them trying (and failing) to further collaborate on work. The team agreed but just didn’t know how to make further collaboration happen. They asked me for suggestions on practices they might use to help solve this issue.
My first suggestion was to limit WIP (Work in Progress) as a tactic that might further enable them to work together and create focus in the Sprint. The team had a visceral reaction. I went on the defense trying to sell the value of limiting WIP but quickly gave up and pivoted. 
The pivot was to introduce the concept of Work Item Age (the time between when a work item has started and the current time). It was a less radical change in their eyes and something rather easy to measure. The team agreed to make Work Item Age a central part of the discussion during a Daily Scrum. The Daily Scrum, to the team, was a natural place to inspect Work Item Age and adapt how working together might keep something aging unreasonably. 

For the next two Sprints, I observed the Daily Scrum and noticed a newfound attention being brought to what work was in progress, who was working on it, and how others might help. Work Item Age was enabling conversations that hadn’t been there before. Conversations went from stagnant to focusing on what could be done to keep an item aging beyond reason. The team was succeeding at collaborating on work! 

Over time, the Scrum Team became more open to additional practices such as limiting WIP (Work In Progress) and a SLE (Service Level Expectation). They saw the value in other flow-based ideas that I would introduce all because of being cognizant of Work Item Age. I witnessed a cooperating group of individuals turn into a thriving collaborative team. The silos were busted and the aforementioned problems disappeared. This team was delivering!

Scrum is a framework for which many complementary practices exist. Scrum Teams often struggle to identify ways to work together. Implementing Kanban and Scrum together creates transparency around issues you may not know how to solve or didn’t even know existed.

Todd MillerAgile for Humans