Play Now!
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

I apologize for the delay in publication — ahhh the vagueries of travel!

SPaMCAST 570 features our essay on the components of good sprint goals. Sprint goals provide direction and energy, and they communicate with the outside world. A sprint goal should be a straightforward statement that a product owner should be able to craft quickly and then agree upon with a team. We provide a structure to keep goals simple and impactful.  

We will also have a visit from Susan Parente. In this installment of Susan’s Not a Scrumdamentalist column, we discuss value.  Value is core to many practices, the problem is that value is a very nebulous concept. Susan provides guidance. Continue the conversation with Susan at and visit her company at (more…)

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

Software Process and Measurement Cast 490 features a return visit from Michael West.  Michael West is the author of Return On Process (ROP): Getting Real Performance Results from Process and Real Process Improvement Using the CMMI Michael and I talked process improvement and how process improvement translates to the bottom line.  Mr West originally appeared on the SPaMCAST 308 []

Michael’s bio:

Michael West is a life-long practitioner and student of process improvement. He is the co-founder of Natural Systems Process Improvement (Natural SPI), a consultancy specializing in designing, developing, and deploying process systems that enable measurable business performance improvement gains. Mr. West’s process insights and innovations have helped many organizations in various sectors of the economy achieve real process and performance improvement. His process consulting clients include ATK, Autodesk, AVL, BAE, BB&T, Crane Aerospace, DCS, Deloitte, Sandia National Labs, Reliability First, and the US Navy. Mr. West frequently presents and speaks at industry conferences, and is the author of Real Process Improvement Using the CMMI (CRC Press, 2004) and Return On Process (ROP): Getting Real Performance Results from Process Improvement (CRC Press, 2013).

Contact Michael at:



Twitter: @ItsTheProcess

Re-Read Saturday News

In week five of the re-read of L. David Marquet’s Turn the Ship Around! ( we tackle chapters five and six.  These two chapters, titled Call to Action and Whatever They Tell Me To Do! continue to tell the stories that form the basis for Marquet’s leadership model.

Current Installment:

Week 5: Call to Action and Whatever they tell me to do!

Previous Installments: (more…)

Can we really measure anything?

Organizations and teams come to agile—for that matter, any concept, framework or technique—for a wide variety of reasons.  Even if we are just the keeping up with the neighbors, we need feedback to know if we have met our goal.  We need feedback because—to quote Paul Gibbons, author of The Science of Successful Organizational Change (Re-read Saturday)—“we confuse what we think ought to work” with what does work (quote from SPaMCAST 480).  Feedback is required when we are trying to determine if the time and effort invested to adopt agile delivered the expected results.  The typical results promised from an agile transformation fall into nine overall categories.  Each of these can be used to generate questions which can be used to measure and assess impact.

  • Lower Cost – Are teams delivering functionality at less cost than they did when using different methods?
  • Faster Completion – Are teams delivering projects and programs faster?
  • Frequent Deliveries – Are teams able to release functionality more often?
  • Transparency – Are the agendas, policies, conditions, and decisions available to everyone involved in delivering value?
  • Business and Customer Focus – Is the work that teams do important to the business and/or the organization’s customers?
  • Engagement – Are teams, stakeholders, and customers working collaboratively in a concerted fashion to deliver value?
  • Predictability – Are teams able to state what they will do, when they will do it and then deliver on that promise?
  • Flexibility – Can the team change direction to meet business needs?
  • Increased Quality – Are teams delivering more usable functionality? Does the functionality have fewer defects and meet needs of the business?

Arguably not all of these promised benefits are direct benefits of adopting agile.  However, all of these benefits are used to sell the cost of adopting agile. Therefore it is imperative that you be able to answer whether we have met the promises and goals set when committing to an agile transformation. Peter Drucker, the management pundit,  has been quoted as saying “The purpose of business is to create and keep a customer.” The impact of adopting agile in the business or technical components of the organization should have an impact on the purpose of the organization.  Most organizations adopt agile to improve their ability to deliver value and gain customers.  At the business level, these tactical goals that support Drucker’s more lofty goal are typically measured by reduced cost and/or increased profit.  Both are proxies for creating and keeping customers.  Evan Leybourn recently wrote that companies are not in the business of making money.  In a comment, someone pointed out that making profits was a requirement for maintaining the ability to create customers; therefore, it is a crucial part of a business’s survival equation.

The Agile Manifesto does not make any promises about performance or about how people will interact.  The Manifesto does describe values and principles that guide adoption and behavior in broad terms.  There are multiple paths for achieving the values and principles in the manifesto.  People almost always sell agile as more than a set of values and principles.  People sell agile to leaders with promises of faster, better, cheaper or otherwise improved functionality.  Given these promises it behooves all practitioners to be able to answer whether those promises were delivered with more than a shoulder shrug.


Next – Suggested Measures and Metrics

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