In this series of posts, I will present anti-patterns encountered during my missions of team agilization. What is an anti-pattern? It’s something that at first seems like a good idea, but at the and is a bad idea.
The first anti-pattern that I’m going to discuss today is the content of the board.
During the Daily Stand-up, I see somebody outside the dev team add tickets on the board, at the location that suits him. It happens typically when the Project Manager (and yes, our team still has a Project Manager, but that’s another topic for an article :) ) feels that a very important topic is not on the board. Following the principles of “traditional management” according to which the Project Manager is in a logic of micro-management and continuous control, he explains to the team how they should be organized. Therefore, he thinks his job is to add a ticket on the board at the location he decided before forgetting and because maybe he thinks the team will forget to deal with this topic if he does nothing. This may seem like a good idea. But …
What you’re looking for in an Agile team is that the team self-organizes. Not easy when setting up the Agile, in most of organizations, decisions are made top-down: the Project Manager - just like the management - makes the decisions and imposes them on the team. It certainly does not encourage the team to take initiatives, nor to self-organize. Doing yourself only keeps this situation that you want to change.
So, concretely, several times, I had to withdraw a ticket which is added by the Project Manager for example (which cannot - in theory - talk during the Daily Stand-up since he is not in the Dev Team) instead to ask the team how they want to manage this topic: adding a ticket in a stream, add it to the list of blocking points, create a special ticket flow for this kind of topic, launch a discussion after the Daily Stand-up to dig up the subject, confirm that it is a hot topic, etc … I’m here just to make sure that the team has taken over the subject and that they self-organize to treat it.
Micro-management prevents the team from self-organizing. Of course, the Project Manager and the management will be able to answer that they lack confidence. But it is a relationship that is built over time. The Scrum Master is there to make sure the team self-organizes. And if sometimes the way the team self-organizes leads to a non-processing of the subject, the Scrum Master is there to help the team to become aware of this problem and to encourage they to find a solution. In the end, the Project Manager and the management will be able to use their time and spend their energy on other topics that generate more value. The team will be grateful that they will no longer feel they are being monitored, that they will be infantilized and will often be able to find more relevant solutions than those imagined by the Project Manager or the management.
I encountered this type of problem during the implementation of Agile in teams that were working in Waterfall or that had several times tried to become Agile without success and in a context of traditional management that does not help itself to become Agile. This partly explains the fact that there is always a Project Manager, to make schedules, traditional reporting and manage resources. Unfortunately, it is also him who is congratulated if the project respect the deadlines or it is him who is reprimanded if there are delays. But that could be the subject of another article. :)