Select Page

A Few Basic Ways to Visualize Story Lead Time Predictability

Note: My colleague Dan Vacanti has also captured and expanded in greater detail on much of the topics touched on in this post, in his book titled “ActionableAgile.”

“The ability to take data – to be able to understand it, to process it, to extract value from it, to visualize it, to communicate it, it’s going to be a hugely important skill in the next decades, not only at the professional level but even at the educational level for elementary school kids, for high school kids, for college kids. Now we really do have essentially free and ubiquitous data. So the complimentary scarce factor is the ability to understand that data and extract value from it.”

“I think statisticians are part of it, but it’s just a part. You also want to be able to visualize the data, communicate the data, and utilize it effectively. But I do think those skills – of being able to access, understand, and communicate the insights you get from data analysis – are going to be extremely important. Managers need to be able to access and understand the data themselves.

 – Hal Varian, Google’s Chief Economist, Jan 2009 – The McKinsey Quarterly

My previous post discussed how some of my earlier teams used T-shirt sizes for story level work items in their software development planning processes. But T-shirt sizes were only a part of what helped us get effectively predictable. The emphasis on just-in-time (JIT) story creation and story analysis, along with just-enough story and portfolio level backlogs (limiting work-in-progress or WIP), were also significant contributing factors. Two other key factors were de-emphasizing upfront estimating of level-of-effort and duration, and instead placing a greater emphasis on lightweight tracking of real (lead and cycle) times to complete and deliver story level work items. (See my earlier posts here and here for a bit more context and background on push vs. pull scheduling systems.)

I also discussed how some basic analysis of this lead time data and T-Shirt sizing helped us develop an internal service level of agreement (SLA) for completing story level work items. But this information also guided and shaped the policies we developed to influence the team’s interactions and specific responses (pulled from our toolbox) in a JIT manner as information unfolded about a story’s level of effort and duration. My observation is that all this contributed to us becoming predictable in a context where we never had been before using heavier upfront planning strategies. Based on my study of scheduling systems this combination reflected key pull scheduling characteristics, where the role of our software development workflow management changed from determining all operation activities upfront, to one focused much more on setting the rules for interactions (in turn influencing our work environment structures).

There’s lots more analysis (mathematical and statistical) you can do using the minimal and easily collected data that produced the Basic Story (Lead Time) Metrics table and T-shirt sizes from my earlier post and that will have to wait for another time. For this post I want to focus on visualizing the information in this simple table to see if we might extract a bit more value from the modest analysis investment already expended.

I’ll also build on this initial visualization, using a bit more (quick) low hanging fruit type analysis of the full raw data set represented by the earlier spreadsheet snippet, to produce a basic temporal (time) perspective of story lead times. Can adding a basic temporal perspective  provide a number of other useful insights into understanding the nature of our workflow’s story level work item lead times? (Both the earlier table and spreadsheet snippet are included here; click images to enlarge). To this basic temporal perspective, with a bit more new analysis on the existing raw data spreadsheet, I’ll then add new information extracted to give a work item type perspective as well, and then overlay the T-shirt size information to this mix.

Finally, again with just a bit more analysis on the existing raw data, I’ll visualize two other separate temporal perspectives using both  percentages and frequency counts. Afterwards, let me know what you think. Do one or two of these other ways of visualizing the information in the earlier table and spreadsheet snippets help you and others access, understand, and communicate insights that leads to a more effective predictable workflow in your software development context? (more…)

T-shirt Sizing: Predictability with Pull Scheduling

Note: Post updated on 3/29/12 to correct titles on the three T-shirt size tables and to lighten the blue shade on the Medium T-shirt size row in these tables to make it easier to read. 

“We do estimation very badly in the software field. Most of our estimates are more like wishes than realistic targets.”
– Robert L. Glass, Nov 2002 – Facts and Fallacies of Software Engineering

“The best way to get a project done faster is to start sooner.”
– Jim Highsmith

constellationsav_t-shirt_blank_modIn earlier posts (here, here, and here), I commented briefly about moving away from upfront estimating and toward tracking and measuring “actual” metrics to complete work items, and using this data as a foundation for predictable scheduling and forecasting. Am I suggesting your software development team can’t achieve effective “predictable” scheduling using upfront estimating? No. But first, to be clear, I’m delineating upfront estimating activities from upfront analysis activities. The former is associated with predicting the number of calendar days (duration) to complete a work item and the actual hours (effort) expended on a work item. The latter is associated more with partitioning larger work items (epic, feature) into smaller ones (story, task) and determining relationships and dependencies between them to assess complexity or risk.1 The significance for decoupling these becomes apparent shortly. So, in your context, if teams haven’t achieved effective predictable scheduling using upfront estimating, I am suggesting it might be beneficial to approach project planning from what is likely a different perspective. I’m also suggesting that over time this different perspective may reduce planning effort.

As an example, I’ll focus on one of the “actual” measurements my past teams collected, in this case Lead times for “story” work items, and discuss how we used this data to derive a very predictable range of “T-shirt” sizes. This range helped us predictably manage story level work items thru our workflow, and enabled us to identify issues earlier as they emerged for those needing alternative (special) processing or management. Before moving to how and what we did and the benefits obtained, I’ll briefly provide context for why we shifted perspective, which may reveal some insights for benefit in your environment.

Earlier Times in a Nutshell

Our development teams were well into implementing agile processes, and demonstrated visible improvements in several areas related to technical practices and our ability to deliver more frequently. However, we continually missed “commitments” for the number of stories to be completed in a sprint whether it was two weeks or 30 days. We were unsuccessful at effectively predicting duration or effort for completing stories using upfront estimating techniques that we had tried including variations of planning poker with ideal days, points, hours, Fibonacci sequences, etc. I won’t go into consequences of these estimating efforts here, but will highlight a key observation made during efforts to mitigate these costs that led to shifting our planning perspective.

As the mid-sprint approached and we saw our commitment at risk, at one point a team decided to assertively reduce (“de-commit”) work items (stories in this case) in their “Doing” state, moving them back to ToDo or to the story backlog. Again and again, when we did this in a sprint, stories remaining in the Doing state would get completed quickly, and then we’d “whip back” the other way and re-pull stories before the sprint end. After of a few of these “herky-jerky” sprints, we did something different and shifted to a “pull-scheduling” perspective.

Push vs Pull Scheduling?

This image is my summary derived from sources contrasting push and pull scheduling systems.2 Push scheduling starts with obtaining commitments to upfront estimates of duration and effort, then develops a schedule based on these estimates and seeks predictable outcomes by attempting to adhere to the developed schedule. Pull scheduling starts with obtaining predictability of upfront (measured) capabilities and known constraints, then develops a schedule based on these capabilities and constraints and seeks to achieve commitments to the developed schedule. Is this distinction a bit too intangible for you? (more…)

The Predictability Paradox and Obliquity: Achieve Predictable Outcomes Indirectly

“The paradox is that trying too hard to create predictability creates the opposite effect.”
– Mary Poppendieck, Aug 2003 – Lean Development and the Predictability Paradox

“If you want to go in one direction, the best route may involve going in the other. Paradoxical as it sounds, goals are more likely to be achieved when pursued indirectly.”
– John Kay, Jan 2004 – Obliquity, January (article)

“Rationality is not defined by good processes, irrationality lies in persisting with methods and actions that plainly do not work – including the methods and actions that commonly masquerade as rationality.”
– Johh Kay, Mar 2010 – Think oblique: How our goals are best reached indirectly

If you’ve worked in the software development field for any length of time, I’m sure you’ve been asked, “When will the project be finished?” I’m also sure you’ve found this question challenging to answer more often than not. Why is this? Estimating, forecasting, projecting, call it what you will, is not easy to do well, or even close to effective, especially as the project increases in size, complexity, or both. In a single post, I’m definitely not diving deeply into how one might estimate, forecast, or project how long a software development project might take to complete. However, keeping in mind the “estimating challenges” we’ve encountered in software development provides a real world context for discussing what I think are a couple of related and intriguing concepts.

The Predictability Paradox

In 2003, Mary Poppendieck published a paper titled “Lean Development and the Predictability Paradox.” The lean principles found in this paper appear in a refined and expanded form in Mary and Tom Poppendieck’s book “Lean Software Development: An Agile Toolkit” (2003). However, unless I missed it, the Predictability Paradox, neither as a term or concept, appears explicitly in this book. But, the concept definitely resurfaced in their following book, “Implementing Lean Software Development: From Concept to Cash” (2006), although relabeled as a chapter sub-heading “Myth: Predictions Create Predictability.”

So, what exactly is the Predictability Paradox? (more…)

Unknown Unknowns: Using Types of Uncertainty to Guide How You Manage Your Project

“Don’t manage the unknown and unpredictable the same way you manage the known and predictable.”
– Doug DeCarlo, Oct 2004 – eXtreme Project Management

“Managers must be flexible enough to adopt the right approaches at the right time…to find the balance between planning and learning.”
– Arnoud De Meyer, Christopher H. Loch, and Michael T. Pich – Managing Project Uncertainty: From Variation to Chaos

Reflecting on the last ten years of my own experience working on projects, early on, I saw mostly “traditional project management.” That is, project management that places greater emphasis on planning upfront, and as a whole, a greater proportion of the total project planning is done very early in the project, and seeks to provide predictability of activities over longer planning horizons. Other terms I’ve heard for this project management style are “predictive” or “sequential (gateway) delivery.” In more recent years, however, my experience has been to see “iterative and incremental” approaches. Again, that is, project management that places less emphasis on planning upfront, and as a whole, a greater proportion of the total project planning is done in small amounts iteratively across the project, and seeks to provide predictability of activities only over shorter planning horizons. Other terms I’ve heard for this project management style are “emergent” and “incremental delivery.”

While this is a minimal level of distinction, for our purposes it will be sufficient. This won’t be a post on “good vs. evil” styles of project management. In fact, I’m advising, that might be a “limiting” perspective. Rather, the “focus” is to view projects from a perspective of uncertainty (as a model) to gain insights into these two project management styles that may help us more effectively manage our projects.

 Are All Projects the Same?

In your experience, how often have you seen projects managed differently from one another? Is there “evidence” to suggest, based on how you manage or see projects managed, that all projects are the same? (more…)

It’s Slack! Who Can’t See That?

Note: In his book “Actionable Agile Metrics for Predictability”, my colleague Dan Vacanti expands on my FedEx example while discussing further the notion and benefits of “slack” in the software development context. You’ll find this discussion in Ch. 13 Pull Policies.

“The beauty of using a flow system and a visual control is that we can measure cycle time and we can observe context…

The trappings of false certainty we gave ourselves in previous methodologies are being replaced with the comfort of graspable variation in kanban…

We now see knowledge work for what it is – a chaotic system that is fully manageable and understandable by its outputs and contexts, but very much unknowable by its actions and specifics.”

– Jim Benson, Sep 2011

The title of this post contains an answer and a question. However, it’s a “question” that prompted the answer part of this title, and my recollection of how both came to me originally, that I’m interested in sharing in this post and hope you find interesting if not amusing. As for providing an “answer” to the question part of this post’s title, that I’ll leave entirely to you.

Who Mentioned Variability?

This summer I had an opportunity to help out with a training class introducing the kanban method to a few members from several teams that all worked in software development and operations support context. On the second day of this training, we came to a section titled “Understanding Variability.” As the class began discussing why this might be important, I couldn’t help but flashback to a time when I heard my wife shout “It’s Slack! Who can’t see that?”, as she was watching a TV program in our family room. I’m sure at the moment of my flashback, more than a few in the training classroom wondered how I could be enjoying the discussion so much, while I sat there listening with a big smile on my face, chuckling a bit as if I was somewhere else hearing a comic telling his latest and greatest jokes. The truth was, I was somewhere else for the moment.

The year 2009 was coming to an end, and it was a few days before New Year’s Eve. I was at home in the loft sitting at my computer reading or writing something, when I heard my wife shout from below “It’s slack! Who can’t see that?” as she walked out of the family room. The tone in her voice hinted it was the “Who can’t see that?” part that she was most excited and proud to share right at that instant. However, I was much more interested in knowing the yet unknown question that prompted her to excitedly shout “It’s slack!” It was obvious too, she had more to share with me right then, something I’ll now share a bit about with you. (more…)