Imagine the following situation: There is project team of two developers already working for several months on a new and complicated feature of an Enterprise application. There are a lot of interfaces and they are doing agile, so documentation is not necessary….Management decides to speed up the project and adds two engineers and two testers. They still believe that when a woman delivers a baby in nine months, nine women deliver a baby in one month 😉 You are the scrum master and you have the challenge to speed up the process…
I experienced this situation half a year ago. The major problem was a lack of knowledge for the new team members. The team decided that all team members should be able to do all tasks. There should be no specialization, or at least as less as possible. Additionally, we decided to take the time to spread the knowledge. Knowing that investing in knowledge would pay of in the next iterations.
We started with some classic knowledge transfer (kt) sessions. The developers who were involved from the beginning explained how the system worked, using a whiteboard. Some knowledge was transferred. However, you already probably know that experiencing something is a much more efficient way to learn then just listening to someone. At the end of every kt session, the new team members said they understood the model Did they really understood the model or did they understand what the presenter said… I decided this was not the way to go, the new developers and testers learned the system. However, it went to slow.
I read somewhere sometime something about bringing a model to life. (I can’t remember where, if you know where please let me know). We played the Game. Remember, building software should also be fun and listening to someone explaining a model is not fun! Every team member represents a sub-component or external component, during the game team members communicate with each other as the software would do. By playing the component itself, they experience the software itself.
After several kt sessions, the new team members knew all different components and the basic interfaces. That was at least something we realized with the kt sessions ;). I assigned every developer to a basic component of the model. Some developers had to be assigned to more than one component. The testers were assigned to different user roles. Everyone looked forward to the meeting, they were excited and curious about how it worked out. Until this meeting, no one looked forward to having a kt session.
The preparation was arranging a meeting room with a digital whiteboard and enough space to walk around the whiteboard. Make sure every team member knew his role during the game.
We started the meeting, and the testers started the first simple cases. Simply, acting as a user and requesting data or entering new data. The developers accepted the request and passed the necessary data to the next component. The receiving component processed this data, and so on. The end of the chain was that a developer/component gave feedback to the tester. During this first round, I wrote down the communication between the components on the whiteboard to make some kind of documentation/minutes.
In the next round, the testers asked more complicated cases or “entered” incorrect data. The different component had to handle these incorrect data and give the correct feedback to the users.
The last round was to understand recovery functionality. What happens when one component is not there? In this case, it was just a matter of “removing” a developer from the game. The other components had to handle this correctly and again give the correct feedback to the user.
The game was a success. Everyone liked the game and the set-up. However, the most important was that all team members finally really understood the system and complexity. They experience the system! The outcome was also some graphical models that the team members used to discuss improvements in the system.
All people involved will need some basic knowledge of the system. Therefore, some classic kt sessions are still necessary. Additionally, you will need the support of management. If your team is expected to work only and have no kt session meetings… We called the meeting the Game…some people knit the brows when they heard we planned a game. Maybe it could help if we name the session kt session.