Informing, inspiring, and engaging society with EMBL’s research, services and training
Here we are hanging out our dirty laundry. As “fail forward” is one of our drivers in the agile work method, learning from what we could have done better in the sprints is as crucial as the achievements of our goals.
So here are some useful lessons we have drawn from this last sprint.
The last sprint took three and half weeks, which was too long. It was exhausting, and it made it hard to keep cadence high while making sure that daily business is running. This was especially true over this sprint, which coincided with the start of the new PhD programmes.
You cannot over communicate when you are sprinting.
In the last sprint, we informed the Strategy and Communications team and other departments verbally about the sprint planning, timing, team members, requirements, goals and planned output. However, we only shared a one-page document outlining sprint parameters within the sprint team. From now on, I will circulate such a document to all parties involved in the sprint and to all Strategy and Communications team members.
In the kick-off meeting for this sprint, we decided to have a daily stand-up call, as we would be working remotely for the three following weeks.
We weren’t good at sticking to this stand-up, and this became really disruptive as learnings and ideas weren’t shared evenly across the sprint team. It wasn’t uncommon for someone to say something like, “Hang on, when was this decided?” or “What happened to idea X?”.
Sticking to a routine during the sprint is hard, and it demands discipline. If one party is unable to attend the call this person should communicate this to the team.
In future, at the end of each daily stand up, I will also make the effort to reiterate the assumptions we are working to and outline the decisions taken during the call. I’ll share this in written form with the sprint team. This is extra work, but I think it will help us to all remain focussed and gives us the opportunity to identify when we’re not.
We used Slack a lot for our sprint team communications and had a dedicated channel for this sprint called cdsprint2 – but there are many channels in our Slack instance. We used our OwnCloud server to share graphic files and store documentation. For collaborative strategic papers and presentations we used Google Drive. Skype was our tool for the daily stand-up. We saw differences in how people used these tools within the sprint team which were disruptive.
How we use all these tools needs to be agreed within the team up front in each kick-off meeting. We need to have a conversation about our understandings and assumptions about each tool. For instance, can we assume that posting a note to the Slack channel means team members are informed about something?
The work we are doing for corporate design is foundational: we’re going back to basics. We are trying to establish the unifying principles of the EMBL brand – things like, Why does EMBL matter and what does it aspire to change in the world? This work inevitably leads to some brain-melting rabbit hole moments (a favourite such moment of mine was watching Ken staring with a furrowed brow into the distance and muttering, “So what, exactly, is EBI?”). Rabbit holes can be great moments – they can highlight when you’re on to a concept that needs to be better articulated or explored. But rabbit holes also take time and energy, so it’s important for the sprint leader to know when to explore one and when to pull back and refocus the team onto something else.
Having a two-week sprint sounds easy, right? Set aside your work and concentrate on something specific for a short period of time in order to do great things. But what happens to that work you set aside? It just keeps coming!
For this sprint I factored this in by communicating to stakeholders that I wouldn’t be available for regular design and production work over the sprint period (much as I would do when taking leave), by hiring in freelancers to cover urgent requests and by delegating some things to our two amazing design interns, who took up so much for me (thanks Aleks and Julie!). But still it was tough to clear time to devote to this sprint, and I think all members of the sprint team would echo this.
So in future, I think we need to budget resources to free ourselves for 80% of our time to devote to the sprint. Despite my best efforts, I estimate I only managed to give 4 hours per day in this sprint (I won’t say what percentage that represents!), and it needs to be more.
Part of this is resources (for supporting external designers to handle production work, for example), but also a long preparation period to try and clear the sprint period – we’ll need the support from our managers and team mates for this. Shortening the sprint period also makes this more feasible.
Sprints require a lot of time and energy for scheduling meetings, aligning travel plans, involving stakeholders, sharing documentation and presentations etc.. So we might think about a dedicated person who takes the admin work off the sprint lead and hence frees their time for other more task- and team- driven stuff.
To make sure that all – or at least most – of the goals can be achieved in the sprint, whatever happens, it would be helpful to think about about a Plan B. For example: what happens when a team member falls sick (two of us got struck down during this sprint!)? Can anybody else in the team take over? If you realise you need more capacity, can you spontaneously increase the number of team members?
We all have lives outside work, so let’s try a rule where no team member needs to travel away from home for more than three days in any given working week. Let’s also try to avoid working late into the night or weekends on a regular basis – this should be seen as a sign that something is going wrong.
For a two-week sprint, I would highly recommend to have a kick-off meeting at the beginning and a round-up meeting at the end, with having all team member in one place in one room whenever possible.
When the sprint required travelling, we always made sure to organise a dinner and some social activities for those who where travelling in other countries. This was super useful. It was a good time to explore ideas in depth and in a low-risk environment (a great time to dive into a rabbit hole that we parked earlier, for instance). It was also an occasion to ask colleagues not directly involved in the sprint for their feedback, input and thoughts. This definitely helped to keep rhythm high and is part of the difference between a good team and a high-performance team.
To summarise: all these insights underline the importance of communication, within the team, within the department, within the organisation and with stakeholders. So never stop communicating.
So now you’ve seen the dirty laundry, stay tuned to read more about the outcomes of cdsprint2, which I’m really excited to share with you.