How to Support Apprentices on an Agile Development Team

Recently, my team was tasked with figuring out how to introduce what we chose to call “Apprentice Developers” into the team in order to help on board new talent into the company. How would our day-to-day interactions and development practices have to change in order for less experienced team members to grow while being productive? I was pretty excited about this initiative, as I enjoy mentoring others to become better software developers and being part of effective, high-performing teams.

Our definition for Apprentice Developer:
Entry-level Dev. Probably none or less than a year of full-time professional experience in software development.

First some background, in the past few months we have been supporting a couple Apprentice-level developers with various amounts of success. Until now, the development team had been a bit loose in adhering to XP practices, such as pairing. Sometimes we would, sometimes we wouldn’t. Sometimes we would switch pairs every day or so, but there was no real cadence to it. Being a small agile team (7 devs), this kind of thing was fine for awhile, but we could easily see that adding more less-experienced devs would require a tad more structured of an environment.

Our first step was to take on honest look at our dev team culture and how everyone was responding to it. We discussed the worries that the team had and we solicited feedback from the current Apprentice developers centered around how the team had supported them, and what areas there might be for improvement.

We came to the conclusion that we would identify five new development practices that promote a more supportive and safe environment for Apprentice-level developers. So we carved out about two hours to come up with them, which I facilitated. To start things off, we narrowed our focus just a bit by creating a few categories that we thought would have challenges from the initial group discussion notes and feedback. From here, we took about five minutes to do some divergent thinking and come up with as many ideas as we could for addressing anything in any of the categories. After reviewing, clarifying, and grouping similar ideas, we each used five votes to start converging on the ones that we wanted to take further. It looked like this.

Next, we discussed the ideas one-by-one in descending order of votes, with the outcome of each discussion being a tangible, immediately-implementable practice for the team. Here is what we came up with:

As facilitator, the most obvious feedback for myself is that I was not an impartial outside facilitator. I had my own ideas and biases. Though I consciously tried not to let them interfere with any discussions, I’m sure that happened a little bit. That is probably unavoidable and a big reason why an outside facilitator for exercises such as this one is preferable.

I also could have watched the time a little better. It took over 2 hours, which I feel was way long. We got off track quite a few times. And the discussions after voting may have been a bit too open ended. Looking back, having a set time box for each post-vote discussion may have provided just enough time pressure to spur the group to create something tangible a bit quicker.

At the end of it all though, the team agreed upon five new practices to enact right away. The underlying goal was to help support new Apprentice developers, but I think the entire team, regardless of experience or skill level, will benefit from them. I’m looking forward to seeing how it goes and how the team grows!