Introduction

As a team matures, it generally enters into the 'performing phase' of Tuckman's stages of group development. While this phase has great benefits in terms of productivity, it can also increase the fragility of the overall system as a crystalised team can be extremely susceptible to disruption.

What happens if you have a sudden surge of work and need to take on extra people? If roles needed to change, or if people left? Any change to the team is considered as a new team which comes with a new dynamic and people have to re-learn to work together efficiently.

With the success of some of our services, we are looking to grow and increase the size of the team, not necessarily just the development team. However before we pull the trigger we thought it would be a useful exercise to introduce some disruption temporarily with a summer internship. The potential lessons would be invaluable to how we can protect or at the very least, buffer the performance hit as the team reforms.

Preparation

As we have a good presence in the community, we were lucky enough to have a good selection of candidates for a summer internship. Due to the short amount of time to set up and monitor this exercise, we selected someone already familiar with our processes. A previous work-experience student, Steven.

Expanding on from a short period of work experience with us, we felt it was possible to deliver some commercial features with support and guidance of the team. Steven would be treated as a core member of the team. He would attend all the usual meetings and discussions, and be expected to perform the same duties as any other member. This would include time tracking, task tracking, performing estimates and delivering the same quality of work as would be expected from any other developer here.

Takeaways

With multiple stakeholders and following our tried and tested retrospective, we turned the focus on the internship itself and some of the results were surprising. This multipart blog-post will feature discussions from different roles within the team with key takeaways in each post. As this has been a collaborative exercise between Viva IT and our intern Steven, he has provided insight at key points.

Always, always have a plan

The importance of a plan to deliver your goal is critical, even if reality doesn't follow it. Just because reality doesn't match your plan (and it probably won't), you can still adjust. As your plan changes, so will your goals, which then can trigger commercial discussions (bigger budget, more time, etc)

A plan should be derived from planning, it sounds obvious but it is here explicitly. What are the goals (both those of the company and those of the intern) you want to achieve by the end of the internship? What challenges do you think will face? How can you overcome them? While getting all the stakeholders involved can help with answering these questions, they also greatly increase the verbosity of the planning which will suffer from diminishing returns with the number of people brought in, so choose your planning team wisely.

A plan doesn't fail because reality doesn't match it, it will fail if you give up on it and the goals contained within. I'm pretty sure that the original plans for a notable monument in Italy were not titled "Torre pendente di Pisa" [The Leaning Tower of Pisa].

Your plan will set out the goals and deliverables, and over time you can measure the performance of them, don't forget why you're doing this in the first place! Your team is working towards this plan and making it happen.

This plan should be communicated to all stakeholders, so everyone is aware of the goals, deliverables and performance. If your plan has trackable goals (it really should), then everyone can be aware of the overall progress.

We wanted to monitor the performance dip of a team during a new developer onboarding, we established time-tracking and task tracking as performance indicators, however as the exercise progressed we found other areas which were impacted (increased communication lines, pair-programming time, context switching hits and thus amended the plan to include these as goals to reduce). This prompted commercial discussions which resulted in delivery of training to the mentor to the intern to reduce the reliance on them.

Day 0-1 training in basic tooling and processes

In modern software development there are many tools, products and services that people will use habitually, your organisation will also probably have dozens of processes that are performed too. Remember that this is why you're in the performing phase; the frictionless collaboration, the short-cuts, the discussions and how they are chaired, what is expected by each person.

Before beginning the internship I was informed to look through some tools. These were tools such as version control, testing suites, IDE, frameworks etc. It was imperative that I read up at the very least to find out what these tools were. After spending some time reading the documentation for each tool, I began to try using the tools. I began by installing the PhpStorm IDE and trying to install the correct version of the Symfony framework.

The version control tool used was Git. This is incredibly important to learn before you begin working in any programming environment. To learn how to pull and push data from a repository is where I began. It was ideal for me to learn this from YouTube as there are plenty of tutorials explaining how it works and the importance of the tool.

- Steven

Something that stuck into my mind from the PHP North West 2015 conference was a keynote by Meri Williams (@geek_manager) which explored about human skill development and how people move through 4 stages of skill from unconsciously incompetent, consciously incompetent, consciously competent and unconscious competent.

The last one is particularly challenging to deal with because as people reach this point in skill development, they no longer consciously know how things work. A great small example that we identified through this exercise was that something as simple that our intern was not subscribed to the "5pm" Slack channel:

For a while I was not in all the communication channels on Slack. This meant I was reliant on other developers to see what was occurring. I needed to ensure I was within the correct channels. This provided the information about what is happening.

- Steven

We use this channel internally to prompt for discussions at the end of the day, it's just something we use single every day. Now, you might not consider Slack to be basic tooling, but here it was proven to be critical in our process.

Expanding on from this we have identified the need to have a perform Day 1 training of critical processes, this will be delivered formally and not left for them to 'pick up'. However we aim to eventually deliver through a "handbook" which could also mean training can be delivered on Day 0 (pre-start). This could also help reduce the stress of any new team member as they will know some parts of what they are literally walking into.

As the sprint retrospective changes our processes gradually and continuously, these should be reflected in the handbook to avoid any process creep. We drew some inspiration from the Valve and Basecamp handbooks, paying particular attention to make it a working document, so rather than a pretty document that could become out of date very quickly, we will do what we do best - start somewhere and build on it over time - https://github.com/vivait/handbook