Cumulative Flow - Part 1

I use Cumulative Flow Diagrams for spotting problems and as a communication tool for discussions with the team. I’m using Google Sheets to keep track of how many cards are in each column of our Kanban board. Every morning I have a coffee and add a row for the day before.

Cumulative Flow - Part 2

In Google Sheets, the CFD is a “stacked area chart”. A CFD based on real team data is crazy looking compared to most examples you see, which are usually simplified views of very stable systems. A real CFD shows the peculiar conditions of the team. I value that more than the throughput, cycle time and lead time metrics although these are important metrics that can have real value for the team.


At the LAST conference in Sydney a couple of months ago, the keynote speaker was Henry Mitzberg. When he said “efficiency is the enemy of effectiveness”, I was shocked - mostly at myself for not questioning the idea of “efficiency” before.

Story Points

Before asking for any kind of size or complexity estimate, I ask “is this card ready?” and “is it as small as it can be…yet?”. If we agree that the card was ready and that it is as small as it can be, I suggest moving on to another card.


I’ve been looking for a silver bullet that will make this “resourcing” strategy somehow less terrible for trying to be agile but… there isn’t one. Whichever way you slice it, making people less than 100% on the team creates dysfunction.

It makes scheduling team collaboration opportunities difficult. It also means that people on more than one team spend more of their time with agile meetings than they should (think two or three lots of sprint reviews, planning meetings, retros…) - or they skip meetings because they have to. Perhaps most insidiously, it means that people are probably 100% ‘utilised’, at least. We know what happens to lead time as untilisation approaches 100%, right? It increases exponentially. So, basically, it’s a nightmare.

Are We Agile?

Sometimes I wonder if an organisation I’m working with is agile. There a moments of inspiring agility… and then something happens that’s really NOT agile. These obstacles of resistance, well meaning misunderstanding or just plain fear of change sometimes pile up on the “not agile” side of the scale and I think about whether there was some point in the past when I should have said “if you’re not willing to try this thing, or accept this thing, then we should stop trying to be agile for a while - call me when you change your mind”.

The 5 Stages of a Remote Retrospective

I’ve never been very confident trying new things for the first time in a retrospective meeting. I recently, and very belatedly, read Agile Retrospectives by Diana Larsen and Esther Derby and realised the importance of really covering the five stages they recommend. It gives the retro a solid structure and makes me more confident about trying new approaches within the structure.

At the moment I’m working with remote teams. We do retrospectives over HangOuts using https://realtimeboard.com/. The results are sometimes frustrating, often hilarious and always worthwhile.

Software products and services need a business goal. We also need to know who the product is for, the problems it solves for them and why it’s better than the alternative. This is the sort of value proposition statement we need to articulate so that we can make good decisions during the long and complex process of making software:

FOR <target customer>
WHO <statement of need>
THE PRODUCT IS A <product category>
THAT <key benefit, compelling reason to buy>
UNLIKE <key competition>
THE PRODUCT <compelling statement of differentiation>