Tag: Planning

Business and Technology Peacefully Co-creating

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

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” which you can learn more about here.

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

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

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? (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:
    Agile Denver Kanban SIG - Denver metro, CO; Apr 13, 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. 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