September 27, 2011
– It’s 42 boss.
– Yes boss, that’s higher than the 5 bugs we had a couple of sprints back.
– No boss, that was the sprint when we spent the majority of the effort implementing the configurable splash screen and the easter egg TicTacToe-game. The features that you predicted would triple our sales.
– Yes boss, it is also lower than the 50 bugs we had last sprint.
– Yes boss, last sprint. You know, the one when you hade us work overtime every second day in order to fulfill our customer’s demands of removing the configurable splash screen and the easter egg TicTacToe-game. Remember how they said that the features lowered the productivity for their employees?
– No boss, it’s still 42 this sprint. However, we’re only on week three of our two week sprint that you’ve prolonged to four weeks in order to fit some extra functionality in. So I guess the number might still go up.
– Boss, I think I’m actually beginning to see the value in counting bugs. These numbers seem to have a strong correlation to the decisions you’ve made. We can probably learn a lot from them.
– What the hell was it you wanted to know boss?
There’s an old saying that a lazy programmer is a good programmer. I’ve never heard an old saying about a lazy manager being a good manager but yet there are all too many of them out there. Not the good kind of lazy manager who is willing to delegate work and to let people do what they’re good at without micromanagement. No, we get the other kind of lazy manager – the Panacea Manager – who is constantly looking for a shortcut.
The Panacea Manager will measure the organization on what he can count on his fingers and toes because words bore him, unless of course they’re his own. The Panacea Manager will ask for bug count, lines of code, number of test cases etc.
What do you think the Panacea Manager will receive when asking for these numbers?
Is it hard for a developer to produce a lot of code if that is what she is being measured on?
Is it hard for a tester to produce a lot of test cases if that is what he is being measured on?
Will the number of bugs found tell you anything about the quality of the software after they’ve been corrected?
Do our customers care about the bug count or LOC or number of test cases? I don’t think so. Bug count and most other numbers that we collect are just proxy variables for quality as we think our customers perceive it. Measuring quality and productivity via proxy variables might very well result in quite the opposite of what we’re trying to achieve.
How about if the Panacea Manager took a long look at the system he has built or inherited and started making deliberate decisions based on how he actually wanted the system to work? What if he stopped measuring bug count and lines of code and began asking the customers for what really matters to them? Would it make his job harder if he tried to compare customer satisfaction over time instead of employee hours spent in the work place? It probably would to some degree but it would also mean that he actually began doing his job.
So what should we measure then? I’ve learnt that many people itch to ask that question after listening to my arguments. Please don’t! That means I’ve failed at getting my point across and I’ll loose even more hair on my head. Begin with asking yourself; what decision do I want to make and what do I need to know in order to make that a good decision? THAT is what you should measure.
September 15, 2011
As a leader – or team member as well for that matter, you are faced with a big problem every time you try to implement some sort of a change in your organization.
No, that’s not true. You face a lot of big problems, but one of the bigger ones is … you.
You are trying to interfere with a system without being able to see the entire system. You need to get a helicopter view of the landscape while at the same time being grounded as an important part of the very same landscape.
Most of us don’t understand how much we affect a system that we are a part of, and more importantly; we don’t understand in what ways we affect that system.
Our presence in a meeting can set the entire tone of it without us doing anything in particular. Likewise, we can also affect the outcome of a meeting just by being absent from it.
How do we interact with our systems? What messages do we send to them? Do you have a total coherence between your thoughts, your words and your actions? If not, what parts of your intentions and your communication are getting across? Vice versa; what parts of your coworkers’ true intentions get across to you.
How can we possibly know how a system will react to a particular change if we can’t see the entire system?
Being a lean/agile coach, I’d like to suggest that you get yourself a new set of eyes and ears. As a leader or team member, it’s your duty to be a part of the landscape. You must be the intricate part of the machinery that you are. I, as a coach on the other hand can reserve the right to stay outside your particular system. I can put my stethoscope to the heart of your organization and listen without the distorting filters of preconceptions and interfering echoes of my own actions.
(… at least for a while. Sooner or later we all get biased.)
There are also tools like the left hand column exercise and Virginia Satir’s interaction model that can help us learn to see how our own behaviors affect those around us. If we accept the help and take the time to study ourselves, we can begin to move out of our own blind spots and get our helicopters in the air.