Before we dive in – let’s begin a new poll for the next book in our Re-read Saturday.  I have had a number of suggestions:

Pick two and we will start on the top choice!  Note: There are two books on the list that will be first reads for me (I will let you guess).  All of these books are very relevant to agile, lean and process improvement.


Whether you like the word transformation or not, many in the process improvement and agile communities help to facilitate change. Involvement in any non-trivial change effort requires resources, people, support and the expenditure of political capital. If change uses an organization’s people and assets someone will ask what the return on those assets are and whether those assets could return more if used elsewhere. I can tell (and often have told) a great story about the impact of a good working environment, doing the right work, and good processes. The response I get to my rationale on the value of being agile is ‘can you prove it.’ Can you prove it’ translates directly into ‘can you measure it’, and ‘are those measures meaningful?’ A model for answering that question that I am sketching out at a program or organization level has to answer the following questions:

(more…)

A New Copy!

One note to start with: we are on Chapter 14 today out of 17. So, after today, we have approximately four more weeks. As a result, we will have to choose another book in the next couple of weeks.  I have received some suggestions, and I have also asked the interviewees that appeared in the Software Process and Measurement Podcast in 2017 which was the most impactful book they have read. I would also like your input. What do you suggest that we read next?  

Chapter 14 is titled Introduction to Forecasting in Daniel S. Vacanti’s Actionable Agile Metrics for Predictability: An Introduction (buy a copy today)

One of the definitions of predictability is the ability to make a quantitative forecast about the future state of a process. In this light, a forecast is just a calculation about the probability of the occurrence of some future event; an estimate might be a forecast. At one point in my career, the group I was part of had to collect data on a nightly file maintenance process so we could determine whether the process could finish within the required time window.   (more…)

Quote from Mark Twain - too much whiskey is barely enough

Can you prove it?

Organizations and team embrace a framework or technique for a purpose. That purpose is generally to address a real or perceived problem.  When you get very specific, each change is done a different reason.  When teams or organizations are asked whether they attained their goals, solved the problems they intended or realized the promised benefits, very few have gathered more than a handful of success stories before losing focus and moving to the next big thing. Unless you can answer whether the framework or technique delivered tangible value,  leaders will be reluctant to spend money on changes.  Best practices are a point in case.  Best practices are, by definition, practices that some have found useful (or at least that someone has professed are useful).  Every process improvement and/or best practice adoption that is not legally mandated needs to follow the following high-level feedback loop.

  1. Decide why you are making the change and what the outcome of the change will be in tangible terms. Developing a solid reason for why you are making a change may sound like a trivial step, however, the rationale will often directly impact the passion for making the change. People pursue survival changes with a lot more vigor than incremental quality of life improvements.
  2. Develop a hypothesis of why the change you are making will satisfy the rationale for the change.  Changes that actually work rarely are the outcome of magical thinking or dumb luck. If there is no logical reason the change you are proposing will have an impact you are very likely wasting time and money.  Use the scientific method!
  3. Set SMART goals that will be used to track and evaluate the change.  As a reminder, SMART stands for specific, measurable, achievable, relevant, and time-bound.  The goals should cover the journey and outcome based on the hypothesis crafted in step 2.
  4. Benchmark the process you are changing.  Consider collecting data specific to the change and data to evaluate the impact on the overall system.
  5. Make the change.  You still have to make and support the change.  Your journey measures will be helpful to make sure that the change is being implemented well.
  6. Collect the data to show the impact (compared to the benchmark developed in step 4) for several cycles after the change has been implemented.
  7. Use the data you collect to tune the process. Pick a feedback loop and tune the process.  Rarely are major changes perfect right out of the box.  Using feedback to tune the process helps to ingrain the change and to make sure it is delivering value.
  8. Report your findings.  Share the impact with everyone involved.  Positive data will help to reinforce the change and will help sell the next round of changes.  In scenarios where the change doesn’t deliver value reporting reinforces the principle of transparency.  If a change doesn’t deliver, don’t double down on a failure; revert back and try something else.

People make changes to how they work on a daily basis.  Some changes are minor and, in some cases, are not worth developing a full-scale proof of impact. For example, deciding on whether to order grilled tofu or pizza for the team lunch doesn’t require a proof of impact.  Some large-scale changes like adopting Scrum, Kanban or DevOps require a great deal of time, focus, and money. It makes sense to be able to answer the question of whether you got what we thought you would get with something more substantive than a shrug.

Next an example

Getting the most value out of a process is important to any leader.  Balancing getting the most value with getting value sooner complicates the discussion.  In some cases, getting some value sooner is worth more than the same value delivered later.  Guiding the delivery of value is more complicated than a rank ordering a list of user stories and then magically hoping that everything will happen in the most effective and efficient manner possible.  Measurement is an important tool to help team and organizations ask the right questions.  To borrow an idea from Daniel Vacanti’s Actionable Agile Metrics for Predictability, measurement helps people ask the right questions sooner.  The following 6 flow metrics provide process transparency into organizations that leverage continuous flow, scrumban, and/or Scrum as the basis for their Agile implementations.  (more…)

Cycle time?

In a recent discussion of Agile metrics, I was asked whether there was a difference between cycle time and throughput.  The simplest answer is that they “feel” similar. Many in software measurement define throughput as the number of units of work (UoW) delivered per unit of time; while cycle time is the amount of time per unit of work (as defined in Actionable Agile Metrics).  The two metrics are the reciprocal of each other. These definitions are functional; however, the cycle time metric is an abridgment of the how the measure is defined in the broader process measurement world.  With the profusion of lean six sigma black belts in the software measurement world lack of precision in the definitions can lead to comical misunderstanding.  Cycle time, with and without lead time, tell interesting but very different stories and are both useful.   (more…)

A New Copy!

Today we tackle Chapter 3 of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability. Chapter 3 is titled Introduction to Little’s Law.  Little’s Law is incredibly clever and potentially life-changing if you are overly fixated on size.  Buy your copy today and read along!

We originally wrote about Little’s law in September 2014. Little’s Law brings WIP, Cycle time and Throughput (metrics discussed in chapter 2) into a relationship that can help deliver information that can be used to answer the basic questions of predictively. The basic configuration of Little’s law is stated as: (more…)

A New Copy!

Today we tackle Chapter 2 of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability. Chapter 2 is titled The Basic Metrics of Flow.  The concept of flow is critical to predictability.   Buy your copy today and read along! (more…)