I’ve always believed in the transformative power of books—they alter our perspectives and enrich our understanding of the world. As an avid reader and unapologetic learn-o-holic, I recently delved into When Will It Be Done by Dan Vacanti, and it revolutionized my approach to process metrics. My previous musings on the topic, documented in a series of blog posts, were challenged by Vacanti’s insights, prompting a reevaluation of my methodologies.

The Fallacy of Averages

Vacanti’s work references “The Flaw of Averages” by Sam L. Savage, which elucidates the misleading nature of averages in statistical analysis. The book’s premise—that averages fail to account for outliers and distribution nuances—resonated deeply, highlighting the inadequacies of conventional metrics.

Consider these illuminating anecdotes:

“If Bill Gates walks into a bar, everyone in the bar is, on average, a millionaire.”

“Never cross a river that is, on average, 4 feet...

I’d like to start by acknowledging the remarkable individuals I encounter as a consultant—those brilliant, fun, and experienced professionals who seldom surface online or at conferences. Scott Hanselman aptly dubs them Dark Matter Developers, and they are the unsung heroes of the industry. This blog post was sparked by one such individual, Yngve, whom I had the pleasure of collaborating with at a client’s site.

At this client, where Yngve serves as an infrastructure architect, we faced a common challenge: measuring software quality. The teams felt overwhelmed by the perpetual neglect of technical debt, constantly being pushed to deliver new features without addressing underlying issues. We lacked a concise means of communicating this dilemma to our non-technical colleagues.

To address this, we devised a simple yet effective metric: the Marie Kondo-index for software quality.

The Complexity of Measuring Quality

Measuring software quality is notoriously complex, as eloquently discussed...

Friend: So in short - they too need to scale their agile initative.

Marcus: Oh - cool! Up or out?

Scaling agile has to be the term that I’ve seen most discussions, posts, comments and conversations about the last couple of years.

And Google seems to agree - it at is peak or going there right now.

But very seldom I’ve heard an explanation to what kind of scaling that is meant: do you want to scale up or scale out? My guess is that many times people talking about scaling agile mean scaling UP but worse I think that most times we have not decided. That is not really wise because it’s two very different problems to solve.

In this post, I wanted to reason a bit about those tradeoffs.

I have been involved in many organizational changes that turn the organization sideways. From functional departments to cross-functional teams, from projects and completing activities to continuous delivery and focus on reaching effects.

Just about always this creates some initial confusion around where decisions get made and how the old ways fit into the new. Quite often worry about chaos breaks out.

For example;

Who is in charge of the overarching architecture, now that each team is deciding everything by themselves?

I realize that I’ve done a bad job describing how this is going to work. The other week I found myself describing this with a pretty simple model that I wanted to share.

Disclaimer

I’m pretty sure this is not news at all and I’m making a pale copy of something brilliant. But … it’s my copy and I’m standing by it.

TL;DR

If you are...

I just had a conversation with a client that I keep coming back to. It has to do with how we are using electronic systems that manager our work, for example JIRA and TFS.

I needed something to refer back to and I hope that you can get something out of me writing this down.

Although I often preach about embracing uncertainty and sometimes get comments about always being calm… despite that; I worry. As do we all.

But sometimes, in rare moments of clarity, I have the opportunity to stop and reflect over the what I am worried about. It just about always brings me to the realization that I worry in vain.

Let me share three things in particular, that I have worried about lately. That gave me nothing but more worry.

UPDATE I have learned new stuff. There are a better ways. Find the update here

It’s time to wrap this series up. I have one final thing that I want to visualize: queue length. How much stuff is waiting and how long will that take us to complete? And maybe even, “if I add something in the queue now, how long before it’s done?”

1. Lead time
2. Lead time with filters
3. Throughput
4. Where time is spent
5. Single numbers - averages, median and max of lead time

As always my sheet is found here and you can make a copy of it and use it. Please let me know how it’s working out for you and if you end up doing something cooler than me.

Let’s do it - queue length!

I stumbled over a new concept the other day. As it was conceived by Kent Beck, that inspired and thought me a lot in the past, I got interesting.

[UPDATED]

I read Kents blog post a bit too fast and missed that this idea was actually proposed by Oddmund Strømmer. Very sorry that I missed that in my writeup, Oddmund. Thanks for correcting me, Raquel.

And after some even more research the origins seems to be traced back to a group of people that took a workshop with Kent Beck. Not only Oddmund Strømme but also Lars Barlindhaug and Ole Tjensvoll Johannessen. Those Norwegians… always a few steps ahead of me.

[BACK TO THE OLD TEXT]

When I read his blog post I got to this quote:

I hated the idea so I had to try it.

I felt the same actually and now...

UPDATE I have learned new stuff. There are a better ways. Find the update here

This post is all about just aggregating and averaging out to a single number… and then I can’t control myself but start to lay that number out over the individual weeks too.

That, and we will use the Gauge-chart for the first time in my life.

This is the fifth post in my series on some simple kanban board statistics. We have been talking about:

1. Lead time
2. Lead time with filters
3. Throughput
4. Where time is spent

This is the fourth post in my series on some simple kanban board statistics. We have been talking about:

• Lead time
• Lead time with filters
• Throughput

And this time it’s time to see if we can visualise a bit where time is spent. For this first post, we will make some basic classifications of active and not active or not “on the board” and “on the board”.

In the coming posts I want to expand on this and see if we can make a distinction between other states on the board as well, but for that, we need to expand the data in “Raw data”, because that data only contains completed items right now.

Ok - let’s get going. As for all these post I am in this Google Sheet - make a copy if you want to play along