Pace the inputs and reduce their transaction costs
The coordination of the prioritisation of the tasks in a project may involve many parties: the development team, which is obvious in our case, but also sales, marketing, finance, external partners and so on.
Everyone is competing to get the developers’ time allocated to their own (part of the) project.
Having a process where decisions are made during the meetings, where each department is represented, can be a huge cost, in terms of time as well as money: the more numerous the parties are, the longer the meetings take and the harder it is to make decisions. Let’s also keep in mind that such long and too often unproductive meetings can generate a huge frustration of everyone involved.
Have shorter and more frequent meetings
A quite simple step to reduce the costs of those meetings is to strictly limit their length and make them happen on a regular basis. Depending on the size of the development team, 15 minutes to an hour once a week may be sufficient.
The time the meeting used to last does not magically disappear, it is now transferred to each party, which will have to prepare their argument in advance to be more concise and efficient during the discussions. The fact that these meetings happen in an established frequency, leave it up to the participants to plan when they will do their preparations.
A regular and relatively short pace of the meeting will also let the participants involved be more up-to-date with the progress the project is making, starting a more transparent relation between the development team and the others.
One may have trouble guessing what the most appropriate frequency for their meetings should be.
The rule of thumb is to have one as often as possible, as long as it makes sense. This will reduce the number of spots that have to be allocated during the meetings and reinforce the communication within the project. This new transparency might strengthen the relationship between the parties and the trust towards the development team. Although the releases are not paced to the meeting, this should contribute to a shorter feedback loop and cycle time, leading to a lesser amount of WIP.
One thing that can help the meetings to be more efficient is to make the participants aware of what is going to be discussed at the upcoming one: the blockers that need to be solved, the tasks that are worked on, the amount of free spots there will be.
This short overview will help everybody prepare the meeting, pick out the tasks they see as important for the forthcoming weeks and their arguments. We might see participants communicating with each other before the meeting and working together towards their goal.
Nonetheless, an attention should be paid to the cost of those preparations; it wouldn’t make much sense if they happened to be costlier than the ones in the previous system.
Een theologisch debat – Eduard Frankfort
Within that, one can also open a reflection on the usefulness of time/cost estimations for all the tasks. Costs estimations are a client’s favourites and often a developer’s dilemma. It is not hard to understand that people who wait for the developers to accomplish a task might want to know how long this one will take and how much it will cost.
Nevertheless, it is important to have a deliberation on which kind of task deserves an estimation and how precise that estimation should be.
It costs time for developers to accomplish a meaningful estimation and the return on this investment is usually very poor.
If you can skip the meeting, skip it
At last, the role and sense of the prioritisation meeting itself must be weighed. With a team mature enough, which has the trust of its partners, the project manager could create a set of rules defining how prioritisation should be set.
Once they possess that, they can do the prioritisation on their own whenever they want to. For that, on the one hand they need to receive the task from the partners and on the other wait for a free developer spot.
The meetings at this point only need to occur when there is a need for it. It is to be underlined here that this configuration has much more chance to work when the developers have already gained their partner’s trust and when the collaboration between the parties has existed long enough so that everybody can put their faith in this system.
This solution will reduce the communication between the parties which can quickly weaken the relations if they are not strong enough at the beginning.
In this example, Kanban showed us once again that it is always best to act gradually, while following logical steps.
You need to start with a strong foundation, make it more efficient while strengthening it and repeat that again and again. What is important, is that none of the steps endangers the process.
They should be small, careful and firm. This allows projects to grow into a direction where developers, project managers and partners can get the best out of it.