A Leaner Start: Reducing Team Setup Times

Posted by Pat Kua on Nov 22, 2007 10:12 AM

Community

Agile

Topics

Teamwork,

Leadership,

Training / Certification

Tags

Management

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.

1. Back to top

   Getting New Hires Off to a Good Start

   Nov 25, 2007 10:51 AM by Chris Sims

   Often times, a new team member is also a new hire. . . My friend Peter started working at EvilEmpireSoft on the same Monday that I started at Geekaplex. That Friday, over beers, he told me that he had spent most of his first week waiting for his laptop to show up. When it finally showed up, it had an outdated version of the development environment installed which couldn't compile the code he was supposed to be working on. On top of that, Outlook was misconfigured and wouldn't even think about connecting to the mail server. He spent an afternoon figuring out the configuration only to discover that his email account hadn't been activated yet! "It's as if they were surprised when I showed up for work on Monday. Maybe they forgot that they hired me? I spent the first morning waiting in HR until someone was available to give me paperwork to fill out. After that," he went on, "I spent the afternoon wandering around looking for an empty cube to claim." I felt bad for Peter, and I was almost embarrassed at how different my first week had gone. My office was just down the hall from my boss's. There was no mistaking that it was mine, as my name was on the plaque next to the door. Inside, I found a shinny new ThinkPad with a docking station and a pair of flat-screen monitors. The drawers in the desk were filled with new pens, pencils, paper, a stapler, and even a box of freshly printed business cards. My boss sat down with me and walked me through my first week, pointing out the various meetings and training sessions that were already on my calendar. There was even a welcome email from the president of the company waiting in my in-box. "Wow!" Said Peter, "You're like a VIP over there! I feel like most folks don't know I exist, and if they do, they are just hoping that I won't bother them. It really sucks. EvilEmpireSoft seemed so cool and together when I interviewed, but now I'm wondering how they get anything done. They aren't the elite, well-oiled organization that I imagined them to be. I feel like I made a big mistake accepting their offer." What a big difference attention to detail and a little preparation made. By simply taking the time to provision my office, my boss sent me a strong positive message about the company, and how much they valued me. Additionally, by making sure that I had all the tools I needed to be productive, they let me know that they expected me to be productive. I felt like Geekaplex had it together, and that they would expect me to have it together as well. I felt welcomed and challenged. Originally posted here: http://blog.technicalmanagementinstitute.com/

   Reply

2. Back to top

   Why is this a problem?

   Nov 26, 2007 2:24 AM by Steven Devijver

   One has to wonder how hard this problem actually is. I my experience new people that come on board never have all the skills they will require. That's why it's important for me to run my projects in such a way that people aren't expected to be extremely talented. That's why tasks like updating design documents and writing documentation are part of our iteration planning and burn-down charts.

   Reply

3. Back to top

   Good agile practices

   Nov 26, 2007 6:05 AM by Junyin Wu

   A new project coming soon, I wanna try these agile practices :P

   Reply

4. Back to top

   Re: Why is this a problem?

   Nov 26, 2007 7:37 AM by Deborah Hartmann

   Steven, it seems you have balanced the tactical (get the software done this week) with the strategic (and make sure we can continue to do so). But not all teams have done this. When things get tough, some decide it's ok to worry about the future in the future, i.e. we'll catch up on that later. Sounds risky to me :-) The future doesn't usually ask if you're ready before it arrives, lol.

   Reply

5. Back to top

   Mimeograph

   Nov 26, 2007 1:30 PM by Greg Helton

   Where I work, technical policy announcements are sent out via email and never added to a central repository like a wiki. I was told that the wiki is not the place for that type of info. New guys are screwed until the parts for our mimeograph machine arrive.

   Reply

6. Back to top

   Re: Why is this a problem?

   Nov 26, 2007 9:27 PM by Patrick Kua

   Hi there Steven, The problem I've seen across many projects inside and outside of agile development is most people are thrown onto a project and assumed they'll pick everything up. The best case I've seen is a single day walkthrough where the new person is bombarded with everything in one go. I wanted to express alternatives that I've found very effective and useful in different circumstances to drastically improve the learning speed of new team members. I agree that lack of skills can a problem and so plan accordingly. I've also seen people with skills not applying it correctly because they lack the context of the entire project. Hopefully these techniques will help build this context faster for them.

   Reply

7. Back to top

   Re: Good agile practices

   Nov 26, 2007 9:28 PM by Patrick Kua

   Good luck. I'd certainly appreciate finding out how they were useful/not useful for you.

   Reply

8. Back to top

   Good to formalize the process

   Nov 27, 2007 2:39 PM by Jeff Bonnes

   Good Article Patrick. In the team I just built I think I did about all of the tasks above, but not formally. I wish I would have had this before I started! It is good to recognize that building a team is different than running a team and has it’s own set of tasks. One thing that we did do that was very effective was called 'designing the alliance'. It is a bit 'HR' but really effective. Basically, we agree on 4 things: Granting Power to the Relationship: Permission to be open in communication, How do we communicate when were ________? How do you like to be communicated to? My communication style is ________. The logistics of the relationship: when / where you both work, how best to communicate, what is required (updating JIRA, daily scrums etc.) All the stuff that is expected of you (both ways!) as a team members. Discovery: What needs to be at the heart of our relationship for it to be effective? What are the obstacles or potential obstacles? What might I do that would really piss you off? (You learn a LOT from that one!) Future: What are your goals for this project? What types of rewards will we both get? How will we celebrate our successes? If you get this done at the beginning of the relationship (we write it down and all sign it) it really opens of communication with team members from day one.

   Reply

9. Back to top

   Re: Good to formalize the process

   Nov 27, 2007 6:50 PM by Deborah Hartmann

   Jeff, your "alliance" is interesting. You mention "both" - in a multi-player communication game like a software team, who does this refer to? Thanks. deb

   Reply

10. Back to top

    Spend the time up front

    Nov 28, 2007 10:07 PM by Pete Johnson

    Nice article, Pat. I couldn't agree more. The steps you outline for the onboarding process are good ones that are all well laid out. It's important in the early stages of a project to create the documentation/artifacts you'll need to expedite all those steps when they happen later. If you wait, you'll only be distracted with the other things going on in the project and not do as good a job. An ounce of prevention absolutely beats a pound of cure here. Can I be on Jeff Bonnes team? Great outline for setting up the rules of engagement. I'm definitely going to steal those ideas. Pete Johnson HP.com Chief Architect Personal blog: http://blog.nerdguru.net

    Reply

11. Back to top

    I will try it!

    Nov 29, 2007 1:30 AM by Alexander Pavlenko

    I'm Alexander Pavlenko, Java Solution Architect. Some days ago, I interviewed a new guy for my project team and he is going to join us next week. I will try this practise and, of course, I will write about my experience. Thanks

    Reply

12. Back to top

    Re: Good to formalize the process

    Nov 29, 2007 10:14 PM by Patrick Kua

    Hi Jeff, I'm very intrigued about your alliance approach. I will definitely try it out the next situation I get to. Thanks for sharing.

    Reply

13. Back to top

    Re: Good to formalize the process

    Dec 17, 2007 4:34 AM by Jeff Bonnes

    Hi Deb. In our context, it was the Scrum master and the team members as a start. We also had some Senior developers do it with starting programmers. It could also happen between team members. What I have found is that if it 'starts at the top' the communication between all team members is open, it filters to all the relationships (or at least most!)

    Reply

• Older >