Getting Real with Scrumban

Ian has worked as an Agile coach for quite a while and reflects on the fact, that whenever he's being interviewed for a coaching session, it's often the manager that he meets – not the team themselves, even though it's them that he'd be working with. So, he likes to inquire about meeting the team.

An Agile Diagnosis

As he goes in to meet them, the first thing he looks for is a board, since any team with Agile aspirations tends to have one of those. This is the main source of information about the workflow for Ian, disclosing more facts than the manager or even the team. The lanes present on the board, the cards, the consequence of the way it's kept or the visual age of the cards can tell a lot about the preciseness and state of both the board and the process.

Fast track lane?

Another thing Ian wants to check on his potential team's board is the presence of a fast lane. Having it there could indicate a maturity on the team's part, but it also may indicate that they are not doing Scrum at all. Whereas having a fast track lane is a part of Lean practices, such as Kanban, they definitely are not part of Scrum. The work items in Scrum are decided on and defined in Sprint planning and doing Scrum does not allow variation of the quality of service. If the team is working along the true lines of Scrum, there is no-one in the organization that could add a fast-track item into their Sprint.

What's the answer:

Ian provides one answer to the team's obvious question of What else are we supposed to do with unforeseen support work or necessary bug fixes?. That is: you're doing all right, the only difference is, you're not working on Scrum, but Scrumban. This is normally by no fault of the team. Usually, this is a result of poor management choices higher up, not providing a dedicated support team, which would enable the developers to focus on their work, or just by lack of motivation to make any changes.

How to proceed?

Once the problem has been identified, there is room for addressing ways to improve. The main goal is recognizing that any unplanned work for the developers is a source of impediments, basically a waste. This needs to be seen as caused by external factors, not via the team's incompetence. From there on, it's either changing the way the developers work (by fully implementing Scrumban) or assigning unplanned work to a dedicated set of employees outside this team. So, as long as you see what's happening for what it really is, any issues can be resolved.

Read our article on Scrumban »