Refactor Work with the Structure of Kanban and the Energy of Scrum
Switching planning and execution methodologies can be a difficult task; this guide will help you to adapt Scrum and Kanban to your needs
Join the DZone community and get the full member experience.Join For Free
One of my clients was struggling with Kanban vs. Scrum as a starting place. They really like the energy of Scrum: teams, collaboration, learning but from a workflow perspective needed the adaptability of Kanban: urgent requests, different ticket types, able to change direction quickly. This happens when the management and culture is there but there are too many short-term needs and/or external dependencies.
This is not new for me. I have been helping clients with this situation for the last few years – finding a comfortable hybrid between Scrum and Kanban. What is new, is that I finally made a drawing that summarizes what the flow looks like. Hope you enjoy it.
The left side of the diagram illustrates what typically happens with most Agile teams I work with. It doesn’t matter whether you are using Scrum or Kanban, teams usually benefit from:
- Sense of purpose (vision)
- Inception Deck – this will save hours or days if you have a month long project. Skip at your peril.
- Stories (or tickets)
- Effort estimates (Story Points or S, M, L)
- Rough plan (backlog) – here it is depicted with a form that matches the structure of the work – by feature area what we do now, later and even later.
- Ability to make forecasts on work
In the diagram, artifacts are in dark green and activities are in light green.
This diagram shows a physical board that helps teams collaborate to get work done. It is essentially a Scrum Board that where the team uses a single story pull model instead of a sprint batch model. One big difference is that there’s an expedite lane for urgent work. Let’s walk through the columns.
- Next: Here we see the stories for the team to work on next. Often this box sits on the backlog board – doesn’t really matter where it is as long as everyone knows what to do. Some teams skip this an pull directly from the ordered and prioritized backlog.
- Planned: A Planning meeting may structurally be the same as a Scrum Planning meeting, but here we are only planning one story at a time. Stories are broken into tasks to increase shared understanding of the work. So it may be the whole team but more likely just the subset of the team that needs to be involved in that story. Of course, very simple, small tickets or stories, may just go to in-progress without creating tasks.
- In-Progress: What tasks/tickets are getting worked on by whom. The Daily Standup meeting is where we make our best plan for the day. We may walk the board backwards to focus on completing work.
- Done: What tasks/stories are done. We may have Demo and Review meeting on a weekly or bi-weekly basis to check against our definition of done and show our progress.
- Retrospective: We meet at some regular frequency to learn how we can work better.
Structure of Kanban, Energy of Scrum
“Energy of Scrum” means keeping the essential bits of Scrum that makes it unique and valuable. These are:
- Shared Ownership – the team is collectively responsible for delivering. One small example is that we may have a task labeled “testing” (that anyone can do) but there is no Kanban step for “QA”.
- Learning – there is a large focus on learning culture. This comes through retrospectives and Scrum Master(!).
- Scrum Master – A Scrum Master represents and investment in learning and getting better. It’s about having someone focused on growing the system. This role works great with Kanban!
- Team Alignment – In Scrum a premium is placed on keeping a team in sync through planning, review, standup. Keeping these meetings let’s us keep the high levels of alignment.
Published at DZone with permission of Michael Sahota, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.