Previously Matt detailed the day-to-day effects of internship from the perspective of the development team with key input from Steven, our Summer Intern. They also shared advice for future internships.
Here we explore the impacts of internship on successfully planning for and coordinating an Agile development team used to working with colleagues accustomed to our implicit ‘culture and rituals’. We have used this internship to look for opportunities to enhance the positive impacts of future internships for the team and company, and mitigate against any challenges. Key takeaways are noted in bold.
Allocate Pair Programming time
Consider the suitability of work that the new starter will be given from commercial, learning, and support perspectives.
Allocate time for pair programming within Planning Poker estimates, whether you normally pair program or not.
When I first began, there was a lot of reliance on the developers around me. This meant there was a lot of context switching in order to assist me. This meant they were leaving the task they were working on and had to immerse themselves in the task I was working on.
Explicitly reduce other performance expectations on the main mentor for the intern, if not the whole team, even if such performance expectations are usually implicit. The mentoring and training demands on this individual are likely to be greater than expected, and without reducing this extra pressure in another way, the mentor might feel impatient or resentful toward the extra demand on their time and focus represented in the mentee.
Keep a close eye on the morale of the team during this time, as ‘forming and storming’ is likely to occur.
After a week of working on forms, I was moved onto working on an API. This was a massive learning curve again. The project I had begun working on had changed and it was not a similar project, it was a completely different project.
Convergence between actual time spent against estimated time spent increases relatively fast, but is not linear, and reverts to a highly divergent baseline when switching to a new project. This makes short term scheduling more unpredictable and necessitates either backup scheduling plans or the agility to apply flexible planning at certain milestones. The role the intern plays in any critical paths should also be considered as high risk.
Follow your Escalation Process
When I first arrived I was incredibly nervous despite having completed a week of work experience with the exact same team of developers. Once I was set to shadow other developers my nerves disappeared completely.
Consider shadowing to ease in the new starter.
Existing code examples and standards helped with guiding how new code should be written, as it shows the standards and sets the bar for future code.
Confidence building in more basic tasks helped because it meant when the intern reached a point where they weren't sure what to do, they didn't panic, but tried to work through it with confidence there was a path through.
It may be helpful to have a breakdown of what is required at each stage to implement a task (even down to as specific an example as 1) create route, 2) create controller / action, 3) create entity & migration, etc.) to assist in spotting when escalations are needed.
Avoid the need for abrupt remedial actions by paying special attention to training your new starter to observe your escalation process.
As the internship progressed I had multiple one-to-one sessions to explain how I am feeling in my position to find any improvements or ways that I could improve in the way I am working.
Giving the mentor a single point of contact, while clear and self-containing can have the unintended effect of leave the new starter unsure who to go to if they have issues that require it. They might feel like they can't talk to or disturb anyone else. Make it clear that they're able to speak to anyone.
An internship can expose weaknesses and gaps within normal processes or lines of communication. For example our interning developer received contradictory instructions with regard to which task to go onto next within a project (as if there were two conflicting product owners). This can lead to a tangle of trying to fix internal processes at the same time as dealing with the new interning experience. Anticipate this happening and defer process improvement if it will put too much extra load on the team during the time of the internship.
Bring the new starter to all team meetings
In organisations where diverse opinions are welcomed, new starters need to be made aware that we value their opinions from day 1. Build confidence in newcomers to encourage them to speak up.
From the start of the internship, it was made very clear to me that my opinion about how a task should be programmed, or my view about working in the company mattered. It is important to realise fast that you can voice your opinion as you will not be told that you are new therefore your opinion is invalid.
Bring the Intern or new starter to all meetings. Even if, unlike in a sprint retrospective they will not get much from the content of a given meeting meeting, it gives the individual an opportunity to start to gauge the culture of the company, how colleagues interact with each other, and help them acclimatise. Reassure the intern that they are not being expected to understand everything, and encourage them to ask questions.
In the working environment, sit the mentor and mentee physically close together.
Take time to explain the hats different people wear, that the new starter needs to be aware of such as who is the product owner, scrum master, HR representative.
Digital project managers can benefit in similar situations by ensuring creation of a training structure so it becomes clear if too much new information is being covered and potentially overwhelming the intern, or not enough. Our focus regarding this concerned how many software projects to expose the new starter to in a short period of time.
Improve task descriptions, in our case by making them more granular, obviously for intern tasks but ideally this can be a chance to revisit best practise on all new tasks.
Ensure tasks are understood, and that a plan of approach for each task is created between the Intern and a more senior developer.
Ensure curation of a suitable issue backlog for the intern.
Encourage an engaged participation in scrums by the intern as soon as possible, and take the time to explain the purpose behind your scrum, or daily stand up meeting and the value it can have for them. Likewise, foster enough trust for honest retrospective feedback, but this will be a challenge as the intern may feel particularly vulnerable in expressing dislikes/negatives/improvements until they acclimatise to the culture.
Finally, although this should apply to the whole team, pay particular attention to shielding the intern from external commercial pressures which might increase their stress.
The cost of this interning exercise manifested in increased disruption and workload on the rest of the team that notably would be paid off in time, once the intern got up to speed.
By the end of Stevens time with us he had gained a good familiarity with certain key projects, delivered multiple useful solutions for several of our clients, and gained key understanding in how we operate that would help him succeed if he visited us again. He also gained great exposure to the industry and the need for teamwork in software development.
We are grateful to Steven for his permission to discuss details relating to his internship publically in this blog format. We hope we helped an aspiring developer within the community with this internship experience. In return we learned how to iterate on our process for onboarding new starters or future interns to be able to quickly place them in fulfilling roles as part of our team.