During agile transition, it is common that large organizations take the books and advices word by word. In scrum, it is advised to have cross-functional teams. This advice is unfortunately sometimes interpreted in the wrong way. For some people, cross-functional team means that everyone on the team shares the same technical and business knowledge about the tasks that the team is supposed to work on. This kind of transition is not only very very expensive - time and money -, but scares the management. I joined an organization, where, unfortunately, the goal was to create teams using this interpretation, and after a couple of months I can tell that it did not worth it. We could have used the time we spent on the cross-functional build-up on delivering more features of the product.
Transition is usually done in several steps and on different layers of a large organization. Usually, first developers do it, then testers, and management at the end. For management, a team where everybody is an expert is very scary. They don’t get the point of it - because of the false interpretation -, they do not understand why train experts, why should everybody be an expert, when the only thing they want to do is deliver features to the customer. These doubts make them confused about the whole transition, and when a manager has doubts, he’ll turn to the old, “this has worked before” ideas, and usually the organization is back at square one.
I prefer the cross-functional team definition from stackoverflow and wikipedia: A cross-functional team is a group of people with different functional expertise working toward a common goal.
I believe that teams can master this definition and get better and faster at what they are doing, but it shouldn’t be the first thing they implement. Start with engineering practises (like XP) and scrum team set-up instead. If the team is getting to understand the main scrum principles, they can start working on being cross-functional. This is very difficult, hence I was thinking about a way to do it. Retrospectives are a great way to find goals for a team, why not set a goal like being more cross-functional?
During a retrospective, it is usually not known on exactly which user stories the team will work during the next sprint(s) (retrospectives are before planning meetings), but the release plan is kind of known. Take a brief description of user stories from the release plan to the retrospective and ask the participants to have a look at them. As a next step, take a bus factor of 1. Ask around whether the team would be able to work on the user stories if any of the members were absent during the next sprints. Let’s assume that the team consists of seven people, meaning that they shall check seven possibilities. If they find at least one case when they won’t be able to deliver any user stories, that means that the team found a knowledge bottleneck. I advise to stop here at the first time, and find a goal to share that knowledge; not among everyone, try to reach bus factor 2. A solution can be pairing up with the colleague or team member who has the knowledge, or asking him to keep dojos about his knowledge.
The goal is not to train backup persons for certain areas, but to share information in order to go better and faster: the more people are familiar with a certain area, the better the team performs, but there is no need for them to be on the same level. The team can go on with the practise above until they can survive a sprint when 45% of the current team is not available. In the example the team shall continue the retrospective game until they reach the bus factor 3.
This game is also helpful when the team changes. By default, the knowledge of the new members is not known by the old members, but with this easy game, new members can expose their knowledge to the team. It may happen that they have the knowledge for working on user stories in the upcoming sprints. In this case the team saves valuable time: they can work on features instead of trainings. On the other hand, if the necessary knowledge is not available, the game starting with bus factor 1 can help to build up the overall team knowledge from scratch.
comments powered by Disqus