Last week, Scrum.org and leaders in the Kanban community published a new guide. This guide helps articulate how Scrum teams can use Kanban to complement the Scrum framework. I blogged about this guide on the Agilethought site. Read my post, debunking three misconceptions about Kanban and Scrum.
Have you wanted to try a simple and free personal Kanban board? Turn your Windows 10 Desktop into your own Kanban board, and use Sticky Notes app to represent your tasks.
I used Photoshop to create the image with columns “to do,” “doing,” and “done.”
If you don’t want to use Photoshop to make an image, you could just as easily use the computer desktop kanban board I made, or create your own using PowerPoint’s “Save as Image” feature to make your own slide, and then set that image as your desktop.
If you have your own workflow, you might consider making a PowerPoint slide and use PowerPoint’s “Save as Image” feature to make your own board.
Regardless, once you have an image, you can set that image as your desktop in Windows 10.
Now, all you have to do is use the StickyNote feature to put notes on your background and move them through the Kanban.
Granted, this is an elementary implementation of Kanban, since Kanban is more than cards on a wall. For a fuller implementation of Kanban, measure and manage flow. But at least this creates some visibility hopefully focus for you.
If you are new to the concept of Personal Kanban, check out the Personal Kanban 101 introduction. Make your work visible, and limit your work-in-progress.
What personal Kanban approaches have worked for you?
If you use this image, please leave a comment about how it worked for you.
If you’ve slapped up a board that says “to do,” “doing,” and “done” and called it Kanban, that’s about the weakest implementation of Kanban that is possible.
If you’re interested in really harnessing the Kanban framework, you have to go beyond three columns and:
If you want to learn more about using data with Kanban, go get a copy of Daniel Vacanti’s book on agile metrics from leanpub, or on Amazon. Read it.
Then, get a trial to Actionable Agile. This tool visualizes data, and integrates with multiple platforms. Watch the videos on the ActionableAgile YouTube channel that gives an introduction to the tool’s capabilities.
Now, use the data and a never settle for “this is as good as it gets.” Dig in and improve your process!
Honestly, it doesn’t matters. If it helps an organization create value for its customers in a way that allows employees to experience freedom while solving challenging problems, it doesn’t matter what label the method carries! But, that would be too short a response.
One way to decide if something should wear the label “agile” is to look at how it reflects the values stated in the Agile Manifesto. Of the Agile Manifesto statements, this is how Kanban values the “items on the left” over those on the right.
The visibility that Kanban provides to teams is a key contributor to facilitating interaction amongst individuals. The kanban board gives visibility to impediments that individuals are encountering makes resolving the impediment of prime importance.
Unlike Scrum, Kanban does not explicitly encourage generalization of skill sets. While Kanban does not force you to have a role for every queue, it is often easy to start by mapping the roles to queues and then inspect the bottlenecks and address those by helping the team develop more generalized skills.
Kanban is not a tool or a process that supersedes the importance of the individuals and their interactions. Yes, Kanban provides a lot of metrics that can be used to inform planning. However, the metrics are to facilitate interaction among team members, between team and stakeholders, and between team and customers.
When using Kanban to produce software, there are specific characteristics of Kanban that allow you to value working software over comprehensive documentation; small batches, WIP limits, measuring and managing flow. Perhaps your workflow will have a step or steps related to creating documentation.
Kanban does not prescribe working software, other than through mapping your value stream. If the last step in the value stream is working software, you can use Kanban as a tool to make sure you do that.
Kanban encourages customer collaboration through the prioritization of the backlog. Prioritization of the backlog is an ongoing process. Agile Kanban practitioners often use user stories or minimal marketable features (MMF). Use of either of these approaches supports customer collaboration in creating those items. The person who provides the detail on the stories or MMF is also available to the team to respond to questions.
As in Agile, daily standups are also present in Kanban. Unlike Agile, only people with issues speak in the daily standup. The standup meeting is an opportunity to speak up, whereas in Agile the traditional “three questions” are often present. This gives the team an opportunity to elevate issues to the Product Management representative’s attention, allowing them to be a partner in the process.
Silver Bullet Policy (see slide 20 for a brief overview) allows the customer to swap out an extremely high priority item for the current work in progress. There needs to be a swap so that WIP limits are not exceeded. Silver Bullet Policy may never be used, but can give the business the feeling that if there is an emergency, they can use this policy.
Agile teams often plan on a regular cadence. In Kanban, planning events can be triggered on an event. For example, your team may have a rule as follows: When the backlog backlog has dwindled to ten stories, a planning event will be held.
Unlike Scrum or XP, where the teams try to identify a piece of stability to work on for a period of time, Kanban allows the team to re-prioritize the backlog at any time and take something new off the backlog. This allows the team to respond to change sooner than if they were locked into a set sprint duration.
While Agile is primarily focused on software, Kanban is more focused on developing a lean organization . In fact, the business-oriented language that surrounds Kanban may make it an easier Agile model to embrace than Scrum.
While an organization or team can claim to be using Kanban and use it in non-agile ways, that will not be the case when done well. If the team and management use visualization, set WIP limits, and iterate on the value stream, Kanban is an excellent option for Agile teams.
There are lots of excellent resources on Kanban. My favorite reference is a book called Kanban – Successful Evolutionary Change for Your Technology Business. Thank you, Eric Landes, for loaning me your copy for a while. For further reading, check out the InfoQ version of the Kanban and Scrum Book.
A special thank you to Eric and Susan for co-authoring this blog.
