Summertime Blues

No matter how much we try and plan our projects around holidays, and allow for the fact personnel will be off for long periods during the summer holidays, somehow we still manage to grossly underestimate the impact it is going to have on the productivity of our teams.

I’ve made a point of displaying the team availability on the wall beside the teams, as well as entering all absences into our shared calendar in an effort to raise awareness of who will and who won’t be here during a sprint, but to no avail. During July and August, we failed to deliver at 2 out of our 4 sprints and I think it’s no coincidence that this has happened during our peak holiday season.

So what exactly, is going on here? Here are 4 of my key insights into why this might happen:

Leadership – various individuals tend to play a stronger role than others throughout a sprint, as we naturally have leaders and followers. Any time a ‘leader’ is off, the cracks start to show, and I can see the team is no longer functioning ‘as one’. The difficulty in resolving this, is that the ‘natural’ leader may not be the designated leader – often there are one or two people who lead by accident – they have a grasp of the whole project and are good communicators, able to see when they need to step up and step in, to pull the team together in a cohesive way.

So to create a clear accession plan whereby you can delegate to a deputy isn’t a straightforward thing to do. Instead this is the time when a Scrum Master or Product Owner will need to ask more questions, to encourage the team to share knowledge with each other, to open up and not rely on their natural ‘spokespeople’ to drive the work forward.

Continuity – specifically in the two teams I’ve been working with recently, I’ve only seen one official handover ‘document’ (comprehensive notes on Slack) out of 12 developers during the holiday period. There may well have been some verbal handovers, or it could be that the teams are so in tune with each other that they don’t need notes (really not likely!). However, the standard of the work delivered during the holiday season throws this theory out of the window, as we have encountered a real ‘stuttering’ effect where the workflow has appeared to stop-start-stop-start, with tasks lingering on Jira for an entire sprint, either unassigned or assigned to someone who is on holiday.

One way to alleviate this issue is to insist that tasks are reassigned prior to someone going on leave, preferably with a minimum verbal handover – note even better. Then at least if I can see that a task is still assigned to someone absent, it can be raised at stand-up and resolved before getting to far into a sprint.

Consistency – like a traveller embarking on a journey we all know there are many routes you can take to arrive at the same destination , and this is true of technology. Individuals in your team may have a slightly different view of how to achieve the desired outcome, both in how they interpret requirements, and how they set out to solve a problem.

This can have an impact on your sprint when work is handed over from one individual to another, as it can quite often lead to someone starting a task over again, rather than picking up where their colleague left off. And even if they can pick up the thread, there will always be the overhead of the extra time they need, to get into the mindset of their team mate in order to complete their work.

This is why the synergy of a team is so important – we should be doing everything we can to instigate an agreed approach, whereby everyone becomes familiar with a shared way of working, and therefore taking a similiar route to the same conclusion.

Lack of specialist knowledge – absences can put a sharp focus on specialist areas that often remain invisible for much of the time. WebOPs, DBAs, front-end specialists, UX designers, QA Testers – all become conspicuous by their absence, but often at a point when it’s too late to intervene.

Planning ahead is critical in order to look at the contingency for those gaps in the team. Does anyone have enough basic knowledge to cover a role, can somebody at least manage their tasks at a basic level in the interim? I’ve found these kinds of gaps can often create an opportunity to be seized, if like me, you’re intent on building a team of T-shaped individuals. I

n one particular situation, despite all agreeing the whole team should enhance their front-end skills, it wasn’t until our front-end specialist had to take emergency leave, that the ‘back-end’ developers had to step-up and build the UI, with pretty successful results. Ideally if you can avoid doing this in a pressure situation, and build in time to allow developers to share skills, its much more favourable…but forcing someone’s hand can sometimes give surprisingly good results, plus a real sense of achievement for the individual involved, having taken on a challenge they may otherwise have avoided.

I’m happy to say that the two failed sprints did resonate strongly with the teams, and after the second failure it was absolutely at the forefront of their minds during the next planning session. When agreeing what we would take into the sprint, several team members made a point that we would be losing some key skills to a series of upcoming training courses, so they adjusted the scope accordingly and also made a concerted effort to adjust the focus of each individuals’ skills during the sprint to balance out against those we would lose during the training period.