When I started writing this blog entry I tried to remember all of the books that we have re-read (or read for the first time) on a weekly basis.  I couldn’t remember.  When I look at the statistics for the Re-read Saturday entries they are almost always in the top ten, month after month so it doesn’t matter whether I remember each of the entries (I added a task to my backlog to find them all) because you find and read them.  Two weeks ago I went on holiday, backpacking on Isle Royale. It was a total unplug. During that time I ran a poll to select the next two books to re-read.  The answer is: 

(more…)

A New Copy!

Today we tackle Chapter 3 of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability. Chapter 3 is titled Introduction to Little’s Law.  Little’s Law is incredibly clever and potentially life-changing if you are overly fixated on size.  Buy your copy today and read along!

We originally wrote about Little’s law in September 2014. Little’s Law brings WIP, Cycle time and Throughput (metrics discussed in chapter 2) into a relationship that can help deliver information that can be used to answer the basic questions of predictively. The basic configuration of Little’s law is stated as: (more…)

IMG_4333

A New Copy!

Today, Chapter 1 of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability. Chapter 1 is titled Flow, Flow Metrics, and Predictability.  Vacanti jumps directly into the deep end by suggesting a way to answer the age-old question, ”when are you going to deliver?”  Buy your copy today and read along! (more…)

Listen Now

Subscribe on iTunes

One last week in mixtape format! I am completing a trip that is a mixture of vacation and a board meeting but that does not mean you have to forego your weekly SPaMCAST.  In place of our normal format I am posting a mix tape of the answers to the “If you could change two things” question I have been asking interviewees for nearly ten years.  This week on SPaMCAST 393 we feature our top downloaded podcasts from the year 2010:

SPaMCAST 85 – Cory Foy on Agile Coaching

http://traffic.libsyn.com/spamcast/SPaMCAST_85_-_Cory_Foy_Agile_Coaching_Collaboration_Part_1.mp3

http://bit.ly/1Qmmx0g

Cory used his wishes to discuss the obsession with certification rather than performance and bring user into making critical business decisions so that usability is maximized.

SPaMCAST 92 – Don Reinertsen on Product Development Flow

http://bit.ly/1WERCDZ

Don used his wishes to ask that people understand the economics of product development and then to use that understanding to measure and reduce WIP queues.

SPaMCAST 94 – Ivar Jacobson on SEMAT

http://bit.ly/1SYSmhA

Ivar discussed the SEMAT core defining software engineering and how SPaMCAST listeners can support the development of SEMAT.

If these excerpts tickled your fancy listen to the whole interview by clicking on the links shown above.

Next week we will return to regular programming with a thought provoking interview.

Functionality should flow like a river.

Functionality should flow like a river.

Kanban, which means signal card in Japanese, has been a staple of lean auto manufacturing for years through its application in the Toyota Production System (and in lean manufacturing environments).  Typical IT processes work by pushing work through steps, with work piling up at bottlenecks. Units of work stuck at bottlenecks are not gathering feedback as quickly as possible, which increases the likelihood that, when a defect is found, it will affect many pieces of work rather than a few. Kanban works by pulling work though the development process, also known as a value chain, so that work-in-process (WIP) is minimized. Kanban is a simple concept, but its application tends to challenge many of our previously held notions of how IT organizations should work.  Kanban fosters the delivery of a flow of individually prioritized work items rather than the delivery of large blocks of functionality all completing at once.  In a Kanban environment the delivered work items are generally grouped into periodic releases, which doesn’t fit the common definition of an IT project.

Alan Shalloway, of Net Objectives, recently suggested that Kanban has evolved into three streams of thought.  They are:

  1. Kanban Method (a branded method championed by David J Anderson)
  2. Kanban as a thought process to be applied with other Agile and Lean processes (championed by Alan Shalloway, Karl Scotland and others)
  3. Kanban as a method to manage workflow (championed by Corey Ladas)

These are all variations on a theme. Merging the core practices from each of these variations yields a broader set core practices for Kanban.  These core practices extend the usefulness of Kanban to most, if not all, IT delivery processes:

  • Work must be visualized. Kanban is nothing if it not a visualization of a work or value flow. The more public the visualization, the better. Visualization helps the team and stakeholders guide the work so that it provides the most value. Visualization also helps control work entry and interruptions.
  • The goal is to manage work so that it continually flows.
  • Each step in the workflow will have a limit to the amount of work that can be in progress (WIP) at any given time. WIP limits reduce multitasking, switching and “inventory.” WIP also reduces waste and increases flow.  The WIP in process limit should not be systematically violated.
  • All policies that guide work (definition of done, work-in-progress limits, work entry process, how work is approved and others) must be explicitly stated.  Explicit rules facilitate discussion and refinement which leads to greater flow and efficiency.
  • Implement feedback loops to ensure transparency and help regulate the process. For example, the team needs to know when work has to wait, so they can either swarm to the bottleneck, regulate work in preceding steps or to refine the process.
  • Kanban provides the information to improve as a team and evolve using models and the scientific method.  Begin slowly by implementing Kanban without process changes until data is gathered.

Below is a basic implementation of a Kanban board based on the core practices:

Kanban helps to visualize the flow of work.

Kanban helps to visualize the flow of work.

In Kanban work is pulled to the next step only when there is capacity for the work in that step to begin. When the work unit is pulled into the next step it will reduce the amount of work the sending step below its work-in-progress limit, allowing it accept another unit of work.  For example, if the analysis step had a work-in-progress limit of 4 units of work and 1 unit was pulled into development, 1 unit could then be pulled into analysis from the backlog. All work items that are in progress should be being worked on at all times rather than waiting in-between steps. When work sits it is considered work-in-progress or inventory (or waste, to use a lean term). Continuously measure the flow of work through each step until it is done. Challenge the team to maximize the flow through the process.  Updating the process to minimize wait states and WIP leads to evolutionary change.

Kanban represents is a significant paradigm shift in how IT works today. It is a shift from a push to a pull method. Using a pull method puts the focus on the improving the flow of work though the development process. Ultimately, it improves efficiency and delivery of business value.

Savannah River

The majesty of a large river can sometimes overwhelm the underlying message of flow.  When under control the continuous flow of water past any point is a metaphor for the flow of work through a process.  The flow of work is like that of the river continuously delivering value.

Constraints that impeded the continuous can introduce significant problems requiring rework  or scrap.  Just ask folks in Southern Louisiana about where the Mississippi really wants to go and the benefits and problems that redirecting the Mississippi has caused.  Engineer processes in a manner that provides as continuous a flow of value as possible!

Image

Subways are great things!  I am not sure I understand how large cities operate without some sort of train system.  However, a subway is not a great metaphor for process improvement projects (or any other kind of project).  Trains barrel into each station, slam on the brakes and then whisk themselves back out.  If the your goal is to get off at a specific station then the starting and stopping at each station is important. Just try getting off or on in between stations.  If your goal is to get to the end of the line (the end of the project) then starting and stopping is less than optimal.

Also if you are reading a book on your electronic device the start and stopping can lead to getting off at the wrong station . . . again.