I have a confession to make; i think i’m turning into a data-guy. No, not a computer-guy - I’ve been that a long time. Rather it’s that boring dude that keep asking for numbers, measurements and saying “yes, but how do you KNOW that” all the time. But I’m on a program to recovery from some of the boredom-parts. It’s called Simplicity and Visualisation.
To be a little more serious I think that collecting data and then do small experiments based upon them rather than you feelings is the way to make controlled, continuous improvements. This is all very Toyota Kata (or rather Kanban Kata or even the scientific method) like but that’s exactly where I’m aiming.
- Establish a target condition or goal
- Make sure you really know where you stand today. Gather data to be sure
- Take small experimental steps towards the goal
- Measure and evaluate against your goal based on the numbers
In this post I’ll show you how we did a small data gathering that didn’t feel like data gathering at all.
Why not feel like data gathering?
Every time I have introduced the idea of start measuring how we’re doing in lead time, throughput or whatever have you - the first reaction is always a shudder. “No!? Why? We don’t need to show that. We know how we’re doing, right?”
This probably only show what most of us has been subjected to before; measurements to be followed by up others, to compare or even affect our salary.
So, let me just make one thing clear here - that’s not what i’m talking about here. I want the TEAM to collect data about the TEAMs performance to let the TEAM improve upon it as they see possible and fit. (Keyword in the pervious sentence was TEAM, if you missed it). It’s an internal thing.
One easy way to accomplish that, and get many concerns from the team out of the way, is to let the team pick the scale or figures themselves. Like story points for example - it’s a relative measurement that cannot be used to compare teams. One team says that a certain task is 8 story points, another calls the same task Large. Or 5 points. Or whatever.
For the case of this blog post, we went even simpler…
The problem - where do we spend our time
I’m coaching a team right now (amazing engineers - best I’ve worked with) that are the firefighters of the company. Anything goes wrong in any backend related stuff - you call them. And they deliver. So you could say that they are paying off technical debt for the company.
But they want to move away from firefighting, reactive work and move towards proactive work instead. Who can blame them? So they started to. And they feel like there on the move to doing more Proactive work. Maybe 60% reactive work now.
See right there? That’s what I mean; But who do we KNOW that guys? Let’s gather some data.
The solution - simple and lightweight
This team is really working me hard. Every suggestion I come up with is met with healthy amounts of scepsis and their asking me for good motivations all the time. Thanks team.
So we agreed that we wanted something really lightweight but also really enough that it gave us real data to work from. We devised two visualizations that helped us with this:
Firstly all the stickies on the board are just in 2 colors; Reactive work and other work.