Wow, what a “newsy” sounding title… What I want to do is show how we will use Kanban to track all of our software maintenance activities. I’ll start with a couple of useful links about Kanban as a technique:
http://www.software.craftysims.com/?p=184
So I have been on board OPP for about a month. My observation is that we have a clunky CM process (CM really means change managament even though everyone thinks it is configuration management), meaning it actually gets in the way of our work; too many meaningless “sign-offs” and meetings to make obvious decisions. It also has certain loopholes that get activated that allows more vocal users to get their way ignoring the processes that ensure we deliver business value in our maintenance activities.
In discussions with our project managers, we determined we needed a simple pull-based process so that our development contractors could feel empowered and we woudl know they are delivering business value; after all we are responsible for the public trust. Kanban seemed like a useful technique, along with some important improvements in definition around issue Severity and Priority. This will be an experiment we will run for several months to see how it works for us; holding regular retrospectives every 3 weeks.
BTW = our issues go by the name of Software Change Request (SCR). So when you see SCR, just think issue. 
The slide to the right describes the rules we will use for Severity & Priority. Severity is the technical prioritization component and Priority is the business prioritization component. Severity is set by our project managers, while the business folks set the priority. As our usage matures, we expect that ANYONE will be able to set these, but we aren’t there yet.
Using these rules will allow a developer to clearly know what to take from a queue and to work on. Once an item is in-work; only a Critical Severity item or potentially a Major Severity item that is ALSO high business Priority can override what is currently a work in progress. 
The slide to left describes the prioritization schema we will use. Again once everyone (including our customers) gets an understanding of how this works, we anticipate anyone will be able to set these. When I describe some of our immediate observations, you’ll see why we have segregated the responsibilities for now between the PMs and business folks.
So what does it take to set-up a Kanban wall? Not much really… You need some useful way of representing your work-in-process(es) (WIPs) and your queue(s). For us, we are tracking more than i would like, but it wasn’t so much of a chance that I couldn’t get buy-in. I hope we can “reengineer” this process later down the road to make it simpler. 
It does take a LOT of thinking and it WILL take a LOT of hard work to get it ingrained culturally. That’s truly the hard part…
For our Kanban Board, we took over a nice clear wall space near our developers; we segregated the WIPs and queues with painter’s tape. We will be using color coded stickies (post-it notes) to show the severity, and horizontal swimlanes to represent the business priority.
Colored dots will indicate whether something is a data fix, bug, or feature/enhancement. Colored flags will indicate the technology base it uses.
OK, while that was time-consuming, it was easy. Now how to get 296 issues onto the wall? I decided in order to reduce resistance, I would print out reports from our issue tracker system with the basics of what was on a Sticky; I would tailor the queries based on Severity and Priority so I can put them in the right box.
CHALLENGE #1: We have established clear rules for Severity; the current Severity categories not only do not match the new ones, they also have only one rule: the willingness to bump it up to management attention and be declared X severity. So I can’t dissect it that way. We will re-triage each Issue and properly categorize the Severity level. this will be time consuming, but worth it. To keep it simple, we will use highlighters in the same colors of the severity stickies to highlight the Severity on the reports; only the blue color won’t be used (we’ll leave Minor Severity white).
I could break reports into High, Medium, and Low; I am not sure I and perhaps our customers will agree with these as the customer used Severity to get attention, not Priority.
CHALLENGE #2: Our tracking system had some nonsensical “states” with SCRs in them. What the heck is pre-approved? No one knows. I and another gentleman in my office spent a couple of hours making educated guesses as to what states they really should be. Some were obvious (at least to him since he had been here for years) and others weren’t. What we wound up with is to the right.
One immediate issue you can see (hopefully) is that we have very few Low Priority issues – literally 4! Yet we have 6 pages of High Priority issues supposedly In Development (WIP) right now! Hmmm… Here’s a VERY apparent issue to investigate. w00t! Pay-Off!
As Issues (SCRs) get worked we will line them through on the report and create a sticky, consolidating the reports as issues come off them. Eventually there will be zero reports and only stickies.
Just to help everyone understand our flow, the slide to the left has our WIP and Queue phases.
We expect we will be changing this (hopefully to make it simpler) and our retrospectives will hopefully guide where the changes need to be made. So far so good, everyone in the IT shop is looking forward to seeing how this will work and seems to be behind it. I invite any questions as comments.
————————————————————————————————————————————————————————
UPDATE 10/30/09:
Here are a couple of shots of our board as some of the items come alive as individual stickies. The first shot is the entire board. You’ll see a couple of Minor (cosmetic in nature) severity items (in blue) that should be low priority (lower swimlane) AND some Moderate severity item (in yellow) that are high business priority (upper swimlane) that we decided to “grandfather in”. We annotated them with a pink border (to signify they constitute an “emergency”, which equals Critical in our new terminology. It highlights the problem with the old way of prioritizing, which was what ever business owner screamed loudest.
The second photo is a closer up one of just teh 4 yellow ones. We hope by usng thse as examples, we can show-off WHYwe shouldn’t be concentrating on these compared to what we should be working on.
[…] I concentrated on further process improvements before I thought of increasing headcount. (You can read about the Kanban system that was set-up on GovLoop if you so […]