Reducing waste by making your goals visible

Metrics are good, but they’re not enough. If you want metrics to drive change, they need to be visible. Not just to managers, but to the team. The right metrics, visible to the team, drive improvement. Visible only to management, drive control. Visible to no-one, drive nothing.

Good metrics need to be communicated clearly and persistently. There needs to be a continual focus on whatever the priorities are. If it’s out of sight, it will be out of mind. If it’s digital, rescue it from individual screens that are easily covered up.

It’s why kanban boards can be so effective when used well. It’s easy to see when the team is taking on too much work, or where there’s a queue waiting for tasks to be pulled. The board radiates information to the team, about how much work is in progress, and who is working on what. It becomes the centre of communication about tasks and removing waste. Make it physical, if you like, and the team is co-located. Use Post-its. Let dog ears and grubbiness indicate age. Do your backlog pruning via environmental effects – older & more used notes are more likely to fail behind the radiator and get lost.

Put (work-related) personal tasks on there too. Keep yourself honest. It’s good for the team to know you’re reviewing CVs, or preparing for that strategy meeting, or learning Haskell the hard way.

But keep it clear. Use a Kanban if WIP or queueing are your key metrics. Use Scrum if velocity and deadlines are key. Use a dashboard if that makes your priorities and progress clearer.

And make sure your key priorities (4 or less please) are visible at a glance for the team, and easy for anyone in the team to explain to a passerby. They don’t need detail, but pointing to a big pile of waiting tasks to justify recruiting a new tester is a clear message.

beta code google programming test

DOOR Oasis Office Reporting

I’ve been hinting in my status in various places (twitter, facebook, etc..) that’s I’ve been playing about with an idea to do some database/web service reporting using the ODF format, powered by a bit of XSLT. The grand idea is that ODF editors are easier to use and to get hold of than the existing reporting frameworks, ODF is reasonably easy to edit by hand if things go horribly wrong (or you need to change a server name), and, as an XML format, I can use my data to change anything in the output, content, styling, could even generate different letters for US and EU customers by selecting paper size based on country. It’s still very much in the requirements capture stage at the moment, but if it sounds like something you’d be interested in, hit the link below and have a nose around. There’s a discussion group too, which I might have to tweak if things get popular, so pop on over and give me your thoughts.

door-reports – Google Code

Blogged with the Flock Browser