Tag: Pull Scheduling

Role-based Guidance: How Might the Kanban Method Influence Your Role?

“So much of what we call management consists in making it difficult for people to work.” — Peter Drucker

“As a job seeker, remember this: You only lack experience if they want it done the same old way.” — Robert Brault

“Deciding what not to do is as important as deciding what to do.” — Steve Jobs

“Out of clutter, find simplicity.” — Albert Einstein

 KLRUS14 – Monterey

In January leading practitioners and coaches of the Kanban Method gathered at the Kanban Leadership Retreat. While preparing our “just-in-time” agenda at the start, a topic suggested for discussion was a variation on a question we had all heard often, “How does ‘kanban’ impact my role: as a Project Manager, or as a Business Analyst, or as Product Manager, or as a Program Manager?” It was definitely interesting to hear responses from others to this question, and for me it was one of the more useful sessions.

First Things First

Confused-Cartoon-Face1Since the Kanban Method is not a specific workflow methodology or process, and therefore is not something that replaces your current workflow process, but rather a tool that can be used to improve any workflow process, it doesn’t prescribe specific roles. It isn’t that kind of tool.

It’s also helpful to consider that improving your current workflow, even in significant ways, won’t necessarily require creating and defining “new roles and practices.” Still, it is important to recognize using it as a tool to improve your current workflow process should clearly result in some noteworthy changes. Right?

A good place to start is to understand upfront that a core component of the “Kanban Method” is using a kanban system, or even more fundamentally using a “pull based system”, to help address obstacles to creating and maintaining a predictable workflow and improving performance over time. That is, if you’re not familiar with “pull systems”, I’d suggest to anyone using the Kanban Method to first focus on understanding the fundamental changes to pull thinking. Allow this new thinking in turn to influence the ideas and experiments (changes) that emerge for improving the design and operations of your workflow process.1 Then, if necessary and only as needed, consider any benefits that might exist from adding (or removing) roles and associated practices. (continue reading…)

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

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

  • Applying lean-agile principles, processes, and practices to deliver quality software and services predictably and sooner.


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

    How do you measure your ability to deliver predictably or measure if your improvements are helping?

    Where are you with understanding
    and using Flow-based (kanban
    & pull scheduling) Metrics

    If interested in learning about custom tutorials or embedded coaching on appying lean-agile principles, kanban/pull procesess, flow-based metrics, and probility-based risk management in your context please contact Frank Vega.

  • Engagements & Events

    PraxisFlow - Newark metro-area, NJ; Jun 2016 - Dec 2016. Assisting PraxisFlow with facilitating lean-agile embedded coaching efforts being provided to their Fortune 500 client with 125K+ employees and $70+ billion in revenue.

    Global, National, and Local Events:
    Probability Management Annual Conference - San Jose, CA.; March 7 - 8, 2017. Excited to be attending this conference for a second time. I hope to see you there!

    Agile Denver Kanban SIG - Denver metro, CO; Mar 9, 2017. I co-lead this special interest group w/ Wade Scherer. Click link above for more info about the SIG.

    Lean Kanban North America Conference 2017 - Washington, D.C.; May 8 - 10, 2017. I've attended this conference since the first one in Miami, 2009, and excited to be attending again. This year looking forward to meeting Mihalyi Csikszentmihalyi and hearing his thoughts on "flow." I hope to see you there!

    Kanban Leadership Retreat - North America 2017 - Washington, D.C.; May 10 - 12, 2017. I've attended every Kanban Leadership Retreat in North America and excited to be attending again in 2017. I hope to see you there!

    Mile High Agile 2017 - Denver, CO; May 22 - 23, 2017. As a former Agile Denver board member, and long time volunteer, I'm again happy to be helping promote this conference. This will be our 7th and this year it is going from one to two days. I hope to see you there!

    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.

  • Subscribe to Blog via Email

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

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