Face facts: Teams change
I've worked with lots of teams in the past few years, some for very long periods, others for very short times. One common theme I've noticed with many of those teams is that the team composition always changes. Usually, events beyond the control of any project trigger these changes: people fall sick or take holidays, project demands grow, new project opportunities arise or people simply want a change. Agile practices, like daily stand up meetings and pair programming, provide new members with all kinds of incidental information which may in fact be useless if they don't have enough context to hang it on. Since agile practices don't directly address the learning needs of new team members, I suggest the use of other practices that specifically reduce the "setup time" for new team members.Queuing theory applied to teams
In manufacturing, lead time is traditionally split into four components, including:- Setup - The time it takes to prepare the process before you can actually start running.
- Run - The time it takes for the item under process to be processed. This is sometimes divided into process time and wait time.
- Move - The time it takes for the item to the move to the next process.
- Queue - Any time the item waits before it enters the next setup process.
Apply the same concepts to teams and the addition of a new team member and you get something that looks like the diagram below.
The last two parts of lead time (move time and queue time) don't affect individual projects and so the focus traditionally falls onto the first two parts (setup time and run time). The setup time for a new team member is the time taken for them to become a fully effective member of the team. This means any time and effort spent by the team to help induct them into the team, show them the ropes until they can contribute to their maximum potential. The run time includes how effective they are working in that team.
Brooks' Mythical Man Month explains in great detail the impact of adding more people to a project, especially those that are already in trouble. It emphasises the communication overhead that comes with more people in addition to the time required for new team members to learn about the project. Time spent onboarding new members creates additional drag on the team. The communication overheads caused by another team member applies continually throughout the run time. Given that, the total cost for a new team member now looks something like the diagram below.
Most processes focus on improving the way teams work together, helping to reduce the running costs of a project. What they tend to neglect is a focus on reducing onboarding time - something that affects how quickly new team members can be added, or how well the team can cope with changes in its composition.
Agile practices address run time, not setup time
Learning is an integral part to every agile methodology. Almost all of these focus on short feedback cycles, employ reflection exercises and emphasise continuous improvement.
However, the learning needs of someone new to a project are very different from their needs after they've been on the project for a while.
For new team members, digesting information tends to raise more questions than answering them. Statements such as the Scrum standup meeting's "I did ... yesterday" triggers questions such as "What are they talking about and how does that fit into everything?" The effectiveness of pair programming also changes, becoming more effective if the newer half of the pair has a high level overview of everything, but becomes very ineffective if they just develop user story after user story, showing them minute details that don't fit into any big picture. I've seen many new team members become very frustrated when they're given lots of tiny bits of information with no common thread tying them together.
The main goal of a new person is to learn about the larger context. They seek out things they should know about, start to understand the domain specific vocabulary, and begin to work with the team and the work culture. The more complex the project is, and the larger the number of people who join, the longer this phase can last.
After developing a broad context, the learning starts to focus on deepening knowledge. With a context to hold bits of information, incidental information becomes easier to absorb. Practices such as daily stand up meetings, pair programming, test driven development and retrospectives all provide this sort of incidental information yet is only useful if put into that bigger context. Given agile practices don't directly focus on these different learning needs of new team members, what are your alternatives? Use other practices that specifically reduce the "setup time" for new team members.
Reduce team setup times with onboarding strategies
Here's a brief list of techniques new team members on my teams have found useful developing the broader context necessary to understand all the incidental information provided via agile practices:
- Preparation Email - Before they join, send them an email explaining the background for their project. It gives them an opportunity to do some reading before they even start, or an opportunity to start developing other skills or knowledge related to the project.
- Big Vision Business Problem - Run a session showing new team members the value behind the project and what is driving it. Start to familiarise them with domain specific terms and put the work they will do into a bigger context.
- Visible Architecture - Diagrams are useful for putting smaller concepts into larger ones. Use these as a talking point around where to focus knowledge gathering efforts and how they all relate to each other.
- Transparent Project Debt - Be frank about areas that the team already knows need some improvements. Focus on how things can be improved and what things are planned, not on how bad things are.
- Tiny Tasks - Break big lots of work into tiny tasks so new team members don't need a lot of hand holding and they can start to understand common tasks project team members do. Ensure that each item is achievable with minimal assistance.
- Tech Huddles - Bring people working in similar roles together on a daily basis to share new learnings and any tricks that might be useful for similar people. These sessions should be focused on skills learning and sharing.
- Student to Teacher - Put new team members into a role where they might help other team members. Getting them to explain concepts to other team members helps consolidate their own learning and refines their own thinking.
- Respect Individual Needs - Adapt the learning process to suit the individuals. Use diagrams, documents, CRC cards or anything that helps them better form that broad context.
- Letting Go - Give each new team member enough space to make mistakes in a safe environment. Some lessons are more effective if they learn it themselves.
Rolling team members on to projects doesn't have to be difficult
Agile practices are great proponents for learning although aren't necessarily as effective for new team members since they focus on reducing the "run time", not the "setup time". Understand the different learning needs of new team members and address them directly with specific onboarding practices. Draw upon further external practices to continue to reduce this "setup time".
There's a very good reason that most people joining a company go through some sort of induction programme. How effective is the one you have for your project?
About the author
Patrick Kua is a software developer, trainer and coach for Thoughtworks. Patrick is passionate about adding value to the teams he works with, and is passionate about people being passionate about the things that they enjoy. He believes it's even better when they align the things they enjoy with the things they do in their career. He has coached, lead and been a part of many teams practicing agile for the last three and half years.
