This post is the continuation of “Save your neighbor” in which I promised to provide hints and examples to inspire you in finding your way of managing skills and working in silos. So where do we start? How can we save the neighbor? Well, it’s both simple and complex. You have to recognize the reality and make it evolve towards the goal.
Recognize the reality—Do you really know yourself? Do you truly know your team? Of course, you know their roles and position in the organizational chart, but do you really know their past experiences, their wishes, their hidden skills? Can you describe situations and conditions that make them have a truly enjoyable day at work? Do you know what motivates them? Recognizing the reality goes way beyond one’s skill set. Start by mapping them. Do not focus on what an individual normally does, but also recognize what a person can do, would like to do again or would like to try. A programmer yearns to become a functional architect? An organic architect may have started his or her career as an IT security analyst? A business analyst may have been promoted to the marketing department given his extensive product knowledge he acquired while in charge of the Quality Control department? Mapping the team’s skills is recognizing its capacity, embracing its diversity. Having a better understanding of the “human at work” allows you to guide the individuals and the team using a path they have created for themselves.
Planning—The skill set ratio evolves over the course of the project. In the early stages of a project, we normally see more background work being done. Completing the first few user stories and functionalities normally require more background work than the last ones. Estimation and task complexity are generally higher at the beginning than when the team has reached its cruising speed. The team faces the challenge of an emerging architecture. Then, ratios stabilize themselves but vary again as the project comes to an end (less architecture required). A team with a well-mapped skill set has all the elements to identify skills deficits and react quickly. Few teams go even further and estimate the per-skill work required using, as an example, Planning Poker®. Other estimates using the SML scale (small, medium and large). It all depends on the teammates’ diversity of competence, the culture of the organization and the willingness and ability to help one another. It then becomes crucial not to fall into the trap of maintaining and confirming work silos, but to recognize the reality and make it evolve.
During the sprint—Time goes by, it’s a fact. The actual number of hours decreases each day of the sprint. It is therefore very easy to graphically illustrate the passing of time. Each day, the capacity decreases by 7 or 8 hours, less if we assume a non-productivity percentage. This is capacity. It becomes very interesting to compare the capacity per skill set on the work remaining per skill set with a slightly modified sprint burndown chart.
The work remaining is variable. It depends on the work left to do and on tasks to perform. Displaying the difference between the capacity and work remaining provides a quick answer to the question “Are there enough hours left into the sprint so I (we) can complete my (the) work remaining?” The team wants to work at a sustainable pace and does not want to work overtime. The team wants to close as many user stories as possible in order to create velocity and, most importantly, to deliver as much value as possible—each and every sprint. The team wants to make things visible to help it achieve these goals. If a team lacks capacity, it can more easily prioritize and focus work on the most important issues.
This chart highlights silos within a team. In this example, architects can code and are grouped with programmers in the “development” silo. In this example, other silos consist of database, testing and documentation. Regarding this team, the needs in architecture are well satisfied, they are more than adequately covered, and definitely not an issue. If it had been an issue, there would have been an “architecture” silo on the chart.
This chart very accurately highlights the under-capacity (too much left to do for the remaining time) or over-capacity (lots of free time) at the end of each day of the sprint, for all silos. It allows more detailed analysis and makes business risks and implementation challenges visible. It allows the team to question itself in real time and migrate from the “are you sure I cannot help you?” attitude towards the “how can I help? we are not going to make it” approach. Other teams prefer to use a Kanban task board on the wall with color-coded post-its to represent trades and silos. That has found satisfaction on a very visual yet macroscopic approach. Maybe this team is more multi-skilled than another? Maybe the team members have a better understanding of the concept of team? Is it perfect? Maybe not, but what matters the most is that the team has found it is good enough. The teammates are satisfied with this approach and find it efficient.
And this is what it’s all about. Find your way. Be imaginative. Experiment and adapt. Trust the team and trust yourself. Ask for help if needed. Whichever way you choose, the goal remains the same: raise awareness about silos and do something about it. Leave the current reality and aim at the bigger goal, define a new reality, save the neighbor.
Now let’s hear about you. How do you save your neighbor? What will you experiment?
No Comment