Agile Teams: Sainsbury’s

How often do you get the chance to hear how a team adjusts to using Agile practices and become more agile, sprint by sprint?

Well now you can! We worked with a team over 11 x 2 week sprints, helping them to start their agile journey. We captured the key notes from their sprint reviews which allowed us to demonstrate the changes that a team is likely to go through in the very early stages of their agile journey.

Here is the team’s story told through the notes they captured along their journey. The big thing you will notice is that changes in their behaviour often took 4-5 weeks to have an effect on the work they were doing. You will also see that the team’s investment in Agile did pay off, but you have to keep the faith!

The Assignment:

Will Sambrook of Akenham was asked to work with a data centre team as their Agile coach and help get a highly complex hardware engineering initiative across the line.

The team worked within a larger division that was adopting Agile and Product Life-Cycle Management and was moving away from traditional waterfall project management approaches. The problem was, this was a big nasty change initiative (that felt very much like a traditional project) and needed to be delivered to allow the division to work in a more Agile way!

The initiative is best described as data centre consolidation and data migration. The specific details of the initiative cannot be shared but that is not the point of this article. It is more to show a team’s reflections as they started to use Agile practices and find themselves becoming more Agile.

Starting to think Agile:

The team started by creating a roadmap and backlog for the initiative and opted for 11 x 2-week sprint cycles.

The backlog was structured using ‘Epics’ and ‘User Stories’.

Epics were considered to be the key working parts of the projects.

Epics were then broken down into User Stories. Stories were considered to be elements of the initiative that could be said to add value to the end user, as the end user would describe it.

The aim was to create stories that could be completed in a 2-week sprint.

Each sprint cycle contained:

• A Sprint Goal that set out the team’s ambition for each 2 week sprint
• A Sprint Planning session on the first Monday morning of each sprint – this was to plan the the delivery of the stories chosen for the sprint
• 15 Minute Stand Up meeting every morning throughout the sprint – everyone focused on what’s they were trying to achieve and potential blockers they were trying to overcome. This was particularly useful as often someone in the team was able to help remove the blocker before large investments of time were needed
• A Backlog Refinement session on the 2nd Thursday of each sprint – this looked at getting stories ready for delivery in the next sprint, and the one after
• A Stakeholder Review with key stakeholders was held each sprint. Internal stakeholders one sprint, external the next sprint
• And lastly, but most importantly, a Retrospective (retro) on the 2nd Thursday of each sprint – this time was used by the team to reflect back on what had gone well over the last sprint, and what could be improved. The notes from the retrospectives are shown below and show the highs and lows the group experienced along its journey

Retrospective Notes:

The notes below reflect the journey the team took when adopting Agile and learning to work with Epics and Stories and to work in Sprints.

The notes are taken directly from statements made by the team during the retros and show the progression the team made in adopting Agile practices and overcoming challenges as the initiative went on.

Sprints 1-4: Learning the ropes

We used the first 4 retros to focus on working in Sprints and creating User Stories that could be delivered within those Sprints. We were also working remotely during lockdown so created an online sprint board on JIRA (activity tracking software and virtual sprint board).

• The introduction of JIRA has given structure and visibility to morning Stand Ups
• There is a lot on the board so difficult to see everything unless swim lanes for each activity are used – maybe this is just a reflection of the amount of work on the board but something to improve on if we can
• We could improve the size of stories and sub-tasks
• It would be good to integrate task lists with JIRA
• Need to make time to review and update things
• Maybe we could get cleverer on the next sprints of prioritising what needs happening when. Likewise, it would be good to get better view of the dependencies that are effecting our work
• In terms of working together – there has been good comms.
• Sprint planning followed by team planning seems to be working.
• Stand-ups overrunning: Everyone needs to focus on the most important stories/subtasks – of those, when is this expected to move across the board and/or what is blocking it
• Key focus has got to be about prioritising – everything we do must be to support the sprint goals
• [Backlog Refinement] Things taking longer than we hoped from others. Keep looking ahead to warm things up ready for action
• [Backlog Refinement] Check assumptions – don’t assume people understand what you want as an outcome
• [During Planning] Identify potential blockers and flag early

You can see from the above, that the following practices really helped the team get itself organised by:

• Making their work visible using a virtual board
• Right-sizing stories
• Checking assumptions, of both delivery times, communications and dependencies that effected the team’s ability to meet deadlines

Sprint 5: A big point of reflection and correction

The team started to see positive results from being a ‘bit more’ Agile, but still had a lot of reflection and correction to do:

• We’ve got better at checking assumptions
• Things are still taking longer than they should – we are not getting daily updates, sometimes people aren’t even responding to requests, having to chase – difficult to have confidence that things are getting done. Taking up too much time.
• We are regularly adding issues to a sprint after the sprint has begun. Is there a way of tracking this (labelling) that can help show what we’ve added, which we can reflect on: eg. Are they unknowns, dependencies, steps we might have missed or new advice?
• Stories are maybe too high a level – therefore they are active for 2 or more sprints. How do we right size these?
• Because of the above, the board doesn’t reflect progress

The big thing here was not letting up – celebrating progress but understanding that this was not how we wanted to operate in the long term.

Sprint 6: showed the breakthroughs arising from Sprint 5

Sprint 6 was a bit of a turning point. The team started seeing the benefits of their reviews and their corrections:

• Sprint 5 was a big learning curve for us. Now able to bring [the 3rd party] with us to follow our process. [The 3rd party] are being more proactive
• Less unknowns
• Feels like we are now working towards specific goals
• Able to see further forward
• Daily stand ups with engineering working better – more visibility and less duplication
• The Sprint Board is getting a bit messy – need to spend time clearing out
• We need our budget and costings broken down [to match the board] – what we are paying for [in a sprint] is different from actual

As you can see, that work on backlog refinement not only worked for the team but people they interacted with, allowing them to more clearly se what we were trying to achieve.

Sprint 7: the team started to find a real rhythm and gaining traction in the business:

By Sprint 7, the work the team had been doing on managing their stakeholders, particularly using Stakeholder Reviews, was starting to pay off:

• We seem to have built a lot of confidence in the business
• No big changes: good pace
• More diligence will be needed in sprint 8
• Able to look ahead better now – need to use this to build last 3 move groups
• People we are working with are being pushed hard – just need to be aware of that: pressure is finding its way down to a few people. We need to be mindful of this during planning

It is interesting to look back and reflect on what a significant impact that stakeholder management made. It was one of the key success factors of the initiative and yet its easy not to focus on it when the returns aren’t immediate. It took 14 weeks of investment of time and effort to start to see a return. More importantly, the return got stronger and stronger – the more progress we could show, and the reasons for it, the more the stakeholders could see how they could get involved.

Sprints 8 – 10: A time to refine our approach, challenge assumptions and ‘learn’:

During sprints 8-10, retros were used to dig into challenges that had kept reoccurring. The idea was not just to finish off this initiative but to look forward and learn for future ones. The key learning points were:

• Throughout the initiative there have been a lot of unknowns which is difficult when you’re moving at pace – finding time to get into these has been tricky
• We’ve assumed too many times that existing infrastructure would work – but keeps needing a lot of rework. This coupled with other issues such as VLAN clashes has been tough. When we stopped assuming, things got better
• Every sprint has seemed like a mini discovery
• Each sprint we may be using the same engineering resource but we shouldn’t assume they need the same time to plan and prepare [they could need more or less than they did last time]
• We tend to focus on the 1st week [of the 2 week sprint] in our sprint planning as there is usually a big move at the end of it. Need to keep an eye on week 2
• Patching is consistently costing us time and has done on each sprint. Definitely a lesson to take forward: Rack work has been ahead of schedule each move but then patching drops us back
• Defining port configurations and what VLAN the services require early is key
• Port Capacity also a key issue

Whilst there is a lot of technical information in here that isn’t relevant to this article, hopefully you can see the big learning points are that:

• The backlog refinement sessions worked best when we picked through any assumptions. This was tough at times, as it feels a slow process, but it paid huge dividends
• During sprint planning, it is really easy to spend time planning for the early part of the sprint and ignore the rest – keep an eye on this is key to good sprint management
• Lastly, understanding where issues are likely to occur and building in these factors is key – hoping the same issues wont show up next time, without good reason, is dangerous

Sprint 11: Final retro and lessons learnt:

The retro at the end of Sprint 11 was used to step back and celebrate. The key points were:

• The team’s approach was held up as a ‘blueprint’ initiative for data centre consolidation and migration within the organisation
• The team only had 12 weeks of actual move time – clearing everything out of one particular data centre – and this was achieved alongside significant business objectives, including: cost savings, carbon savings, and modernising of the technology estate
• 10 out of 10 move groups were successfully completed as planned and without adverse effect felt by the business
• The initiative was carried out using Agile practices which were alien to the team at the beginning of the process. It would be wrong to say the team was truly Agile by the end, but they had definitely made great progress and were on an exciting journey
• During each sprint cycle the team had a retrospective that captured the challenges the group were facing at the time. The team looked at ways to overcome these in future sprints. The investment of time in each sprint ceremony – Backlog Reviews, Sprint planning, Stand Ups, Stakeholder Management and Retrospectives – paid off. It could sometimes take weeks to see a return so rigour, discipline and keeping the faith are vital to factors in achieving a return on investment
• The group faced a number of ‘known’ and ‘unknown’ opportunities and risks. These were captured in order that future Data Centre consolidation and migration initiatives could learn from the experiences of this team

Hopefully you can see how the team embraced Agile working practices and the results they achieved. You will also see that shifting to this way of working takes dedication, perseverance and really being able to use the sprint ceremonies to best effect, which is of course were we come in!