Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 467 features our essay on value. Value is the most talked about and least understood concept in Agile. In terms of software development, enhancements, and maintenance, the value of a piece of work is the worth of the outcome that results from doing the work.

In the second position is Jeremy Berriault and the QA Corner!  Jeremy discusses testing in difficult situations. Are there differences? Jeremy has the answers!

Gene Hughson completes the cast by bringing a discussion of a recent missive, Management, Simple and Wrong – Semantics, Systems, and Self-Correction.  This entry at  Form Follows Function even includes a reference to Snidely Whiplash!

Upcoming Appearances

Metricas 2017

I will be keynoting on Agile leadership and then delivering one my favorites, Function Points and Pokémon Go
29 November 2017
Sao Paulo, Brazil


Re-Read Saturday News (more…)



Value is in the eye of the beholder.

When deciding which piece of work gets included in a product’s portfolio value is touted as the most important arbiter of priority.   Value is so important that the first of the twelve principles in the Agile Manifesto includes the concept of value.

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  

Clearly, the value is a core tenant in the Agile community.  But . . . the word has definition issues, does not have a single accepted unit of measure, and can relate to lots of different attributes; therefore, it can generate LOTS of different opinions.  In Value: Looking for Value in All of the Right Places, we provided a number of questions to prime the pump when mining for value.  The essay is a starting point, not an ending point.  Because there are many potentially different aspects contributing to value we need to recognize that sometimes the value is driven by perspective. (more…)


Value, as we have noted, is often discussed and rarely defined.  Much in the same way personal or organizational values are tossed about, the value of a project, product or piece of work is used in the same mythic but nebulous fashion.  Kumar Javvaji, @solidwood described; “Value is a tangible contribution to meeting a critical need.” This is a credible definition; however, we still need to translate each tangible contribution into a language that can be understood by all of the stakeholders in the process. (more…)

Don’t Value Be a Detour!


Value is the most talked about and least understood concept in Agile. In terms of software development, enhancements, and maintenance, the value of a piece of work is the worth to an organization it is the outcomes that result from doing the work. That definition might be hard to wrap your head around. More simply, value is what you get from the sweat, tears, and money needed to take an idea and convert it into functional software (or hardware, network, or service). From an organization’s perspective, some functional software is more valuable than others regardless of the input. The difference between the time and money and the perceived value of what is delivered is the net value.  Most of the definition of value should boil down to basic accounting, but unfortunately there are complications.

Complications include:

  1. Value can accrue from many sources. It is often difficult to get a handle on (or even remember) all of the potential sources of value.
  2. Results must be valued in a common unit of measurement. Differing units of measure make coming up with a total value number difficult and make comparisons of an alternative hard.
  3. Value is often a function of the perspective of the person estimating or determining value. Perspective is often even more of an issue when accounting for indirect or seemingly intangible sources of value and cost.

The potential sources of value are often varied. For large, mission-critical pieces of work or products, the number of sources can be quite large and some might be more important than others, while for smaller pieces of work the source of value might be very specific. The list below identifies several possible sources of value and potential seed questions to elicit information about a value source:


Impact/effect on the organization’s

  1. Will doing (or not doing) the work have a direct impact on the organization’s mission?

Coupling – describes how related or coupled to the business is the piece of work to the mission or vision.

  1. How related is the piece of work to the organization’s mission and/or values?

Types of Value

Direct value is generated by direct creation or consumption of resources.

Revenue – Sales, Investments, License Fees, Patent Shares

  1. How much income (or returns) for the organization is generated by executing this work?

Costs – Reduction of cost include savings from not doing work, retiring manual workarounds, or tools.

  1. What are the cost savings you expect to accrue from implementing this piece of work?
  2. How will this piece of work impact cost in the organization?

Labor savings – Labor savings are a specific form of cost savings. They are generally generated by reducing staff or avoiding hiring.

  1.  How many FTE can be trimmed/removed from your budget when the work is implemented?
  2. What is the impact of implementing this work on your hiring plans?

Improved efficiency – Savings in this category are generated when work is done “better.” Efficiency is a reflection of more usable output per unit of input. Productivity is a measure of efficiency. (Note: typically seen as labor reduction) Efficiency can be improved by doing a better job (higher quality – more effective) and/or doing the job better (less effort or more usable output).

  1.  What portions of your operations budget can be trimmed/removed based on implementing this work?

Indirect – Costs and benefits are derived from the use of direct labor and resources.

For example, software has a tangible direct value.  Using the software to do something delivers an indirect benefit from the software.

Effectiveness – Effectiveness is a reflection of how successful a process or project is in producing the desired outcome. Improving quality is a reflection of improved effectiveness.

  1. How will this piece of work improve quality and by how much?
  2. How will this piece of work increase improve the probability of delivering the expected value?
  3. How does implementing the work deliver a better product or service? Note: I always ask why won’t improved effectiveness increase revenue or reduce operations costs?

Improved Scaling – Scaling is providing a system or process the ability to expand services, products, or generally do more. If the scaling features being deployed are to be used immediately the cost or revenue impact would be direct. In scenarios in which the work is being done to “position” the organization for change ,the impact is indirect.

  1. Does the work position the organization or grow efficiently in the future?  (Growth should relate to the mission.)

Risk Reduction – Risk is the probability of something happening (typically that negatively impacts plans or operations).  Reducing risk is the quantified reduction in the probability of occurrence or impact if the risk becomes an issue.

  1. What risk is less likely to occur if this work is delivered?
  2. Does this work reduce the impact of a risk (be specific if possible)?

Future Options – Some work, due to its nature, changes the options possible in the future. For example, implementing a maintenance on a software package so the organization is positioned to use/implement features that will be delivered in the futures. (This is a specialized form of scaling).

  1.  Will this work enable other changes in the future? Follow-up with, what value will those future changes deliver?

Goodwill – Goodwill is a valuation of the brand, customer base, external relations, and relations with current and future employees.

  1. Will doing (or not doing this work) negatively impact the institutes brand or relationships with stakeholder communities?

People/Current Employees

Engagement – Engagement is a measure of how likely an employee is to do their best, present best effort all of which is committed to the organization’s goals and values. Engagement is often linked to higher quality and productivity (effectiveness and efficiency).

Morale – (a specialized form of engagement) Morale is the impact on job satisfaction, outlook, and attitude.

  1.  Will the work item improve employee engagement? Follow on by asking: how the improvement impacts areas such as employee retention, reduction in sick time, and less retraining?

Motivation – The impetus to do what is needed to ensure the company/organization is successful.

  1. How will the piece of work impact employee motivation? Do you expect the motivation gain to translate into improved effectiveness or efficiency?

To paraphrase Johnny Lee, we need to look for value in all of the right places because value is rarely a simple number that a product owner carries around in their back pocket. While sometimes full-scale, detailed cost benefit analyses are required, most work needs far less detail. Most work does need an understanding of value so it can be prioritized, so that the really important bits can be identified, and so that a minimum viable product can be identified. The list of sources and questions are a tool to prime the discussion pump.

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 435 features our interview with Allan Kelly.  Our discussion touched on the concepts behind #NoProjects.  Allan describes how the concept of a project leads to a number of unintended consequences.  Those consequences aren’t pretty.

Allan makes digital development teams more effective and improves delivery with continuous agile approaches to reduce delay and risk while increasing value delivered. He helps teams and smaller companies – including start-ups and scale-ups – with advice, coaching and training. Managers, product, and technical staff are all involved in his improvements. He is the originator of Retrospective Dialogue Sheets and Value Poker, the author of four books, including “Xanpan – team-centric Agile Software Development” and “Business Patterns for Software Developers”. On Twitter he is @allankellynet.

Re-Read Saturday News

This week we tackle Chapter 8 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 8, titled “Changing Mindsets.” The whole concept of mindsets would be an interesting footnote if we did not believe they could change. Chapter 8 drives home the point that has been made multiple times in the book, that mindsets are malleable with self-awareness and a lot of effort. The question of whether all people want to be that self-aware will be addressed next week as we wrap up our re-read.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate one more week.   The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of both pursuing an organizational transformation and also using the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and start the re-read from the beginning!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.


The next Software Process and Measurement Cast will feature our essay on incremental change approaches.  We will also have columns from Jeremy Berriault. Jeremy blogs at  and Jon M Quigley who brings his column, the Alpha and Omega of Product Development, to the Cast. One of the places you can find Jon is at Value Transformation LLC.


Picture of the book cover


This week we are back to our read of Commitment – Novel about Managing Project Risk by Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016) .  Chapter 4 introduces more agile techniques, including work visualization, staff liquidity and a focus on outcomes. (more…)

Listen Now

Subscribe on iTunes

The Software Process and Measurement Cast 388 features our interview with Dr. Mark Bojeun. Dr. Bojeun returns to the podcast to discuss how a PMO can be a strategic tool for an organization.  If a PMO is merely a control point or an administrative function, their value and longevity are at risk.  Mark suggests that there is a better way.

Mark has last visited the Software Process and Measurement Cast on SPaMCAST 280.  We discussed his book, Program Management Leadership: Creating Successful Team Dynamics (Kindle version).