A daily status meeting? Really? Now you want daily performance measures? Really?

I run agile training courses and I often preach the benefit of a daily standup.  The idea is that it is 15 minutes a day where everyone in the team lists

• What they have done since last time
• What they will do today
• What obstacle or issue is in their way

It works really well in my slides but now I am trapped in the real world temporarilly working on a real project. Do I really want a daily meeting?

I actually do really benefit from the daily meeting, especially when I compare what we say we are doing to a physical story wall.

Lately though, I have been on multiple projects, all of which have a standup.  I have also asked my own team to do a stand up.  So now one of my obstacles is “I am in too many meetings about my obstacles”.

The simple solution we have implemented is that nobody can be in more than two standups a day. It seemed impossible because we are doing so much. But then we realised we were actually commiting to so much, not necessarilly doing it all.

Nobody believes me in my training courses, but if you are on 10 projects you really do have to stop being spread so thinly. People often thing there is no choice but to remain too thinly spread. But even if you get thrown off the projects for complaining and people tell you off, this is better than being left on 10 projects and then having people complain that you are not delivering.

So I was happy again.  But I had no idea that outside of agile projects some guy published a book on “Mastering the Rockerfeller Habits“. Based on this the team I am working with have:

• A daily meeting to keep up on things.  The agenda should be short and sweet and should cover
• What 3 things you will do today
• The “rock” or obstacle in your way
• Your daily measure or “Key Performance Indicator (KPI)
• A weekly meeting to confirm progress, communicate across the team and commit to the next week.

It all sounded very agile even though I assume Rockerfeller never used the term “agile”. 

I particularly like the limit of three things you will do today, because it forces you to prioritise and to be brief in your update. But then I stopped to think about it – why would I provide a KPI every day?  And what happened to the “This is what I actually got done yesterday”.

So we now have a story wall for one team (we are colocated) and make sure we put our daily commitments up on the wall – so we see if they have been done.  For the other team we have to remind each other what we missed or achieved.

But good grief – who wants a daily KPI?  It turns out that it sucks quite badly for multiple reasons. 

• Rather than just reporting tasks completed or stories delivered, we have to measure the quality of our work every day. It turns out it is a lot easier to talk about stuff you did than about the value you added or the quality of what you did.
• You need to find out what the core focus of your role is and quantify it.  Then you need to explain your focus to the rest of the team.
• You need to constantly come back and focus on your measure.
• Even simple measures lead to challenging questions when they are inconsistent (or too consistent) or unexpected.

Of course these are also good reasons for doing it.

My initial measures were a bit lame, but now I think I will change one of mine to the following

• Percentage of time spent adding new value to the business (new stories for developers, something hard for managers)
• Percentage of time spent “consolidating or protecting existing value”.  This would include fixing defects (because you are repairing the system to what it should be doing already), maybe monitoring the system and maybe refactoring to simplify what the system is already doing
• Percentage of time spent doing other stuff (writing on my blog, going to meetings which have no defined value nor good muffins, writing reports for people, etc).

Since we don’t have time sheets here (yay) I will have to guess what the percentages are every day. But then I would probably have to be able to justify the rating I give and that seems really hard.

Maybe I should tell them that agile projects don’t measure KPIs. We measure activity rather than quality. 

In fact many projects measure activity instead of progress (story points complete but not problem solved or new capability delivered).

Then again – maybe my agile projects should be providing some kind of measure of daily contribution to the business rather than daily activity.

What would happen if our agile projects were expected to do that in the same way the team I am working with have been asked to?