Prodcutivity: should I really care?
I think the response is yes. Most companies work around dates and this is simply due to the fact that when a company buy something to another, it wants to know when it will receive it. It doesn’t really like hearing that it will receive it when it is ready like Agile people like to answer. This kind of response is more or less like having your cable company telling you that someone will go to your home between Monday and Friday at commercial hour and you will need to be there. You won’t accept that because you won’t be able to organize yourself in order to get things done while waiting for the technicien. Consequently you need predictability. One way of getting that is measuring the time it takes to get a peace of software done. In other words, measuring productivity.
Way work get splitted and its impacts
When you work with management it is very common to see work load spreads as one user story per developer. This is a nice field for the creation of cowboy developers . Even though it doesn’t prevent developer to work together and help each other, it doesn’t incentive them to do so neither. The productivity math usually comes down to looking at each team mate productivity and sum it. I don’t think this the right way to go.
The system should force the team mates to work together. The way Kanban deals with it is by have Work In Progress limit (WIP Limit). IMHO you hould have less user stories being developed than your number of developers. Doing so, there is no way people compare developer’s productivity. The only remaining measure is the team productivity. In order to increase this number your best developers will have to spend more time helping the team to produce than developing user story themselves. You cannot measure the individual productivity anymore, so you can only consider the team and help it to get more productive. The fact that some user story will be done by more than one person should incentive developers to share ideas, teach each other and deliver a better solution.
Some draw back of WIP Limit
When developers start spending more time on helping than doing, they usually have a hard time. This comes from two main factors:
- Your best developers will have to deal with a lot more interruption.
- At the end of the day, people who spend more time helping won’t have ended or made any significant progress to any specific user story. It can creates the impression of not getting things done. This is common when people start practicing as the pass from a model where they were used to get user story done to a model where they get “help/teach” done.
They are several technics to deal with it:
- The simplest your best developers don’t have any user story assigned to them
- Set the WIP Limit to 1: everybody works on the same user story and help each other.
- They uses technics like Pomodoro to manage interruptions.
- They time-box the time they spend on their user story and spend the rest of the day helping.
Adopting those technics should help to increase the productivity of your team, deliver with higher quality. As people share more and more ideas, the level of your team should increase.