Context
Coming from of a reactive approach to work tasks
Whilst working in the Sainsbury's Digital Design team, we spent a lot of our time reacting - rarely carving out time for personal projects or delivering against key objectives - it was always about delivering what other teams wanted from us if we could squeeze it into our already busy day.
To combat this reactive approach to work we trialled working in an Agile working method known as Sprints (or Scrum) in the Design team.
Sprints allow you to break up time into a set period (a sprint), only focusing on a set number of tasks based on an estimated capacity for that sprint. At the end of the sprint a review and retrospective are held which reflect on the sprint went - Did we work on the most important tasks? How much of our work couldn't have been planned for? Were our estimations of our capacity correct? What are the next steps we need to take? - This drives continuous improvement.
The Scrum Framework
Since moving to Sprints, the Design team had seen huge improvements to how we could prioritise, manage capacity and plan ahead.
THE PROBLEM
Translate Agile to a multi-disciplinary team
Following the success of Design Sprints, I was approached to establish Sprints as the method of working for the newly created multi-disciplinary DiCE (Digital Content & Experiences) team.The team consisted of 16 people across the following teams:
Design, Content, Optimisation, Product Content & Retail Media
Step 1
Discover
I spent time with the Head of Digital Content & Experience to understand his vision for the team, and how he thought Sprints would help achieve this. We discussed other solutions, ensuring not to limit ourselves to one solution too early.
We came to the following principles that the new team should follow:
Foster a culture of collaboration
Being able to collaborate on projects which cross between disciplines, whilst still being able to work on more team-specific work. With the scope to align with a wider group of stakeholder teams in the future.
Be clear about plans and priorities
Have a future plan of work which ladders up to the objectives and deliverables of the Digital division. With an ability to prioritise any new projects against this existing roadmap, to enable flex
Consistent improvement and learning
The team should improve their ways of working over time, adapting to changes (be that business or tech changes)
I began research into different methods of working for multi-disciplinary teams, talking to Agile coaches and larger teams throughout the business to understand the benefits and challenges of different ways of working.
Step 2
Define
Step 2
Define
I spent time with members across the entire team to explain the concept of Sprints, during these conversations we identified the benefits and drawbacks of the way of working for each of DiCE’s teams.
Some teams had on-going work which would never be ‘complete’. There were concerns around how to feed in work from external teams. How we’d come together as a team for collaborative projects.
Using these requirements I looked into various workflow management options, considering the pros & cons of each before settling on Jira as the best option for our team.
Establishing team responsibilities and likely cross-over points
Examples of some of the team requirements which were factored in
Step 3
Develop
In the spirit of Agile, I wanted to get a solution up and running as fast as possible - then focus on iterating on it to troubleshoot issues that arose rather than trying to spend a lot of time perfecting a process that might not work by the time we launched it.
I trained the team on Agile practices, how the Sprints would work and how to use Jira, inviting open conversation and feedback where the team felt things could be adjusted to better suit their needs. E.g. Creating an issue type for recurring (BAU) work to easily filter to tickets of this type.
In the spirit of Agile, I wanted to get a solution up and running as fast as possible - then focus on iterating on it to troubleshoot issues that arose rather than trying to spend a lot of time perfecting a process that might not work by the time we launched it.
I trained the team on Agile practices, how the Sprints would work and how to use Jira, inviting open conversation and feedback where the team felt things could be adjusted to better suit their needs. E.g. Creating an issue type for recurring (BAU) work to easily filter to tickets of this type.
Supporting documentation was provided with interactive workshops
During this time of developing the process I gave updates to the key stakeholders for the team, ensuring they were kept up to date on the development of the project and factored in any of their external considerations.
Step 4
Deliver
The DiCE team began working in Sprints, with myself running all of the rituals to ensure they ran smoothly to get everyone used to the process.
During the first few sprints the team focused on getting comfortable with the various rituals, and building a habit of using Jira to track their work. Utilising the Retrospective sessions I gathered feedback on how the team was finding the process, and made improvements to suit the teams needs.
The team's first retrospective was overwhelmingly positive
Step 5
Do it again
Due to the in-built iterative nature of sprints we continued to improve the process, with a rota for the ritual meetings to build the team’s confidence in them and run them how they saw fit.
A few of the improvements we made from the first few months of Sprints:
⏺ Migrating to a new Jira board in order to unlock further customisation options and greater alignment with the rest of the teams across the business using Jira
⏺ Predicting future sprint capacity utilising story point estimations and burn down charts
⏺ Trialling different lengths of Sprint from 2 weeks to 4 weeks
⏺ Separating teams into boards for easier management of tasks
⏺ Aligning on a issue hierarchy structure to keep teams aligned
⏺ Separating teams into boards for easier management of tasks
⏺ Aligning on a issue hierarchy structure to keep teams aligned
Conclusion
My takeaways
I learnt a lot from this project, about how to run workshops and training with a broader group of people. Ultimately this project strengthened my love for designing solutions for diverse groups of people. Here are a few of the key takeaways I had from this project:⏺ That responsibility should be delegated before it becomes overwhelming. There were certainly points where I felt I'd taken on too much with the entire fate of the team resting on my shoulders.
⏺ That not everyone is going to find the same things useful, and people learn in different ways and at different rates. During the project I found myself expecting more enthusiasm and engagement for the new way of working as they'd been so useful for me. It definitely taught me that there's not always a one-size fits all solution.
⏺ Don't try to do too much too fast. With the DiCE team being so new, I could have better managed expectations with external teams on how they would be feeding into the Sprint process - the DiCE team were still establishing their roles and remits, so some difficulty came with managing external teams expectations on how they could feed in project requests when the DiCE team itself didn’t know what they needed in a brief to get started.
⏺ That not everyone is going to find the same things useful, and people learn in different ways and at different rates. During the project I found myself expecting more enthusiasm and engagement for the new way of working as they'd been so useful for me. It definitely taught me that there's not always a one-size fits all solution.
⏺ Don't try to do too much too fast. With the DiCE team being so new, I could have better managed expectations with external teams on how they would be feeding into the Sprint process - the DiCE team were still establishing their roles and remits, so some difficulty came with managing external teams expectations on how they could feed in project requests when the DiCE team itself didn’t know what they needed in a brief to get started.
That's all folks
Thank you for reading
