Getting the most value out of a process is important to any leader.  Balancing getting the most value with getting value sooner complicates the discussion.  In some cases, getting some value sooner is worth more than the same value delivered later.  Guiding the delivery of value is more complicated than a rank ordering a list of user stories and then magically hoping that everything will happen in the most effective and efficient manner possible.  Measurement is an important tool to help team and organizations ask the right questions.  To borrow an idea from Daniel Vacanti’s Actionable Agile Metrics for Predictability, measurement helps people ask the right questions sooner.  The following 6 flow metrics provide process transparency into organizations that leverage continuous flow, scrumban, and/or Scrum as the basis for their Agile implementations.  (more…)

A New Copy!

Today we tackle Chapter 5 of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability. Chapter 5, Flow Metrics and CFDs combines the concepts of flow metrics and cumulative flow diagrams (CFD). Cumulative flow diagrams are powerful data visualization techniques, combined with flow metrics the power becomes more evident. Buy your copy today and read along! (more…)

A New Copy!

Today we tackle Chapter 2 of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability. Chapter 2 is titled The Basic Metrics of Flow.  The concept of flow is critical to predictability.   Buy your copy today and read along! (more…)

 

A framework is just a framework without planning!

A framework is just a framework without planning!

Personal Scrumban establishes a framework for conquering the chaos that day-to-day life can throw at you. However having a structure, even a structure with multiple classes of service, does not get the most important pieces of work in the queue when they need to be in the queue. Planning is required. Weekly and daily planning exercises, similar to sprint planning and the daily stand-up, are useful for taming the backlog and adapting to the demands of real life.

I begin all weekly planning sessions with a quick backlog grooming session (note: when new items are added to the queue during the week, grooming can be performed). In personal Scrumban, the goal of backlog grooming is not get team consensus (no need for the Three Amigos). Rather the goal is to ensure each backlog item that might need to be tackled in the next week has been broken down so that there are one or two immediate next steps identified. The first step in backlog grooming is to ensure that all work items (or stories) have been classified by class of service. For example, if one of the work items was “Review cover art for the Hand-Drawn Slide Saturday Ebook,” the work item should be classified in the Podcast/Blog class of service. Classes of service act as a macro prioritization and assigns the work to the relevant time slice in any given day. The second step is sizing, just like in Scrum, the immediate next steps should be of a size that can be accomplished in a single sitting. The information gathered in execution will used as part of daily planning or during the next weekly planning session.

Weekly planning is comprised of getting work items in priority order and then deciding which needs to be dealt with during the upcoming week GIVEN what is known when planning occurs. If you have not already established a work-in-process limit (WIP), set one for each class of service. A WIP limit is the amount of work you will allow yourself to start and actively work on at any point. Work is only started if there is capacity to complete the task. Prioritize up to the WIP limit or just slightly past the limit in each category. Remember if as you complete tasks in a category (and you have time) you can refresh the backlog by prioritizing new items. I generally do my weekly planning every Sunday evening so that I am ready to begin the when I roll out of bed on Monday.

Daily planning is exactly like a daily stand-up meeting, with two minor twists. In Scrum, the daily stand-up meeting starts the day with each team member answering the three famous questions:

  • What did I complete since the last meeting?
  • What will I complete before the next meeting? and
  • What is blocking progress?

The three questions provide a framework to make generate laser focus on what is done and what needs to be done. The twists

In personal Scrumban, as in normal Kanban, completed work items would have been moved to the completed column of the Kanban board as soon as they done, however this is a good time to ensure that has occurred. The twists relate to how new items are dealt with and time allocation. During planning, work items that will be accomplished during the next 24 hours should be moved to in-progress. Given the nature of daily planning, if new work items have been discovered and prioritized into the backlog, they then become part of the standard planning process. The stand-up also provides time to reflect on anything that will block accomplishing the planned work items. A second twist to the stand-up process is a reassessment of the time slices being provided to each class of work. For example, if a critical work product needs to be completed, time from a more discretionary class of service can be reallocated and the work items in this category can be put on hold.

A weekly planning session provides a stage to address the week. To paraphrase Helmuth von Moltke the Elder, no weekly plan stands first contact with Monday. The daily stand-up provides a platform to re-adjust to the nuances of the week so that you can stay focused on delivering the maximum value possible. Without planning, all personal Kanban is a framework and a backlog of to-do items.  Planning puts the energy into the framework that provides the guidance and reduces stress.

Half socks are not quite as valuable as full socks

Half socks are not quite as valuable as full socks

The concept of Work in Progress (WIP) is at the core of Kanban. WIP is work that has entered the production process, but is not yet complete. WIP includes all partially finished work whether it is currently being worked on or not.  Generally in IT projects work that is not complete has little or no value. Therefore, to maximize the value delivered, teams need to move units of work from started to completed with the least amount of delay.  Minimizing the amount of work in progress delivers functionality and reduces the risk.

Minimizing WIP to the capacity of the process increases a team’s ability to complete work. All processes have a natural capacity where a piece of work can be started and completed without stopping and starting to work on another piece of work.  Software development processes are not significantly different.  However, Kaban’s emphasis on minimizing WIP is generally at odds with most of the waterfall software development methodologies that have dominated IT for the last generation.    In the waterfall model, we would do all of the analysis, usually a requirement at a time.  We would build a backlog of requirements and package them in a requirements document and then pass them through a phase gate to the next stage. In this example we have a lot of WIP and a lot of WIP that is spending sitting around being inventory.  For a waterfall project to generate value the whole project must be complete.  Kanban limits the work in progress to only those items that can be actively be worked at once.  In a manufacturing context, limiting WIP reduces the amount of capital tied up in production. In IT projects, limiting WIP gets units of work completed so they can delivered and generate value.

Limiting WIP is an effective mechanism to limit risk.  Even if work is not immediately released, the completed units of work will generate feedback which increases the probability that the work that is ultimately delivered will meet the customer’s needs.  Shorter cycles and a single-minded focus on working software help teams avoid the two biggest risks most projects face—that of eventually delivering nothing (failing) or delivering too late.

In the classic book by Tom DeMarco and Tim Lister, Waltzing with Bears, risk was grouped into five categories:

  • Intrinsic Schedule Flaws The flaw is that the project schedule is incorrect.
  • Specification Breakdowns The problem is caused by not knowing all of the requirements or that project requirements change over the life of the project.
  • Scope Creep – Requirements are added without control.
  • Personnel Loss – The problem of key individuals leaving negatively impacts the delivery of the overall project.
  • Productivity Variance – The problem that productivity variations go unnoticed impacting delivery.

Limiting WIP specifically address the first two of these categories (Kanban helps with all five) by delivering work and generating feedback. While managing work in progress requires changing how work is packaged and managed therefore is difficult.  The benefits in delivering value and reducing risk is undeniable.