“Errors using inadequate data are much less than those using no data at all.” – Charles Babbage, English mathematician, philosopher, inventor, mechanical engineer, invented the first mechanical computer (1791 – 1871)

“I always avoid prophesying before hand, because it is a much better policy to prophesy after the event has already taken place.” – Winston Churchill, British orator, author, and Prime Minister during WWII (1874-1965)

“Policies are many, Principles are few, Policies will change, Principles never do.” - John C. Maxwell, evangelical Christian pastor, speaker, and author of 60+ books primarily about leadership (1947 –   )

“We’re entering a new world in which data may be more important than software.” – Tim O’Reilly, founder of O’Reilly Media, supporter of the free software and open source movements (1954 –  ) 

This question below came up recently on our Agile Denver Kanban SIG (special interest group) LinkedIn discussion list.

“I am working for an organization that has ‘Lab Week’ six times a year. Lab Week encourages innovation by setting aside time for engineers to work on whatever they want. My current conundrum is, what do I do with the work items on my team’s Kanban board, specifically those in To Do or Doing, during Lab Week?

It feels wrong to put them back in the backlog, but keeping them in To Do or Doing will affect lead/cycle time. While this is reality, it is only reality six times a year. In the interest of predictability I think I would want to know what lead/cycle time is without the impact of Lab Week and then factor in Lab Week when we hit a Lab Week.”

I had two immediate responses to this interesting question. First, teams in a number of software development and IT/IS organizations are familiar with the basis for this question, and I’m guessing it comes up in a number of non-IT/IS or non-software development contexts as well. 

Second, there is already an upfront discomfort with the idea of moving workitems back to the “backlog” that have been “pulled” into the ToDo (or Ready, On Deck, etc.) workflow process states. I’m wondering what signal is this discomfort providing to us? I’m guessing the discomfort is even greater with the idea of moving workitems back to the backlog that have made it to some state of Doing in the workflow process. In essence, this would be “resetting the clock” for a number of workitems already considered work in progress for some period of time, and with expectations I’m sure they would be completed within some known SLA.

Just what I like, “real world” questions in particular when they come with some “pain points” clearly identified upfront. As I continued to think about this one more, it felt like a “perfect” opportunity to raise what I feel is a related question and discuss them some together in this post. When discussing metrics as part of measuring and managing flow, the question below is one I raise often with others who are applying the Kanban Method to their workflow processes.

“In your workflow process context: Does Data Shape Your Policy or Does Policy Shape Your Data?”

How might we in the case of a “Lab Week” produce the metrics we want and visualize this information without any “discomfort” of doing post collection adjustments or moving (resetting) workitems back into the backlog? What can we learn from thinking about and responding to this “Lab Week” question that applies beyond the original basis itself in how we develop policies for managing our workflow processes?

(continue reading…)

“Science and technology revolutionize our lives, but memory, tradition and myth frame our response.” - Arthur M. Schlesinger, Jr., U.S. historian. “The Challenge of Change,” New York Times Magazine (July 27, 1986)

 “A myth is an image in terms of which we try to make sense of the world.” - Alan Watts, British-born philosopher, writer, and speaker (1915 – 1973)

“What is the Kanban Method?”

• It’s not about replacing your current software development process.
• It’s not about changing or removing your team’s current titles and roles or adding new ones.
• It’s not about a process that is only for support, maintenance, or “dev-ops” teams.

Does any of the above surprise you?

If so, maybe it would be useful and helpful to take a closer look at the Kanban Method from a different perspective.

Kanban Leaders Retreat (KLRUS) 

In November 2012 I attended the Kanban Leaders Retreat (KLRUS) in San Diego. Over two days there I had an opportunity to take part in a number of break out sessions with several other leading coaches, trainers, and practitioners of the Kanban Method. In one of the sessions we focused on identifying some of the “surprising” myths and misconceptions we were hearing about the Kanban Method while coaching, training, and working with others. As summarized by some participating, “there really is a lot of surprising ‘stuff’ out there!” In the context of this post I’ll limit myself to providing a taste of our discussion there at KLRUS. In particular, focusing for the moment on a misconception I hear often, the Kanban Method: It’s just Scrum with tweaks.

If you’re just beginning to learn for yourself about the Kanban Method, I hope this post provides a useful foundational perspective to keep in mind as you continue learning, researching, and reading articles, posts, etc. For others more familiar with the Kanban Method already, I hope it provides a little insight into the misconceptions you’re likely to run into, if you haven’t already run into this one, and how some in the community are discussing them in ways we feel will help others see the Kanban Method from a more useful and different perspective. (continue reading…)

“Queues lie at the root of a large number of product development problems. They increase variability, risk, and cycle time. They decrease efficiency, quality, and motivation.”

“Large queues form when processes with variability are operated at high levels of capacity utilization. In reality, the misguided pursuit of efficiency creates enormous costs in the unmeasured invisible portion of the product development process, its queues.”

“Since high capacity utilization simultaneously raises efficiency and increases the cost of delay, we need to look at the combined impact of these two factors.”

“We have already pointed out that companies do not manage product development queues. What do they manage? Timelines...In contrast, when we emphasize flow, we focus on queues rather than timelines. Queues are a far better control variable than cycle time because, as you shall see, queues are leading indicators of future cycle-time problems. By controlling queue size, we automatically achieve control over timelines.”

- Don Reinertsen, 2009 – The Principle of Product Development Flow: Second Generation Lean Product Development

If you’re new to or rusty on CFDs, it would be helpful to review “Basics of Reading Cumulative Flow Diagrams” first. This earlier post covers basic definitions and the mechanics of reading WIP (work-in-progress), lead-time, and an average completion rate (throughput) from a CFD. It also includes links to external sources, one showing a basic example of how to create a CFD using MS-Excel, and another providing a quick overview of their use in the kanban method context. From this foundation I’d like to shift here toward a visual analysis perspective, exploring a few contexts where a bottleneck in our workflow is more or less present and see how it might appear on a CFD.

To be clear, I don’t think CFDs are the only way or “a best way” for spotting a bottleneck in your workflow. If you’re adequately visualizing your workflow on a board and diligently measuring and managing work items as they flow through your process, you’re well on the way to being able to identify where any bottleneck might be occurring. (Note: see my Kanban Board Design Primer under Resources/Nuggets here). That said, don’t under-estimate the value of using the CFD as well for learning about what happened, is happening, or will happen in your workflow. It can be a very effective tool for creating an easily accessible visual historical record and a trending perspective of a workflow in your context.

What is a Bottleneck?

Let us get a shared understanding of the term “bottleneck” by first looking at these selected Wikipedia definitions:

• Metaphorically a bottleneck is a section of a route with a carrying capacity substantially below that characterizing other sections of the same route. This is often a narrow part of a road, perhaps also with a smaller number of lanes, or a reduction of the number of tracks of a railway line.
• In engineering, a bottleneck is a phenomenon by which the performance or capacity of an entire system is severely limited by a single component.
• A bottleneck in project management is one process in a chain of processes, such that its limited capacity reduces the capacity of the whole chain.

As we continue our discussion, a key point from these definitions to keep in mind is the “singular” characteristic. Additionally, I’ll infer a “stationary” characteristic as well for the bottleneck throughout the time reflected by the example CFDs that follow. (continue reading…)

“Here’s the bottom line: the number one driver for shipping products quicker is by focusing on the important ones and killing the unimportant ones.”

“You might be thinking: ‘True, but couldn’t we also increase the average completion rate’? You’re right, but the impact of doing that is much lower than reducing the TIP (things-in-process) — that is, influencing the average completion rate is rather difficult and is often a function of available resources, scope creep, market demands and changes, etc.”

- Pete Abilla, Nov 2006, Little’s Law for Product Development

A few weeks back Arne Roock (see his posts here), a fellow kanban/lean-agile practitioner, pinged me with a question related to Little’s Law and utilization. Paraphrasing, essentially it was “Queuing theory states that the speed of networks decreases dramatically (non-linearly) as utilization increases more than 80%. But according to Little‘s Law (given a stable system), Lead Time increases linearly if we increase WIP (which increases utilization). Why doesn’t Little’s Law show lead time going up exponentially from a certain point on (ex. past 80% utilization)?” This resulted in exchanging a couple emails discussing the use of Little’s Law, and why and how in the software development context an increase in work-in-progress could result in a non-linear increase in lead time. This post captures and reflects some of the thoughts we shared. My assumption is you’ve wondered too about similar questions. If so, I hope you’ll find this post interesting and helpful. (continue reading…)

Written in direct collaboration with Richard Hensley (McKesson AVP).

“Knowledge is an unending adventure at the edge of Uncertainty.” - Jacob Bronowski, British mathematician, biologist, historian of science, poet, inventor, author of “The Ascent of Man”

“Maturity of mind is the capacity to endure Uncertainty.” – John Huston Finley, 1938 – New York Times editor-in-chief

“Many high performers would rather do the wrong thing well than do the right thing poorly.” – Thomas J. Delong & Sara DeLong, “Managing Yourself: The Paradox of Excellence”, June 2011 – Harvard Business Review

It’s common to see an organization (the people in them) focus on building systems with as many features as possible and targeting delivery by a specific due date. Yet, often the result is missing the date while also ignoring other important goals demanded by the businesses such as high levels of product quality, development productivity, planning reliability, employee satisfaction, and customer loyalty. Retrospectives, if done after such an occurrence, surface the dissatisfaction concerning missed dates, poor quality, technical debt, and more, still frequently this pattern repeats. Does this scenario sound familiar to you? If so, why do you think it is so? In a past or maybe your current organization, I’m guessing you’ve heard or thought, “We need our business and technology people on the same page.” How might “being on the same page” look in your organization? Does your current software development methodology, its principles, processes, and practices, contribute effectively to this objective? Is getting on the “same page” with objectives and goals enough? 

Over the last three years Richard Hensley, AVP Process at McKesson Health Solutions, has worked to address these challenges within the three business units of the division he works in at McKesson. I’ve been able to catch up with him on several occasions and discuss his efforts over these years. This post is a brief “fly-over” of his experience, capturing some of the key thoughts Richard developed over this time, and shared during our conversations.

No Silver Bullets Here!

Anyone reading a blog post on getting business and technology people on the same page probably knows there is no “silver bullet” to this challenge. Chances are good you’ve already been a part of such an effort, right? If so, you know it is not a simple task. Or even if you saw them start out on the same page in your organization, did issues appear that caused this working relationship to return to its earlier challenging state?

In short, Richard suggests, “you won’t find quick fixes for this issue” and his experience indicates it takes a serious effort from both sides. It also requires a continuous commitment over time because “getting everyone on the same page is a good start but not sufficient to sustain the business.” Yes, getting on the same page upfront, by itself, can be a positive thing as it helps everyone feel good, knowing where others are at and being in the know. If you’re familiar with the practice of daily stand-ups, you can draw a comparison, getting on the same page only is like a stand-up where team members simply provide “status” of their work. It is a good start, but alone it is ineffective for helping to solve real issues. In a similar fashion, getting on the same page with objectives and goals, if that is all you do, doesn’t help anyone address how things might be done more quickly or more effectively. It is a good start, but more is needed! (continue reading…)