Last week I ran a fully remote innovation sprint. I'd been planning to run one for some time, but in my head I'd always pictured it as an 'in the room' activity probably involving post-its, and pizzas. Having made some key hires recently it felt like a group activity was needed to bring the new team together, even if on this occasion this meant virtually rather than physically, and an innovation sprint proved to be a constructive way to achieve this.
The Importance of Promoting Innovation
In recent years the promotion of innovation has become a real focus for companies seeking competitive advantage. In fact a 2020 survey of 750 corporate CEOs and almost 800 other C-suite executive revealed "Creating a more innovative culture" to be the third most important priority for both the European and North American responders.
Building such a culture is hard, and has many pitfalls. In my post "The Innovation Silo" I discussed the perils of restricting innovation to a few key roles and the risk on motivation for others. If the development teams feel that they are just being asked to overcome the practical challenges in delivering other people's ideas and prototypes this can be demoralising. It's important in promoting an innovative culture that everyone feels part of the innovation, so group activities and ideas gathering are important to give everyone creative input into a product.
A former colleague had first introduced me to the idea of 'Innovation Sprints' - where a team decide on and take on an innovation task on a fixed timescale in the form of a compressed agile sprint - a couple of years ago. This was something I'd wanted to try and so was pleased when the CEO and CTO in my current company were also keen to try this activity. Having made some key hires late last year this felt like a great opportunity to bring the new team together on an activity and provide some much needed team building in this period of forced remote working.
Setting off on the right foot
With any workshop based session, the kick-off is vital. People’s time is precious and to avoid skepticism they need to understand why they are involved and the what is expected of them from the start. Having all attendees connecting in remotely made it even more important to get everyone engaged with the activity to maintain momentum while working apart. With this in mind I invested more preparation in this session than I perhaps would for a physical workshop. The key elements of the kickoff were:
- Why we were running the session. It seems obvious but when bringing such a wide variety of roles together and asking them to commit their time to a venture, it's important that everyone is clear why we're in the room and bought into the value of it.
- How we would run it. This included a rough agenda (in our case covering 4 days) and also details of the channels and means of communication. For a physical on-site session a brief agenda would have been enough, but the remote element meant that it was more important for people to understand where and how to communicate and capture their findings.
- Presenting the challenge. Innovation loves challenges, so a great way to present a subject for innovation is in the form of a challenge. I showed a video recording of a user research session where the subject explained how the right tool had grown to become the focal element in her team's weekly decision making. I then gave an open remit to the attendees to come up with ideas to help meet the equivalent need for users of our system. The challenge was literally a blank canvas to create a team's go-to place for weekly status reviews.
- Gather ideas. Innovation isn't easily forced 'in the room' - inspiration tends to be more forthcoming when people have time to process the problem and then come together to make creative connections. With this in mind I'd prepped people beforehand with some vague details of the focus of the challenge to prompt some offline thinking. After presenting the challenge I gave folks 15 minutes to think, discuss and share ideas of how we could help the subject of the video achieve her goals.
- Prioritise and target. In the absence of 'in the room' dot voting on Post-its, I collected ideas via Teams chat and added to a mindmap via screenshare. I used a Microsoft Form with a sort-order question type to allow everyone to vote on the ideas. The resulting top priority was something that overlapped very heavily with a development that was already scheduled for prototyping in the next full sprint. We wanted the innovation sprint to be a separate, self-contained effort so we agreed instead to progress with the next priority item.
This kick-off session ran for 2 hours, which felt like a reasonable duration to ask all members to attend. By the end of that time we had a clear target for delivery along with company-wide buy in on what the development team would be doing for the remainder of the sprint.
Getting things done
Off the back of the kick-off session the development team created a top level backlog item and collectively broke this down into tasks to share across the team. This involved a mixture of concurrent research and development activities.
- Researching and user testing options for data and visualisation to help answer key questions
- Standing up an API to serve data
- Selecting client-side libraries and assessing both for rapid prototyping and potential production use
- Exploring how to gather and aggregate the necessary data
- Exploring production systems to confirm assumptions around the shape of customer data and identify anomalies.
Our intention was to establish a narrow working prototype if possible, but with a priority to capture learning around limitations and challenges that we'd need to tackle if taking the capability into a production feature.
After one day it became clear that, while researching different options was valuable we also needed to decide on an initial target design if we were to get a capability prototyped in the time available. We therefore mocked up a wire-frame of the best options we'd identified to that point, and geared development towards it, while concurrently doing rapid usability testing on the design with internal stakeholders to identify potential refinements.
By the end of day three we had the basic capability up and running and had iterated the visualisations based on the feedback. This left day four for final adjustments and writing up all of the learning that we'd gained from putting the prototype together.
As a final step in the process we brought the whole company back together for a demo and review. As well as reviewing the prototype, each member of the team presented on the contribution they had made to the activity and the learning that we'd gained.
What went well
Despite having run many innovation workshops this was the first time I'd used a full innovation sprint format, remote or otherwise, and I was pleased with the outcome. If I was to highlight the particular positives from the week they would be :
- Everyone was involved. We managed to get most people in the company involved at least during the launch and wrap up sessions. Not only did we get the benefit of their ideas but also got to show how innovation is part of our core strategy and that that ideas can come from anywhere. Also all of the dev team were involved in contributing to the research and final prototype.
- We gathered diverse ideas and prioritised. We gathered a broad set of initial ideas from across the business and identified a clear goal for the week from these diverse options that we developed into a working solution.
- We balanced development and learning. One peril of innovation is that it's driven too much by technology and not enough by learning. Alongside developing a prototype, we also incorporated elements of rapid feedback and refinement of the prototype even in the short time available and also captured and documented a number of potential challenges to overcome in progressing the idea.
- Running fully remote was better than partly remote. We have one member of the team who works fully remotely and sometimes he can be left out of the discussion if the rest of the team are in the same room. Having the session focussed on being fully remote actually meant it worked better for all participants.
What could have worked better
Despite a generally positive outcome there were elements of the innovation sprint which in retrospect could have worked better.
- It was hard to keep the whole development team involved throughout. There were some moments where members had completed their tasks and didn't have new ones to pick up. At the same time the developer iterating the front end constantly had a lot to do. I think this was a pitfall of working remotely - if we had been working together in a shared space I think that the sharing of tasks would probably have been more fluid. If I did the same exercise fully remotely again I would be careful to more explicitly break up and share out the development tasks to ensure a balance across the team.
- We still suffered from innovation silos. It's inevitable that certain roles will give more time over to thinking about innovation than others. It was clear that some of us, myself included, had already formed some strong ideas around the idea chosen and how parts of the experience might work. This made it hard for others to perhaps contribute as much to the creative part of the process as they would have liked. This is something I'll be wary of when we tackle this kind of activity again.
- It was hard to get our ops expert involved. As the innovation was primarily through an existing channel there was little need for new infrastructure, therefore the member of our team who specalises in this area found it harder to contribute. This is something that we can potentially address in future, such as by tackling a more cross-cutting challenge.
These certainly didn't diminish the value of the activity, but they are learnings that will go towards improving future sessions and making sure everyone gets the same rewarding experience out of it.
Summary
I'm now scheduling in innovation sprints at the end of every quarter. I'd like to think our end of Q3 one will be a very different affair where we all get together in the same room. This is not just to overcome the challenges we faced, but more importantly because it's a great team and I miss working with them face-to-face. Plus I also I missed getting to order in pizza which felt like a big loss. In a retrospective session after the sprint we all agreed that, while generally successful, we missed the buzz and the banter that would have come from working on the challenge in the same room. I wouldn't hesitate to run another innovation sprint remotely if I had to, and I'm sure we'd look to address the challenges we encountered in the one just gone. But let's hope that, for far more important reasons that these, by the time we run the next one these aren't things we have to worry about.
Post a Comment