If you work in a corporate structure that seems too dysfunctional or too rigid to adopt agile processes, you may feel helpless in your current role to affect change. Maybe you work on a small team in a command-and-control environment. Maybe you work as a single developer in your own project silo with more work assigned every week than you have the capacity to complete.
This blog post is to challenge your assumptions about your ability to affect change, and hopefully give you the tools you need introduce positive change in your organization.
Project X is currently in production, but has some significant challenges. It has suffered from the lack of developer availability since it went live. Bugs were discovered in production and often there were no developers available to fix them. This later caused the product owner and users to overload development staff when they were available for support work. The code was originally developed in project silos, with no automated test support. The code base is only 2 years old, but is effectively a legacy code base.
David Anderson, a leader in the Kanban community, has recently talked about Kanban as a “change management” system. Since Kanban has a low barrier to entry compared to other popular Agile methods, your goal should not be to make grand, sweeping changes in your environment. Allow Kanban to show you and the other stakeholders where you need to make changes.
Mechanics of Kanban
Your immediate goal is to visualize the value stream. This can be on a white board, but any wall with appropriate fasteners will do. The value stream for Project X (bug fixing) is:
Needs Prioritized –> Prioritized –> Dev –> Ready for Test –> User Testing –> User Accepted –> ReleasedRepresent the value stream on your board and track every work item (figure 1).
Next, start limiting work in progress where possible. At the time of the board photo, there was one developer fixing bugs, so the WIP limit for development is 1 (yellow highlight). Notice the two large batches of bug tickets at either end of the board. We'll explore what that means a bit later in the post.
As soon as you can track work items on a board, keep an electronic copy in a spreadsheet or tool of your choice. The critical piece of data to track is the actual cycle time per work item (figure 2). You will notice this sheet shows "Dev Cycle Time". Since the code base doesn't have automated tests, large numbers of code changes are typically batched up for user acceptance testing and manual regression testing. Given the technical and testing limitations, the project has very little end-to-end flow. So, to help with project planning in the near term, development cycle time becomes more useful. It allows the product owner to plan when a full regression test and subsequent release can occur. In Lean terms, this is not ideal, but in the context of Project X, there is value in measuring a subset of the full cycle time.
Once your work items are captured, and cycle times are recorded, you will need to capture that data on a regular basis. For most projects, a daily project "position" is adequate. At the end of each day, record the total number of work items in each state (figure 3). Unless you have a very busy Kanban board, this should only take a few minutes each day.
This historical data can be used to generate a simple Kanban dashboard in excel (figure 4). At a minimum you should include information to answer two basic and related questions: how fast are we going, and when will we be done?
Once again, in the short term, Project X is primarily concerned with calculating cycle and lead time values for the development stage.
- Average cycle time is easy: (sum of cycle times / count of cycle times).
- Lead time measures the backlog and average cycle time: (backlog count * average cycle time).
For Project X, this simple dashboard is posted beside the Kanban board (figure 1 red highlight) and emailed to stakeholders every week.
We have two immediate goals with our Guerrilla Kanban implementation:
- Generate useful metrics to assist with immediate project planning needs.
- Provide visibility to make observations and improvements to the process over the short and long term.
The Kanban board (figure 1) and cumulative flow diagram (figure 4) both serve as conversation starters with project stakeholders. The only “good” aspect of the cumulative flow is the thin yellow ribbon of development work. The WIP limits for dev work are effectively enforced. The rest of the diagram exposes a large backlog and high counts in the testing states. Work is batched up before and after development work. Even though items are moving through development at a steady pace, there is very little flow of value since bug fixes are only tested and released to production in large, infrequent batches.
To further make the point, we could contrast the average development cycle time (2-3 days) with the average end-to-end cycle time (2 – 3 months). If we desire a healthy software product and project, 3 month cycle times for bug fixes are unacceptable.
One of the top software project killers is lengthy feedback cycles. The conversation around improvements for Project X could center around ways to reduce the feedback cycle between development and testing. A potential solution would be to explore methods of automated testing. The ultimate goal for our testing phases would be an enforceable WIP limit that would ensure flow of value to the customer.
You may be wondering why Project X uses such low fidelity tools (white board and spreadsheet). There are very capable digital Kanban boards available. Use whatever works for you! White boards and Excel spreadsheets have a unique advantage, almost everyone has access to both in the workplace.
If you decide to try your own Guerrilla Kanban, realize that your effort is simply to create an environment where stakeholders have the tools to observe and make improvements. As you begin to replace developer estimates with actual metrics, you will begin to build trust. Once you have project visibility through the board and cumulative flow diagrams, you have catalysts for future process improvement conversations.
I hope this inspires you to start your own Guerrilla Kanban!
Very nice. Guerilla Kanban may just start the cultural change needed in some disfunctional shops.ReplyDelete
Indeed. Great post Troy. thank you. I really think strategies / tactics such as these if used properly will help move Kanban to the next level of adoption, as I think the hardest part, as with most things, is starting.ReplyDelete
Excellent post. I've been a Guerilla kanbanner for about five months with much luck so far. It works!ReplyDelete
A few things to point out...
1. The visibility of the kanban board is important. It starts discussions, makes problems visible to managers, and it _decouples the information from your opinion on what to do about it_. My backlog is now entirely managed by management types... before it was a mess because I've got five teams which feed my input queue and they wouldn't coordinate. This all happened because it became really apparent there was a problem.
2. Here is the question I'm currently struggling with... how do you make the case for imposing WIP limits? Say you have a limit, and you hit the limit, but you can't send your finished work to QA because they have their limit, how can you make the case and tell them you can't start on the next thing?
you don't make a case for imposing wip limits. trying to impose limits will just cause friction. instead, you should focus on setting goals to reduce your wip. start by having conversations about the problems that wip causes - delayed feedback and rework, etc. and continue those conversations into the benefits of reducing wip. appeal to the human sense of being overworked, of not being able to focus when too many things are going on. ask people how they feel when there's too much going on, and use that sensibility to suggest reducing the current wip. set small goals... for example, if you have 25 items currently in your system, set an initial goal of getting it down to 20 items. this is a simple goal on the outset and should be easy to get people to agree to. but the key is that you never enforce those limits... ever. instead you measure how often you are able to meet that goal. you won't meet it initially - expect that. what you will do, instead, is begin the discussions with your team members to identify the things that prevent you from reaching that goal. then you start to work on fixing those things. over time, you will reach the goal more and more often. when you begin to reach the current goal on a very consistent basis (say, 25 out of 26 working days a month), then you set a new goal of a little lower and you start the process again
I have to concur with Derick. WIP limits can be a goal for the team to work towards.
I would just add that conext is still king. Depending on your environment, you may want to have explicit WIP policies. In Project X, a hard limit for Dev work is possilbe immediately. But hard limits on the work downstream toward Release is much harder due to project constraints. But those would be areas the stakeholders should concentrate on improving.
Does that help?
I see you are calling out "states" within a development work flow as a value stream. Although this is just part of the value stream, should one look at the complete value stream from moment customer request shows up to the point of delivery and support? i.e see the wholeReplyDelete
It really depends on the hats that you wear in your shop. If the earliest that you see an item is after it has been approved by a BA and laid out by an architect then your board might start at 'Needs-Prioritzed' but if you start from the requirements gathering from the customer then you will most likely care about value streams such as 'Gathering Requirements', 'Awaiting Customer Approval'. If you happen to be formal QA doing your own board then you will probably not care about value streams during development or after testing.
So I believe it depends on the intended visibility and context of the board you are on, even other teams in the same department can have differing value streams.
Yes, seeing the whole is the goal. Project X is close to that given the current board. Needs Prioritized is the first state a newly discovered bug (in production) would be placed. The board could have a "releasing" state, but typically, the cards would just be removed from the board.
The important point to consider is whether your board layout will effectively show problems along the value stream as they happen.
@Brian I think localized workflows are acceptable. Some in the Kanban community use multiple boards to show this. But at some point, they still employ a big picture board that shows the entire stream from idea to cash.
This makes a lot of sense and appeals to Things I Already Know. What I need to do is show my WIP over time. I should have enough information to do this.ReplyDelete
BTW, I'm Jason Felice on the Kanban list. Don't know why my OpenID insists on "eraserhd". :(
Oh, hey Jason. OpenID has a way to go, or at least blogger.com's comment engine. The same seems to happen to me to on other sites.ReplyDelete
Good luck with your Kanban work. If you will be at the Atlanta conference, would like to chat about your experience. If not, let me know how your WIP limiting progresses.