One of the fundamental values of the Agile philosophy is transparency. However, it often proves to be a double edged sword. Misused, it can create the opposite of the expected effect.
When I coach teams who are using an Agile methodology, like Scrum for example, velocity is often used as transparent information and broadcasted to stakeholders. Don’t forget that velocity as an indicator aims at helping the team and the Product Owner plan the next iteration according to the measurements of the last three or four sprints; regardless of the scale used, such as t-shirt sizes or story points following the Fibonacci sequence. Out of reflex or habit, the organization’s stakeholders can start pressuring teams using this value.
The boomerang effect of transparency occurs at that time. In difficult times, we go back to “non-confidence”, we use the team’s vulnerability to demand accountability. Under stress, the organization will want to put pressure and might have a short-term result, but very quickly after, the team’s productivity will drop. From experience, it doesn’t last much longer than four weeks.
Why? Readers who are familiar with Patrick Lencioni’s five dysfunctions of a team will anticipate my answer. Teams are going to start inflating estimates as in the days of the V-Model project abacuses. In the short term, stakeholders see an increase in velocity, but we quickly realize that it’s a fool’s game. The business value for our clients and users isn’t increasing! Worse, we feel like the software products are becoming unstable. The technical debt skyrockets and the production teams’ motivation plummets.
It’s because without trust, without deeper curiosity about what teams are going through, without the stakeholders’ support, we lose adults’ engagement, who therefore go back to being children.
Infantilization of the workplace is then at the door of our organization. In the teams, there is an impression of always having to justify everything. For the management, the next risk is a turnover increase, and then the different actors in the field need to be replaced. This comes at a high cost: loss of time for interviewing candidates, loss of business and technical knowledge, etc.
I am barely exaggerating; I saw it on the field in so many places at my clients’ and listening to my friend’s stories in their different contexts. Hence the idea of improving the production teams’ communications. But when we want a situation to change, it is important to start with ourselves. The team will need to have the necessary intention and motivation to undo the black box effect, the exterior perception.
I have been in computer science during fifteen years or my professional life. My first battle as Scrum Master, more than 7 years ago, was to deconstruct the negative image of lacking rigor that engineers sometimes have. We were often treated like kids, down the hall, and it was important not to make us interact with customers and users.
In my opinion, one of the first things to implement is board of what I call “extras”. That is to say that at the beginning of the iteration, we plan a certain number of items according to our capacity and the average velocity of the last sprints.
I wrote more about this in this article on Enjoy Agile (in French). As soon as we are done with the planning rituals (Day 1 of the iteration), and we have sent our message to the rest of the business summarizing what we think we will accomplish during the iteration, we can add to this board.
But what are we putting or not on this notorious board?
Here is a non-exhaustive list of what can be found on it:
- Urgent and untimely code corrections in production.
- An unplanned company event (example: an emergency speech from the boss.)
- A request to create a presentation for a potential client or investor.
- A presale with a potential client.
- A feasibility study of a feature for a client ready to sign if it’s implemented quickly.
- A training workshop or seminar. It has value for the company, but we are not coding features in the meantime.
Examples of what we should not find on the board:
- The usual and paced team events, such as in Scrum, the Daily, the sprint review, the retrospective, etc.
- Any technical work mentioned during planning
- A company party, a leave, a public holiday we were unaware of during planning.
- “I helped a friend solve a problem,” mmm… it’s the normal life of solidary and agile team!
For all the management team, this board enables the detection of the invisible work in their “factory.” I took this term from reading The Phoenix Project book which I recommend to all. It’s not because we are not aware of something that it doesn’t exists. Therefore, as a production team, let’s be professional and show with transparency everything that is going on in our team. It’s a great way to make the work we do more accessible, and in a way, to depict the complexity we face to the stakeholders.
My first win when setting up such a board for a client has been raising awareness about the level of interruptions experienced by the technical team. Steps have been taken to improve the focus and mental flow of engineers. The productivity of the software publisher skyrocketed. Today, they frequently raise millions and are still growing.
So sing “C’est Extra”, and communicate to the max, well used transparency is relaxing! Enjoy!