Risk of poor QUALITY in the delivery

Risk #4 is the about quality from the project management perspective — going a little deeper from the “Seven Risks in Software Development”.

Kent Beck (with Cynthia Andres) in “Extreme Programming Explained (Embrace Change)” [2nd edition] states

“This model (managing projects using speed, quality, and price) doesn’t work well in practice.  Time and costs are generally set outside by the project.  That leaves quality as the only variable you can manipulate.  Lowering the quality of your work doesn’t eliminate work, it just shifts it later so delays are not clearly your responsibility  … The variable left out of this model is scope.”  (page 92)

From this model Beck describes and also thinking about the Project Management iron-triangle of scope, schedule, and budget, there are 4 levers:

  1. Scope
  2. Schedule
  3. Budget
  4. Quality (can be a silent lever)

And as Beck stated above – two of those levers (schedule and budget) are often frozen or given to the Project Manager as non-negotiable.

So beware!   When Scope, Schedule, and Budget are all frozen and there is not enough time to complete all the scope (common), then quality will suffer and you will probably find out later, after the software releases.  Actually, to be more accurate, your customers will discover and tell you about the product defect(s) after the release.

Beck also states “Defects destroy the trust …” (page 97)

  1. Trust of the customer and stakeholders (obvious)
  2. Trust within the team (not as obvious)
    1. Manager’s trust of true project progress
    2. Team members trusting each other

Beck (one more time):  “Here is the dilemma in software development:  (released) defects are expensive, but eliminating (preventing) defects is also expensive” (page 97)

What can we do about this?  Measure quality and then start actions designed to prevent defects like …

  1. Frequent testing (e.g., smaller testing batches, automated tests)
  2. Pair programming (to reduce both design and execution errors)
  3. TDD – Test-Driven Development (think about the test conditions before writing code.  A powerful technique!)

About measurements:  listen to the great advise from Troy Magennis on the Agile for Humans podcast [hosted by Ryan Ripely] .  A balanced metrics approach for software development.  Measuring not only quality, but …

  1. Throughput
  2. Predictability
  3. Responsiveness
  4. Quality

Magennis advises us to use a set of metrics that will offset each other – “anticorrelated measurements”.

Example:  if we focus a team on improving throughput, and only measure throughput, what happens to quality (or predictability for that matter)?

The four take aways are

  1. Quality can be a silent lever, leading to escaped defects (i.e., post-release defects).
  2. Poor quality erodes trust.
  3. Measure quality to drive improvements.
  4. Use a balance metrics approach, so one metric does not dominate the product or team, which can lead to gaming of the system or lead to the myopic pursuit of a single metric at the expense of the bigger organization.



Risk of the team not working well together

All organizations thrive when teams work well, within and together.  No matter what the dominant product development process is  — agile, lean, waterfall…

More on #6  Risk of the team not working well together from a previous blog entry “Seven Risks in Software Development”.

I discussed risk #6 in terms of NOT overburdening the team with work – demand and capacity must match.  Muri (unreasonableness)  is one of the three concepts of waste in lean manufacturing – Muda, Mura,and Muri.

But creating great team dynamics is much more than controlling Muri!  And one can go in many directions learning to develop and fostering highly productive teams, with great working relationships.

One model of understanding and developing great team dynamics comes from Patrick Lencioni’s “The Five Dysfunctions of a Team“.

A call-out to Tom Caglay’s  “re-read of The Five Dysfunctions of a Team“, in which I also participate with comments to Tom’s weekly, re-read blog entries.

Lencioni’s case for Teamwork – “Teamwork remains the one sustainable competitive advantage that has been largely untapped”.  Not because organizations do not think and discuss the idea of creating teamwork, but because organizations will focus more on business results, than creating and growing great teams.

Lencioni’s model (from bottom-to-top) is …

  1. Dysfunction #1 – absence of trust
    Can team members be vulnerable with each other, in order to be open with each other?
  2. Dysfunction #2 – fear of conflict
    Can team members argue, challenge each other in the spirit of finding the best solution AND do so in a way that does not harm relationships?
  3. Dysfunction #3 – lack of commitment
    Can team members buy into the same plan and the decisions made?
  4. Dysfunction #4 – avoidance of accountability
    Can team members not only commit to the plan and decisions, but also hold other team members (peers) accountable to the same?
  5. Dysfunction #5 – inattention to results
    Can team members put their egos, agendas, and individual needs aside in favor of the team.  Example:  for a department manager, what will be considered team #1 – the leadership team or their department?


The end goal, from David Rock’s article “Managing with the Brian in Mind”

“But when leaders make people feel good about themselves, clearly communicate their expectations, give employees latitude to make (some) decisions, support people’s efforts to build good relationships, and treat the whole organization fairly, it prompts a reward response.  Others in the organization become more effective, more open to ideas, and more creative.”

Risk of unplanned work disrupting the work process and schedule

What strategies can we use to cope with new work entering the system?

#3 Risk of unplanned work disrupting the work process and schedule
going deeper from a previous blog entry “Seven Risks in Software Development”.

To be more clear about what is meant by unplanned work:  they are those
high-priority, new work items that the team feels cannot be refused or be delayed.

Example:  you manager requests something the an executive vice-president wants completed in 2-days.

Most common scenario:  the work-item is taken on as requested.  Other “in-flight” work-items are put aside for a while and one of three common outcomes occurs:

  1. Team (or some team members) works overtime to make all work-items happen on-time.
  2. All or some of the other work-items are delayed.
  3. The other work-items are delivered as scheduled, but with poorer quality.

There are 4 strategies to help cope with unplanned, high-priority work.

  1. Adhering to prior work-in-process (WIP) limit agreements.
    1. Kanban – queued to be pulled when capacity allows.
    2. Scrum – deferred until the next sprint.The delivery team is saying “no” to taking on the requested work immediately because of prior agreements about how work is accepted.  Sometimes these WIP limit agreements work and sometimes they break down because of pressure.  So just like antivirus software, good to have in-place because it does work sometimes.
  2. Slack – the emergency responder model – have excess team capacity to deal with these unplanned requests.Example 1:  production support rotates week-to-week among team members and that non-available resource is not considered when planning for team capacity.

    Example 2:  team lead does not usually start any planned work assignments.  And then when something comes in, the team lead takes it on directly or stands-in for another team member who takes-on the new high-priority, work-item.

    The person in the slack resource role, must be able to drop current work to deal with high-priority, work-items and do so in a way that does not affect the team’s performance for committed work.

  3. Visualize the effect of high-priority, unplanned work has on the team’s cycle time (see Risk of missing the delivery schedule because of poor predictions for more information on cycle time)Here we are saying the above two strategies either do not work most of the time or cannot be implemented.  Example:  because of budget, there is no possibility of placing slack in the team.

    Visualizations methods from Daniel S. Vacanti’s book “Actionable Agile Metrics for Predictability” include:

    1. Cumulative Flow Diagrams (CFDs)
    2. Cycle Time Scatterplots
    3. Cycle Time Histograms
    4. The bad effect that an increased cycle time has on the 85 percentile when running Monte Carlo simulations from the team’s delivery data.Note:  we assume the performance of the 85 percentile is what can be communicated back to the business for service level agreements (SLA) or service-level-objectives (SLOs).
  4. Class of Service for high-priority workIn Kanban, you can design your workflow board to include a special swim-lane for high-priority items.  Normally, this swim-lane will have a WIP limit of 1.

    This works, when there is capacity to service the swim-lane.  Otherwise, this special, swim-lane will disrupt the work-items already in-play.

    However, there are ways for the business stakeholders and delivery teams to meet in the middle by setting up a very limited, high-priority, swim-lane or “silver bullet” than can only be used by the business stakeholder(s) (e.g., product owner) once a quarter.

Question:  what would any group of managers / product owners / product managers do when there is a special, high-priority, swim-lane with a WIP limit of 1?
Answer:  keep it filled.  That special queue is a GREAT way to get my “special” work requests completed fast!

Daniel S. Vacanti has a wonderful write-up in his book – Chapter 13 – Pull Policies – about the effect that “special queues” can have in small US airports and then the negative effect special queues and the resulting pull-in-new-work practices can have on both predictability and cycle times.

Risk of delivering little or no value to the customer or organization

Delivering little or no value to the customer or organization is one of the most frustrating of the seven risks I write about.  It was the risk that first came to mind.  Much has been written about and is what the Lean Startup movement is all about.

Jim Highsmith “Given that studies show over 50% of software functionality is rarely or never used, the idea that focusing on scope and requirements yields value is mistaken.” [from the book “Agile Project Management” (p. 18)]

Steve Blank “Webvan. Groceries on demand: the killer app of the internet. The company spent money like a drunken sailor. Even in the Internet Bubble costs and infrastructure grew faster than the customer base. Loss: $800 million.” [from the book “The Four Steps to the Epiphany“, chapter 1 goes into detail about the Webvan case-study]

Webvan’s lesson learned:  validate assumptions (e.g., customer demand) before scaling a business plan (a.k.a., Lean Startup thinking).

What can we do to avoid building out an useless feature?  Validate assumptions (e.g., customer acceptance) before building out any new, large feature.

But this is hard for us because (1) we are often VERY sure of our great ideas and (2) time-to-market pressure.  So we move forward anyway because we rationalize our decision for immediate action:

  1. Why waste time on customer validations?
  2. This idea is a sure thing!

Of course, we will not validate every new feature / user story we choose to build out. However, we need to be doing a better job of vetting the larger items in the product backlog for customer and stakeholder success.

Marty Cagan (product manager and blogger) writes about Dual-Track Scrum and using both a Discovery sprint and a Delivery sprint.  Working on both the current release and figuring out if upcoming items in the backlog are worth building out.

For new products or prized new features, use Dan Olsen‘s Product-Market fit six-step methodology for innovation and discovery, as detailed in his book “The Lean Product Playbook“…

  1. Determine your target customers
  2. Identify underserved customer needs
  3. Define your value proposition
  4. Specify your minimum viable product (MVP) feature set
  5. Create your MVP prototype
  6. Test your MVP with customers

Dan describes these six steps as “The Lean Product Process guides you through the formulation and testing of your hypotheses” (p. 277).

If #6 checks-out, you are ready to build out the product or new feature.  Going through these six steps transforms your  idea and will help create successful products through a structured learning methodology.  So by the time you are ready to build out for delivery, the risk of delivering little or no value to the customer or organization has essentially been removed.

“It is not enough to do your best; you must know what to do, and then do your best.”
W. Edwards Deming

Risk of missing the delivery schedule because of poor predictions

Core to the Project Manager, Scrum Master, Product Manager, team, and stakeholders is
#2  Risk of missing the delivery schedule because of poor predictions
from a previous blog entry “Seven Risks in Software Development”.

On LinkedIn, I state as an Agile Project Manager I do this …

Improve your agile process, create reliable and predictable deliveries.  I coach teams to use data and analytics that show how the workflow is actually performing.  Which start conversations and inform actions resulting in measurable improvements.

A bold statement and not always easy to achieve.  What is behind this?

I have distilled Daniel S. Vacanti’s work “Actionable Agile Metrics for Predictability” into my value statement and practice.

Vacanti –
“Simply stated, flow is the movement and delivery of customer value through a process.”

The essence is to treat development as a process and be very clear on the start dates and end dates for all work items.  And then use simple analytics  and visualizations to see if you have a stable process.  For example, is the scrum process being used actually stable?

And what exactly is stable?  Vacanti answers this question very clearly by spelling out the
5 assumptions behind Little’s Law.  You can see a stable or unstable process by using the  analytics Vacanti recommends:  Cumulative Flow Diagrams, Cycle Time Scatter-plots, and Cycle Time Histograms.  Vacanti also warns, even if your process looks stable, it might not be stable.  You must also make sure that the process is not accumulating flow-debt.

Once we have that stable (or near stable) process, that is when we can use Monte Carlo simulations on past performance, to make those accurate and probabilistic schedule predictions.

Example:  we have a 85% chance that a user story accepted into a sprint will be completed in 20 days or less.  That might be the Service Level Objective the delivery team uses with the business stakeholders for delivery agreements.

In this example, the only estimation required is being confident that the user story taken into the sprint can be completed within the time frame of the sprint.  And we let past data and Monte Carlo simulations help us with lightweight planning and scheduling.

I have used this approach and it is great way to visualize the teams output and also start those improvement conversations.

As an Agile Project Manager, accurately stating the deliver schedule is often how the project’s performance is judged.

More from Vacanti’s book “Actionable Agile Metrics for Predictability”

Little’s Law, reframed for knowledge work, is Cycle Time = WIP / Throughput
Which tells us, for a stable processes, one lever we have is to reduce WIP to shorten Cycle Time and deliver value sooner to the customer.

Vacanti’s 5 assumptions for Little’s Law to hold, but in my words are …

  1. Work coming in = working leaving, on average.
  2. All work accepted into the process is started and eventually completes.
    Note:  we can have a tag for abandon work, when we know we must remove the work item because it will not be delivered, either because the work item “never will be delivered now” or “will not be delivered in the foreseeable future”.
  3. The amount of WIP is about the same, at the beginning and ending of the time interval being measured.
  4. Do not allow WIP to arbitrary age inside the process.  That is, work that is accepted into the process, does not stop very often.  It may stop because of an outside dependency.  It may stop because of a “self inflected process wound” by stopping work on an active item, to service a higher priority work item recently introduced.
  5. Must use consistent measurements for all three variables:  Cycle Time, WIP, and Throughput

Vacanti provides many great metaphors in his book.

  1. Airport arrivals and departures — what would happen to an airport if the aircraft arrival rate was constantly greater than the departure rate?
  2. Airport security lines and the effect of special queues (e.g., prescreened passengers) has on the average wait times for the regular queue in small airports where there is only one security agent attending all queues.  Good luck making your flight if you are in that “punter” queue.
  3. Is the process you are managing a Ponzi scheme?
    Yes it might be a Ponzi scheme, if resources are taken away from active work-items to service new work-items more often than not.  No wonder business stakeholders get frustrated with delivery teams, even though these stakeholders are often the primary source of new, high-priority work-items.



Re-read of The 5 Team Dysfunctions

Tom Cagley‘s re-read Saturday series continues with the book “The Five Dysfunctions of a Team – A Leadership Fable” by Patrick Lencioni.

Week 1 [beginning through Underachievement] – setting the stage for the story line.  Lencioni introduces the setting, main character (Kathryn), and the team.  And hints of a turbulent ride for Kathryn, the new CEO of the fictitious company DecisionTech.

Right upfront Lencioni tells why he wrote this book and why readers should pay attention.

“Teamwork remains the one sustainable competitive advantage that has been largely untapped.” (from the companion book, “Overcoming The Five Dysfunctions of a Team – A Field Guide”)

More often teams focus their attention on customer needs, release dates, budgets, technology, usage data, etc.  All of these are important, but without good working relationships among the team, much waste is produced and opportunities missed.

Extra:  for a similar message, different angle, see Simon D’Arcy Next Level Culture site.

Week 2 [Lighting the Fire through Going Deeper]  – “real work” is happening.  Martin (chief technologist) informs he will miss most of Kathryn’s off-site now.

Kathryn confronts the situation … “First of all, I have one priority at this point:  we need to get our act together as a team or we’re not going to be selling anything.”  Meaning, the sales meeting needs to be rescheduled.

Kathryn successfully defends this position to the people Martin enlists in his “end run” to avoid the off-site meeting.

Martin shows up at the off-site and Kathryn introduces the meeting theme, purpose, and the first team dysfunction – “Absence of trust”.

Kathryn uses a “personal histories” exercise to have the team open up to each other and start to build trust with each other.  Followed by reviewing the results from the Myers-Briggs Type Indicator (MBTI) for each person.  For the most part, the team knows everyone a little better and interactions start to improve.

Week 3 [comment on the “Drawing the Line” chapter]

The conversation Kathryn has with the Chairman of the Board, the person who hired Kathryn, took courage and confidence.  And without that conversation and obtaining the Chairman’s support, anything Kathryn tried to-do would fail because some of the team would learn there is a way around Kathryn.

Week 4 [two important questions when beginning to work with a team]

In the companion book “Overcoming The Five Dysfunctions of a Team – A Field Guide”, Lencioni presents two questions before he starts to go in-depth about the the five dysfunctions.  Remember (last week’s re-read) in “The Speech” chapter, Kathryn talks about the first dysfunction, the  “Absence of Trust”.

1) Are we really a team?
2) Are we ready for the heavy lifting?

skipping ahead the re-read blog for now

[Poolside through Attack] – the last team dysfunction is introduced – Inattention to Results (because of status and ego).  Lencioni introduced the 1st team dysfunction (absence of trust) and here jumps to the top, #5, and describes the 5th team dysfunction (Inattention to Results).

We see this in the off-site. One example is when Mikey defends herself and the marketing department.

Note:  the Week 5 re-read covers three Chapters:  Awareness, Ego, and Goals.  The below quote is found in the Goals chapter.

(p. 81) [Mikey talking] “In fact, I think my department has done remarkable well given what we’ve had to work with.”.  The unspoken thoughts from Carlos … “but your department cannot be doing well because the company is failing and if the company is failing then we are all failing and there is no way we can justify the performance of our departments …”

Note worthy items from the companion book “Overcoming the FIVE Dysfunctions of a Team – A Field Guide” from chapter “Overcoming Dysfunction #5:  Focusing on Results”.

  1. “What is it about us that makes it is hard to stay focused on results?  It’s this thing called self-interest.  And self-preservation.”  (p. 69)
  2. “How do we avoid this?  The key lies in keeping results in the forefront of people’s minds.”  (p. 70)
  3. “They (teams) have to eliminate ambiguity and interpretation when it comes to success.”  (p. 70)
  4. “Key milestones (a.k.a., team success metrics)?  There are only two consistently wrong answers:  none of the above and all of them.”  (p. 71)
  5. “When players on the team stop caring about the scoreboard, they inevitably start caring about something else.  And that something else is usually not the team.”
    (p. 72)
  6. Distraction #1:  Ego
    “Well, at least my area is doing well.”  (p. 75)
  7. Distractions #2 and #3:  Career Development and Money
    “Anything that stands in the way of performance must be addressed openly and directly, even if it is something that is sensitive to one or more members of the team.”  (p. 76)
  8. Distraction #4:  My Department
    “the tendency of team members to place higher priority on the team they lead than they place on the team they are a member of.  I call this the Team #1 Dilemma.”
    (p. 77)
  9. United Nations Syndrome or Congressional Syndrome
    “In essence, whenever push comes to shove, they compete with their teammates rather than collaborate with them.”  (p. 78)
  10. Scoreboard
    “every team should have a single, easy-to-read visual tool for assessing its success at any given point in time.”  (p. 79)

skipping ahead the re-read blog for now

[Exhibition (one, 9-page chapter)]

This is the chapter that summarizes Lencioni’s 5 Team Dysfunctions model; it is the CliffNotes for this book.

And the companion Field Guide for this book, also by Lencioni, has a great summary for the model on page 7 written in a positive tone … worth displaying in an office setting.

The dysfunctions and their anti-patterns starting from the bottom of the triangular model.

  1. Absence of Trust – anti-pattern invulnerability
    (i.e., no guarded conversations that withhold information)
  2. Fear of Conflict – anti-pattern artificial harmony
    (i.e., the ability to argue in the spirit of making the best decisions and NOT create “collateral damage”)
  3. Lack of Commitment – anti-pattern ambiguity
    (e.g., no common plan / many agendas)
  4. Avoidance of Accountability – anti-pattern low standards
    (i.e., not calling out peers, probably because there is no true buy-in to a common plan)
  5. Inattention to Results – anti-pattern Status and Ego
    (e.g., my team is #1 priority)

The User Experience Risk

What has influenced my thinking (so far) about
#7  Risk of end-users not using or liking the product
from a previous blog entry “Seven Risks in Software Development

From my work experience, everyone has an opinion about what a good user experience (UX) is.  Few are really talented in UX, except those who have studied and practiced UX.  And even the talented ones, designs and implementations must be checked to see if they work as intended with the targeted users.

UX is front and center in every product.  UX is the visible part of the product.  Thus good designers carefully and patiently explain the design.  Taking in feedback when appropriate, but most often explaining the design — several times to various stakeholders.

This risk is inspired by Marty Cagan‘s (product management consultant) basic question:  will the users use the product?

Dan Olsen, author of “The Lean Product Playbook” has two simple models I really like.

Model 1:  Olsen’s Hierarchy of Web User Needs, that helps put UX in perspective.

Layer#1:  Is the site available for the user?
Layer#2:  Is the site too slow?
Layer#3:  Does the functionality work?  (Quality)
Layer#4:  Does the functionality bring value to the user?
Layer#5:  How easy is the web page to use?

UX goes directly at Layer#5, but all layers are important to the users.  UX designers should be working with Product Management, User Research, Development, and others to make sure the right functionality is being developed and the product is working well at all layers.

Model 2, Dan Olsen, is the UX  Design Iceberg.  On-top is the Visual Design.  Below the Visual Design and below the water’s surface is Interaction Design, followed by Information Architecture, and at the base is Conceptual Design.

For more on Information Architecture, follow the thought provoking work
of Amy Covert who’s tag line is “Make the unclear be clear”.

(Dan) Olsen’s Law of Usability:
“The more user effort required to take an action, the lower the percentage of users who will take that action.  The less user effort required, the higher the percentage of users who will take that action.”

Olsen’s Law of Usability is good way for the broader team to think about UX and why a good UX matters.  For a deeper look, check-out BJ Fogg’s Behavior Model –> B = MAT.

That is, Behavior = Motivation + Ability + Trigger
where Ability (to perform an action) is what Olsen’s Law of Usability is referring to.

And Nir Eyal uses BF Fogg’s behavior model and other research to develop his popular Hooked model for products.

Dan Olsen runs and hosts a Lean Product Management & UX meet-up in Palo Alto, that has featured both BJ Fogg and Nir Eyal as speakers.  There is a Dan Olsen YouTube channel that captures many of these great talks, so enjoy from afar.

I firmly believe great products are a collaborative result of Product Management (business-side) + User Experience (end-user interests) + Development (technical side) all working well together and not one or two of these  disciplines dominating the conversation.


Seven Risks in Software Development

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





Extreme Programming Explained

Tom Cagley’s re-read Saturday series continues with the book “Extreme Programming Explained (Embrace Change)” by Kent Beck with Cynthia Andres (second addition)

XP is much about software practices, rather than Scrum which is more about project management in an agile setting.  Read this interesting Continuous Delivery blog which complains Scrum leaves off the software practices and mentions that Continuous Delivery was built upon XP and Lean practices.

[Note:  after reading this book and I have changed my mind on the above point I made going into the re-read.  XP is as much about team dynamics and software project management as Scrum is.  XP adds good technical practices into the framework and that difference is noticed more than the other parts.]

Preface & Chapter 1  Tom, I liked your back-then and now comments.

I am still waiting for my copy of the book to show-up. I look forward to the read, as good technical practices make agile work.

Example, scrum is a good framework to follow for several reasons, communications, feedback, and team improvements. However, without the good technical practices, scrum will fall flat.

Martin Fowler makes a much stronger case in his classic blog, FlaccidScrum.

Chapters 2 & 3 [“Learning to Drive” & “Values, Principles, and Practices”]

Chapter’s 3 figure 1 bridge, is an excellent visual { values <- principles -> practices }.

Chapters 4 & 5 [“Values” & “Principles”]

It is hard to argue with any vitreous Values and Principles set, whether they come from Agile, Lean, Kanban, XP, Waterfall …

I like Jurgen Appelo’s approach in Management 3.0 (the book) and the “Do-It-Yourself Team Values” exercise.  Pick what makes sense for the team and the situation and do not pick too many (3 – 7), so the team has a focus.  After mastering certain value – principle – practices combinations, you may  choose other values / principles to focus on.

And we read similar advise in Extreme Programming Explained, where other principles might be included depending the the team’s situation (e.g., traceability for safety-critical systems).

Note:  Waterfall, really?  Gil Broza actually documented the Waterfall values in his “The Agile Mind-Set” book.  The values themselves read well (e.g., “Get it right the first time”). But in most cases, for software development, they are VERY difficult to actually do without increasing project risks.

Chapters 6 & 7 (“Practices” & “Primary Practices”)

Put a “*” on chapter 7, great advice!  I particularly liked the last primary practice – Incremental Design — defer design changes to the last responsible moment (real options thinking).

Beck cautions us “Without daily attention to design, the cost of change does skyrocket.” (page 52)

Beck’s simple heuristic look for and eliminate duplication – excellent!

Chapters 8 & 9 (“Getting Started” & “Corollary Practices”)

Beck provides practical advice on how-to get started implementing XP practices within a team setting or even just by yourself.  At the end of chapter 8, there is a nice map of “Energetic Work” (figure 8) to keep in-mind.

Chapter 9 talks about 11 Corollary Practices in XP, and interesting “Real Customer Involvement” is listed as a corollary practice, rather than a primary practice.  However, Beck explains why listed here, some of the development fundamentals should be addressed first — the two mentioned are (1) accurate estimates and (2) low defect rates.

Chapters 10 & 11 (The Whole XP Team & The Theory of Constraints)

Wow, chapter 11 changes the subject from chapter 10 — really two separate topics here.

Beck’s explanation on how different disciplines (architects, interaction designers, testers) resist working together, at the same time, is classic.  However, for user experience and feature validation , I do think a Lean approach should be considered in most cases.

Validate the feature and/or user-interaction with a prototype and with customers BEFORE it becomes part of the development backlog.

Why?  “the amount of waste and rework is very high because backlog items have not been validated” from Marty Cagan’s Dual-Track Scrum  blog (first paragraph) .

Beck’s explanation of ToC (Theory of Constraints) using laundry is one I can easily understand!  Again, I wonder how this chapter would be re-written today in light of Kanban and WIP (work-in-process) limits in the software context.

Chapters 12 & 13  (Planning:  Manage Scope & Testing:  Early, Often, and Automated)

Two great, short, chapters here.

*  [comment #1]

“Planning:  Manage Scope” is a must read for any project manager of software.  Beck write’s well what an experienced Project Manager has already learned.

See page 92 …

  1. “Time and costs are generally set outside the project.”
  2. “Lowering the quality of your work [to meet schedule] doesn’t eliminate work, it just shifts it later so delays are not clearly your responsibility.”

Therefore, scope almost always is the ONLY negotiable item from the project management “iron triangle” – Schedule, Budget, and Scope.  Which explains why Scrum’s sprint planning sessions were invented and are so popular today.

And I like Beck’s definition of ‘”Complete” means ready for deployment; including all the testing, implementation, refactoring, and discussions with the users.’ (p. 93)

The opening sentence of Chapter 13 is profound – “Defects destroy the trust required for effective software development”.  Having seen defects from both the inside and outside, I agree!

“Here is the dilemma in software development:  defects are expensive, but eliminating defects is also expensive.”

And one argument I had not considered before – “Investments in defect reduction makes sense as an investment in teamwork.”  Normally we consider the impact of defects to the business and end-users, but not the impact of defects to the team itself.

Chapters 14 & 15 (Designing:  The Value of Time & Scaling XP)

I liked much of what Beck and Andres states about Design.

  1. Do design!  And design in small increments whenever possible.
  2. Design at the last responsible moment.
  3. Designing software is not the same as design physical things (e.g., buildings). Although in today’s complexity between numerous systems, this is less true.
  4. Simplicity in design and some specific ideas to achieve it.
  5. Was Beck the first to use the popular phrase “big ball of mud” back in 2004?

One idea I think should be reworded is “Weekly delivery of the requested functionality is the cornerstone of the relationship.” (p. 109)

I think this idea pushes teams to just follow the customer (or Product Owner) lead, even when the team knows technical debt is piling up and there likely will be no plan to address it in the future.  And we do know, there are always new features the customer wants delivered yesterday.

I actually think Beck and Andres was cautioning us against  Big-Design-Up-Front (BDUP), rather than telling us to ignore technical debt in favor of delivering the next new feature.

Scaling XP (Chapter 15)

I think Beck left a marketing opportunity behind by not defining some elaborate scaling framework for XP🙂

Some really good thoughts here.  Beck is a pragmatist, as am I.

  1. “The project manager makes sure the the organization’s expectations are met.”
    … while the team is using XP practices  (p. 113)
  2. “Don’t push your new-found (XP) knowledge and power on others for your own benefit.”  (p. 114)
  3. “I never became an actuary, but the resulting system (and team) was much stronger than if the actuary worked on his little corner of the system while I worked alone on the user interface.” (p. 115)
  4. “The XP strategy for dealing with excess complexity is always the same: chip away at the complexity while continuing to deliver.” (p. 115)

Chapters 16 & 17 (Interview & Creation Story)

Short and interesting!

About the Interview, I wonder how the XP transformation did the next of couple of years. XP was clearly a mandated change for the organization, train everyone and watch it take hold.  But to start, there were 1/3 were for it, 1/3 were neutral, and 1/3 had serious questions.

One bright call out, quality did improve!

[** comment #2]

The Creation Story (Chapter 17) is how the development teamed formed and became much better than the previous team using the XP framework and practices.  This XP Creation Story project ran like scrum projects that I am familiar with (p. 127)

How the backlog user stories were identified for each iteration:  the customer (product owner) choose.  But how did the customer know?  In this case, the customer was a subject matter expert and the domain space was already very well understood – payroll.

Contrast this to many of today’s projects.  Teams are often working in a domain that is emerging, have market acceptance risks, and there may not be a domain expert.  So we have ideas about quickly validating the selected backlog user stories (e.g., Lean Startup) before the true development starts (i.e., dual track agile).

(p. 128) “End-to-end is further than you think”

Chapters 18 & 19 (Taylorism and Software & Toyota Production System)

Taylorism – Frederick Taylor, early twentieth-century industrial engineer, concerned with efficiency.

Beck & Andres (p. 132)
“Things usually go according to plan,
Micro-optimization leads to macro-optimization,
People are mostly interchangeable and need to be told what to do.”

Does not work well in knowledge work (e.g., software development).
Agile values states the opposite.

Toyota Production System (TPS) – the foundation of lean software development.
A great, short summary of TPS!

Beck & Andres writes about a worker cautiously pulling the chord shortly after a quality issue was spotted. From Lean, this is the Andon Chord (pull it immediately).  And Yea!!! for any organization culture which supports the Andon Chord philosophy.  It definitively would take nerve to “stop the workflow” in an organization mainly focused on throughput – won’t happen very often, as this action would be viewed as a risky move.

Chapters 20 & 21 (Applying XP & Purity)

(p. 139) “You should see big improvements in the first weeks and months, but those improvements only set the stage for the big leaps forward that happen further down the road.”  — this selling statement could apply to any framework.  Could happen that way, but no guarantee.

Two implementation tips I like are …

  1.  Speaking about using a unit test framework  –
    (p. 141) “Expecting others to do what you are not willing to try yourself is disrespectful and ineffective.”   This advice, of course, applies in many other situations.
  2. (p. 141) “Your organization learns to deploy solid software predictably, then invites external customers to be part of planning.”
    Wow, once you arrive here, your team is golden!

Chapter 21 (Purity)

(p. 146) “It’s worse to fail with an XP team than to succeed with a pure waterfall team.  The goal is successful and satisfying relationships and projects, not membership in the XP club.”

XP, as with any process & practices framework, is a means to a goal, not the goal itself.

Chapters 22 & 23 (Offshore Development & The Timeless Way of Programming)

Beck and Andres make a good case to use the wording of “multi-site”, instead of “offshore”.  But the chapter is titled with Offshore — well this chapter, “Offshore Development”, was a few years back  (2005).  The term “distributed teams” is commonly used today (2016).

(p. 150)  “Jobs aren’t going in search of low salaries.  Jobs are going in search of integrity and accountability.”  That is, capability to deliver value first and labor costs second.

Chapter 23 (The Timeless Way of Programming)

Wow!  Note to self, re-read this chapter for culture-change thoughts about creating higher value software deliveries from  teams.

It is vital that we achieve a balance in the organization between business concerns, user experience concerns, and technical concerns.

*** [comment #3]

(p. 154) “With more experience I began to see the opposite imbalance [of technical dominance], where business concerns dominated development.  Deadlines and scope set for only business reasons do not maintain integrity of the team.  The concerns of users and sponsors are important, but the needs of the developers are also valid.  All three need to inform each other.”

(p.154) “My goal is now to help teams routinely bring technical and business concerns into harmony.”
Note:  I bet this sentenced would be re-worded slightly today by adding User Experience as a separate concern to Business and Technical.

A 2005 prophecy about Agile Adoption …
(p. 154) “Without a change of heart, all the practices and principles in the world will produce only small, short-term gains.”

And there is two more good thoughts …
(p. 155) “XP relies on the growth of powerful [capable] programmers; able to quickly estimate, implement, and deploy reliable software.”

(p. 155) “Sharing power is pragmatic, not idealistic.”

Chapters 24 & 25 (Community and XP & Conclusion)

Brief wrap-up statements in both of these chapters.

(p. 158)  “Accountability is particularly important when making changes.”

Do NOT ignore the great Annotated Bibliography at the end of the written text.  Some really interesting categories and titles there.


Great read (or re-read) for software professionals, including software project managers and scrum masters!

My favorite quote from this book is
“End-to-end is further than you think” (Chapter 17 – Creation Story, page 128)

End of the re-read of “Extreme Programming Explained (Embrace Change)”


Re-read Saturday of “Commitment …

Re-read of the book
“Commitment Novel About Project Risk” (1st edition) by Olav Maassen, Chris Matts, Chris Geary (a.k.a., Options Expire)

Responses to Thomas Cagley’s re-read Saturday blog posting series.
I am posting my responses here, before leaving a reply over there (chapter by chapter)

This book is a graphic business novel with some blog like writing sprinkled in.  So this book reads fast.

Chapter 1 and 2:  a traditional Project Manager is replaced by Rose.

Rose takes up where David leaves off, since that is the only way of running a project she knows, and is heading down the same, no-win path.  The project plan is rejected again at the end of chapter 2.

The sketch of the project team facing their newly appointed (and unpopular) project manager (Rose) is classic — nobody is happy

Rose has been and is overworking, and her younger sister Lilly points out she is heading down the path of being a “moany old maid soon”.

The team is not happy with being asked to work extra hours to make this project happen with the current plan.  A plan the team was handed and did not help create.

And the only thing that will make these stakeholders happy is profit, and this project is at-risk.

Chapter 3:  Rose learns a different way to think about project management.

Jon:  “So they can co-ordinate their activity.”
Rose:  “But I do that.”

I like the idea a Host Leadership, rather than Servant Leadership, see “I’m Not a Servant – I’m a Host! A New Metaphor for Leadership in Agile? ”  Pierluigi Pugliese (other have said this too)

Notes from chapter 3

  1. Intro to flow principles, Kanban — and away from directive leadership.
  2. Avoid committing to early.  That is, avoid those big, detail plans upfront when things are likely to change (e.g., software development projects).
  3. Blog about technical debt (“dirty dishes”)

Chapter 4:  Rose practices a new style of project management, based on kanban, agile, and lean …

We  now see

  1. Planning collaboration with the team
  2. Visualization of work
  3. Stop starting and start finishing
  4. A reminder:
  5. Staff liquidity … people breaking out of their silos to break through the project bottlenecks.
  6. Probing on the project bottleneck to see what the problem is.  In this story it was “the specifications do not have enough detail for us to test”
  7. Deliver value to the customer in small value, so adjustments can be made along the way, and not risking getting way off track and not delivering what the customer values.
  8. Value analogy:  ordering a cup of tea, rather than ordering a tea-bag.
  9. Feature Injection is added to the story line.  Figure-out the value by starting at the end — ask “why” questions to figure-out what the customer is really after or really values.  [And then test you hypothesis] … “Hunt for Value” [and then verify you found it]

Chapter 5:  Rose explains “staff liquidity” to a skeptical execute.
This is like T-shaped skills.  And fortunately, most people are curious, enjoy learning and developing new skills.

Chapter 6:  the plot thickens, as Rose’s project is under scrutiny.
But first a little explanation of Game Theory and how it applies to group dynamics.

People’s tendencies are to avoid uncertainty, even if that means to make a decision too early.  Rose is managing the project under “real options”, or deferring the key decisions until that last practical moment, introducing more uncertainty and fostering collaboration.

There is blog post in chapter 6 to tell us not to go too crazy with real options and only consider options for the key decisions.  Plus, introducing too much uncertainty is bad for team dynamics, “choice overload” or “decision paralysis”.

Perhaps “choice overload” affects team performance and perhaps not, see “More Is More: Why the Paradox of Choice Might Be a Myth“.  The situation and the end results will help you and the team make that call.

An aside:  in the last re-read, How To Measure Anything by Douglas Hubbard, in the last chapter, discusses real options also.  I think both this book and Hubbard are saying similar things about real options, you can’t put a financial value using the Black-Scholes formula for business decisions.  Evaluating the probability value for the formula is the difficult task that does not translate well outside of the financial markets.

One last note:  I applaud the authors often subtle references of exercise to manage stress.  Rose, after an emotional setback, has a great workout in chapter 6.

Chapter 7:  Rose finds out that the project sponsor is pulling out; option planning, starting with brain storming the possible scenarios.

And for each scenario, a plan of action to either lessen the blow or be in position to take advantage of a possible opportunity.

Rose ushers out the elephant in the room (people may lose their jobs very soon), by helping the team put their personal scenarios in-place, before tackling the scenarios for the project.

This chapter’s blog title is “Increasing your psychic odds with Scenario Planning”.  Now Rose has the team thinking on their feet to come with options to save the project.

Chapter 8:  Rose becomes the hero.  She is totally prepared for the customer meeting by taking the customer’s perspective and knowing several options.  Rose is very confident and poised during the customer meeting, which impresses her managers.

Final Thoughts:  I totally misestimated the time this re-read would take.  I re-read this book in 2-3 hours in the first week.  Mainly because this book is such a great read with engaging pictures.  But slowing down the re-read pace did help me learn more about what was behind Rose’s growth and success.

End of the re-read of “Commitment …” blog entry