Alternatives!

Three possible alternatives:

IFPUG function points. If you have to have a standards-based approach to sizing and comparison. IFPUG function points are the gold standard. IFPUG function points are an ISO standard and can be applied to all software types (technology agnostic). The drawbacks for using function points include the perceptions that there is a high level of overhead, counting requires too much information too early in the processes and that only highly skilled wizards can count (or approximate) function points correctly. None of these perceptions are really true, however, in some circles, the tar and feathering has stuck. (more…)

How did we get to this point!

Story points were originally developed as a metaphor to give a rough answer to the question of how much functionality could be delivered in a specific period of time.  The problem is that all good metaphors are eventually abused or, worse, people forget that the metaphor is a simplification and approximation of real life. Metaphors become reality.   Three basic behaviors of leaders and stakeholders in software development (broad definition) have lead the metaphor of story points to evolve into story points as measures — something they FAIL miserably at. (more…)

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

SPaMCAST 520 features our interview with Doc Norton. We talked about his new book Escape Velocity, measurement, and why velocity isn’t generally a good measure for teams. By the time teams get to a point where story point velocity is consistent and predictable, they will have better tools that have fewer negative side effects.

Doc’s Bio

Doc Norton is passionate about working with teams to improve delivery and building great organizations. Once a dedicated code slinger, Doc has turned his energy toward helping teams, departments, and companies work better together in the pursuit of better software. Working with a wide range of companies such as Groupon, Nationwide Insurance, Belly, and JaTango, Doc has applied tenants of agile, lean, systems thinking, and servant leadership to develop highly effective cultures and drastically improve their ability to deliver valuable software and products.

A Pluralsight Author, Clean Coders contributor, frequent blogger, international keynote speaker and coach, in his spare time, Doc has been working on his latest book, Escape Velocity: Better Metrics for Agile Teams. You can find his book on LeanPub at www.leanpub.com/EscapeVelocity

Twitter: @DocOnDev

Web: http://docondev.com/

Can you help keep the podcast growing? Here are some ideas:

  1. Tell a friend about the cast.
  2. Tweet or post about the cast.  Every mention helps.
  3. Review the podcast wherever you get the cast.
  4. Pitch a column to me. You are cool enough to be listening; you deserve to be heard.
  5. Sponsor an episode (text or call me to talk about the idea).
  6. Listen.

Whether you do one or all six, being here is a big deal to me. Thank you!


Re-Read Saturday News
This week we continue on our journey through Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along!) Today we tackle a single chapter.  Chapter 6, titled Sunny, introduces Ramesh “Sunny” Balwani to the story. Sunny, Holmes’ live-in boyfriend (the stress on the live-in part is to shine a light on just how close Holmes was to Sunny), adds another layer of toxicity to the Theranos story. The toxicity feels extraordinary but is not that uncommon when teams break down.  

Current Entry:

Week 5 — Sunnyhttps://bit.ly/2AZ5tRq (more…)

Pareto chart of Pokemon

Got to catch them all!

A Pareto analysis is based on the principle suggested by Joseph Juran (and named after Vilfredo Pareto) that 80% of the problems/issues are produced by 20% of the issues. This is the famous 80/20 rule, and this principle is sometimes summarized as the vital few versus the trivial many. Process improvement professionals use the Pareto principle to focus limited resources (time and money) on a limited number of items that produce the biggest benefit. (more…)

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