I like beginning new projects…

I like beginning new projects while endings make me sad. Beginnings are full of possibilities. Often the end of a project is the last you will see of the people that you have spent hours laboring over problems, sharing meals, stories and, in short, becoming a team. The day-to-day interactions and frictions that create a team are fundamentally different from hallway conversations or the occasional catch-up lunch.  In organizations that dynamically reframe teams to meet the next opportunity, all of accumulated team capital based is jettisoned based on the a mistaken idea that the “thing” that makes a team a team is fungible.

In many organizations that see work and people as an assembly line teams are re-formed at will.  The goal of re-forming teams is to deliver efficiently as measured in productivity, or how much of something that can be produced per unit of work.  Widgets per hour, lines of code per hour, test cases per month are all expressions of productivity.  However productivity as a measure for software development and enhancements can only be used at a project level to measure output and can only be confirmed at the end of the project. Productivity is a measure of output, which reflects the impact of other variables – like moral, methods or complexity.  Because productivity is measured at a project level it lacks the granularity necessary to see the dip in productivity that ALWAYS happens early in projects when random individuals are combined into a “team.” This tends to leave the team behind the eight ball. Because this initial slow down is not planned, the organizational productivity and delivery expectations can’t be met without overclocking the rest of the project.  This compresses activities, which will cause technical debt and project stress. Technical debt injures the company and the company’s long term perception of IT and the team.  Project stress injures the team reducing its productive capacity potentially starting a negative cycle of decline.

First snow, first kisses, first pages of new novels…all are full of possibilities, full of anticipation.  We can spin any story that we want though the starting.  It is only after the next step that our path begins to be constrained if we assume a deterministic path rather than viewing the past as a sunk cost.  We can maximize the possibilities of beginnings by projects with stable teams so that we focus on delivering value rather than reforming linkages and relationships.

 

Kanban: Getting Started

Making a cake is a process.

Getting started using Kanban is deceptively easy – there are just three steps. The first is visualizing the flow of work, the second step is setting work in progress (WIP) limits and the third is documenting process policies. Visualizing means developing an understanding of the steps that are taken to complete a unit of work, such as a project. A WIP limit represents the team’s normal capacity to handle work in each of the visualized steps. The third is to document or create the policies that will govern the process, such as classes of services and how interruptions and expedited items will be handled. The process is simple and concise, however, the devil is in details.

Visualizing the flow of work begins as a mapping process. Initially, use a technique like value chain mapping , activity network diagrams or just plain process flow charts to document your process. Diagraming the process flow on paper or in a tool before translating it to the Kanban board allows the team to discuss and make sure the flow accurately reflects how work is done. The flow below represents the process I use to create the interview segments for the Software Process and Measurement Cast.

Software Process and Measurement Cast process flow.

When you are convinced that you have the process laid-out correctly construct the Kanban board. If using time-honored methods of a white board or brown butcher paper, I typically define the start and end points for the flow and then fill in the middle parts (adding a column for the backlog at the beginning and a column for done at the end).

Generally there is a lot of pressure to “redesign” the process as soon as you have put down on paper, on a physical Kanban board or into one the great Kanban tools. Resist the urge to change the process until you have begun to use the board and see where the bottlenecks appear. Waiting to see how work flows allows process improvements to be made based on data rather than opinion. Also using the work flow visualization as a feedback mechanism will allow the team to reverse changes if they don’t work.

The next step is to set the initial WIP limits. This can be a bit of an art. One method is to set the limit for each step at one for each person assigned to the step. For example, my podcast flow would have a WIP limit of one for each step (my podcast empire is . . . me). Another method is to use a recently completed project as an example and walk through the process with the tasks to estimate the limits. When using this method, the team should continually ask whether each team member was trying to work on more than one item at a time. This an important question because multitasking is an indicator of violating WIP limits. Another method is to simply begin a project. This is a variant of the one WIP per person method. In this method, each team member begins by pulling a piece of work they can do. This number is used to set the initial WIP limit for the categories of work that are initially possible. As work progresses more and more of the process will be used and WIP limits identified. This method can mean that initially some team members will be engaged in work that is not their specialty. This is where having team of specializing generalists (a person that can do more than one thing, but does have a specialty) comes in handy, as team members can pitch in and help in more than one step. Regardless of the method used each person should focus on a single task at a time. Adjust and experiment with WIP limits to minimize the time it takes for work units to move through the process.

The final step is to document the policies that will be used to govern the process. All policies should be explicit and transparent. It is very hard to govern a process with hidden policies. Also when you have to guess what the process is, it very hard to test the policy to see whether it can be improved. Polices that need to be defined include the WIP limits, classes of service, how to handle interruptions and how temporarily breaking WIP limits will be handled. I generally have team members and their managers define the initial set of policies as part of a project or support chartering process. The chartering process gives the team a chance to get all of the rules on the table, discuss them and then cleanly begin.

Beginning to use Kanban is a fairly straightforward three-step process. One, map your current process and convert it into a Kanban board. The board is in essence an overlay on top of the process you use today, which makes beginning to use Kanban less contentious. Make changes to the process only after you begin using it and you have visual evidence of a bottleneck. Two, set initial WIP limits. This part of the process might require some experimentation, however always err on the side of overly constrained as it will always be easier add to the limit than decrease the limit (this is just human nature). Finally, define the policies that will govern the process. The whole team and their managers should commit to be governed by the agreed on policies. Three steps . . . no more, no less. Each one will require careful consideration and discussion, which is why the devil is always in the details.