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

SPaMCAST 544 features our interview with Jeppe Hedaa.  Mr. Hedaa and I discuss his new book, Nucleon: The Missing Formula That Measures Your IT Development Team’s Performance. Our discussion centers on the book but also touches on meritocracy and why you want top performers on a team. This is a wide-ranging interview with thought-provoking ideas as we talk about Nucleon!

Jeppe’s bio:

Jeppe Hedaa has been working with complex systems development for more than 30 years, serving the largest IT development departments. He is the CEO and owner of 7N, who is an agent for top 3% IT specialists. 7N has departments in the US, Switzerland, Finland, Sweden, Norway, Poland, India and Denmark. In September 2018 he published the book “Nucleon: The missing formula that measures your IT department’s performance”, where he describes how to calculate a hard number for an IT team’s performance that could best be compared to that of horsepower in a car. In the book, he also measures the factors that hold back an organization’s delivery and identifies the most impactful areas for improvement.

Our review of Nucleon: http://bit.ly/2XQvB9T (more…)

Nucleon by Jeppe Hedaa is a short and concise book that is rich in thought-provoking ideas. To give you a sense of scope, the subtitle, “The Missing Formula That Measures Your IT Development Team’s Performance” speaks volumes. The book weighs in at 119 pages with front matter (always read the front matter), six chapters and eight pages of endnotes. I will admit that I am a sucker for grand unifying theories. I am still rooting for Stephen Hawking to posthumously pull a rabbit out of the hat (I sure hope someone is looking through Hawking’s personal papers). Mr. Hedaa, founder and CEO of 7N, developed the theory that team effectivity is a function of the sum of each person’s effectivity (the ability to be effective). Effectivity is a function of people, organizational, and complexity factors. Arguably the idea that people, organizational, and complexity factors influence effectivity is not controversial.  But, these factors can be consistently measured and then used in a deterministic manner to predict performance is controversial. Mr. Hedaa spends the six chapters of the book developing a logical argument based on experience and data for the premise that there are ways to measure the factors that matter and that knowing the answer matters to leaders that want to get the maximum value from the money they spend on software development (the broad definition that includes development, enhancement, and maintenance). The Nucleon formula is: (more…)

On a scale of fist to five, I’m at a ten.

(This is lightly re-edited version of a post from 2016 — I have been on planes for two days going hither and yon, therefore, we are revisiting quality.)

Quality is partly about the number of defects delivered in a piece of software and partly about how the stakeholders and customers experience the software.  Experience is typically measured as customer satisfaction. Customer satisfaction is a measure of how products and services supplied by a company meet or surpass customer expectations. Customer satisfaction is impacted by all three aspects of software quality: functional (what the software does), structural (whether the software meets standards) and process (how the code was built). (more…)

The kingfisher was about this far away!

Each mapping layer, value chains, value streams, and process maps serve related but different purposes. As an organization drills down from a value chain to a process map different measures and metrics are exposed. One could summarize value chain metrics as high-level cost, revenue and speed while process mapping as variations on effort, delay, and work-in-process. Each metric set is highly related but targeted at different levels of the organization.

Value Chain Metrics Pallet (more…)

5255124016_1229905b61_b

**Reprint**

Productivity is a classic economic metric that measures the process of creating goods and services.  Productivity is the ratio of the amount of output from a team or organization per unit of input. Conceptually productivity is a simple metric. In order to calculate the metric, you would simply sum up the number of units of item produced and divide it by the amount “stuff” needed to make those units.  For example, if a drain cleaning organization of three people cleans 50 drains per month, their labor productivity per month would be 50/3 = 16.6 drains per person. The metric is a sign of how efficiently a team or organization has organized and managed the piece of work being measured. There are four types of productivity.  Each type of productivity focuses on a different part of the supply chain needed to deliver a product or a service.  The four types are: (more…)

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