What might prevent us from delivering software that matters, on-time?

My top 7 list and what to-do about it in the “Further Information” links that will posted in the next few weeks (Sep – Nov – 2016).

First, I like Douglas W. Hubbard (How To Measure Anything) definition of risk –
“A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome.”

#1 Risk of delivering little or no value to the customer or organization.
Product Management typically owns the product-market fit risk.

Very disappointing to spend time and energy to deliver a feature that is not used or cannot be supported by the stakeholders.  All team members should be asking challenging questions around what features are really important and  how do we know that.

Key questions are:

  1. Is there a business (or funding) model that makes sense to the organization?
  2. Will the end-user find the feature valuable?

Further information about risk #1

#2  Risk of missing the delivery schedule because of poor predictions.
Project Managers / Scrum Masters / Delivery Managers typically own the schedule risk.

Schedule outcomes are best predicted from recent past performances; stick with predicting the likely outcome of the next sprint.  And worry about those features that cross over the 50% cycle time mark.  They are the candidates for being really late (see #5 below).

Further Information about risk #2

#3  Risk of unplanned work disrupting the work process and schedule.

Product Manager and the development team typically wrestle with the high-priority request disrupting the current work plan.

Scrum tries to prevent this by the scope-of-work agreement for a sprint.
Kanban has work-in-process (WIP) limits to help prevent this.

Essentially, when this happens the new work “cuts” in the queue and rarely will a team have enough capacity to absorb the new work without delaying at least one work-in-process item.  Most teams will not have enough “slack” in-place to deal with this, so some work item(s) stops temporarily, while the high priority item is serviced.

Kanban may also have a high-priority swim lane that really only acknowledges this situation comes up often, unless there is actually excess capacity in-place to service the request.

At the very least, make the high priority work requests visible and the affect it has on the work plan.

Further Information about risk #3

#4  Risk of poor quality in the delivery.
We all own product quality.

Quality is the silent lever when we focus too much on the schedule delivery.  Typically, scope is the only visible leverage the team has to negotiate towards a release schedule. Budget and schedule are almost always a given by the organization.  So if scope cannot be reduced and the schedule remains in-place, quality can suffer – either explicitly or implicitly.

Further information about risk #4

#5  Risk of work item becoming an outlier … way off!
Project Managers / Scrum Masters / Delivery Managers typically own the schedule risk.

There is another schedule risk we touched upon in #2 above:  in software development, a few work items can be significantly delayed … way off.

Something is delaying a work-item and there is a chance for a big delay.  It probably has some sort of dependency that the development team cannot influence and thus is sitting in a wait state (on-hold).  The delivery of this work item can become atypical.  It skews to the right on the time line, several weeks past the delivery history mid-point.

These are the work items that development team should spend time identifying, so we can call attention to it as-soon-as-possible — coming up with alternate plans or mitigation.

As stated in #2 above, once a work item crosses the 50% cycle time marker from the past delivery data, then this work item becomes more at-risk to become a schedule outlier.  Treat WIP crossing the 50% cycle time as a trigger for team and program conversations.

#6  Risk of the team not working well together.
Universal risk to all roles.

People create and deliver products.  Good working relationships are essential.  In context to THIS post, make sure the team is not overburden with work and a tight deadline. Demand and capacity must match.

Scrum is important because of the idea the team can accept a work item into sprint, or not, depending upon the team’s capacity.

Kanban is important of the idea of WIP limits.

Good team dynamics go way beyond the overburdening of a team; however, overburdening leads to technical debt and a feeling of “whatever”.

Further information about risk #6

#7  Risk of end-users not using or liking the product.
User experience matters – even when you have everything else right.

This is a different that #1 above.  Here we have confidence and data that the product is well supported by the organization and does provide value to the customer.  It is “just” the UI is bad.  The user maybe confused and cannot find the feature.  Or the user has a difficult time with the feature and will avoid using it.

Further information about risk #7

More …
Of course, this risk list is not complete.  We can think of security vulnerabilities as another risk, for example.  Use this list a spring board for your own risk lists, depending on your projects and purposes.

Ordering of risks
This list of risks is not in priority order.  However, #1 (product-market fit), for me, is most often the top priority.  But I can see a strong argument for #6 (Teams not working well together) too, especially in some situations.

Ash Maurya states in his book “Mastering the Key Metrics for Startup Growth – Scaling Lean” that “Incorrect prioritization of risks is one of the top contributors to waste” (p. 13), so prioritizing your risks is very important.


I will be creating “Further information” posts for each of these risks in the upcoming weeks

  1. Further Information on risk #1
    Risk of delivering little or no value to the customer or organization
  2. Further Information on risk #2
    Risk of missing the delivery schedule because of poor predictions
  3. Further Information about risk #3
    Risk of unplanned work disrupting the work process and schedule
  4. Further information about risk #4
    Risk of poor quality in the delivery
  5. – next week
  6. Further information on risk #6
    Risk of the team not working well together
  7. Further Information on #7
    Risk of end-users not using or liking the product