Tag: Data Analysis

Little’s Law: Isn’t It a Linear Relationship?

“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…)


A Few Basic Ways to Visualize Story Lead Time Predictability

“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? (continue reading…)


  • Applying lean-agile principles and
    practices to deliver quality software faster.

    LKU-KCP-badge

    You have technical skills, but
    do you have the odds in your favor?

    What key performance drivers in your context provide Predictability or Meaningful Improvement?

    Where are you with Flow-based
    (Kanban/Pull Scheduling) Metrics
    ?

  • Upcoming Events

    Global, National, and Local Events:
    Agile Denver Kanban SIG - Denver, CO; Nov 13, 2014, from 6:00-8:00 pm. Location for this meetup will be at Square Two Financial. I co-lead this special interest group w/ Dan Wyks. Click link above for more info about this SIG and our next mtg.

    Engagements and Tutorials:
    Kanban Metrics Coaching Philidelphia, PA; Apr-Oct, 2014. In conjunction with Corporate Kanban, providing embedded coaching to private client on applying kanban (flow) metrics along with the Kanban Method to improve workflow delivery and predictability.

    Kanban Metrics Data Collection Support Philidelphia, PA; Jun-Oct, 2014. In conjunction with Corporate Kanban, providing private client with custom application/programming support to automate extraction of kanban (flow) metrics from VersionOne, and feeding into custom analysis and display tools.

    Kanban Coaching Sarasota, FL; Aug-Nov, 2014. In conjunction with Corporate Kanban, providing embedding coaching to private client on introducing and applying kanban (flow) principles and practices, along with initial flow metrics improve workflow delivery and predictability

    If interested in custom tutorials on Kanban Metrics or on appying the Kanban Method in your context, or embedded coaching, please contact Frank Vega.

    Past Events:
    Click here for past presentations and major events attended. If interested in similar presentations at your company, user group, or conference, please contact Frank Vega.

  • Enter your email address to subscribe to receive notifications of new posts by email.

  • Copyright © 2011 - 2014 VISS, Inc. All Rights Reserved.
    iDream theme by Templates Next | Modifications by Frank Vega | Powered by WordPress