About this Case Study
Before I joined Ocado, its infrastructure department was 30 people. There were 4 teams, with 2 team leads, a product owner, a dev manager and a head.
The product owner had to represent the 100+ products within the department. The head had become a bottleneck for important decisions, vision and requirements gathering for various teams. The dev manager was also acting as a product owner and team lead, whilst handling disjointed stakeholders. The teams spent a large amount of time supporting legacy systems or stakeholders using their systems.
It was unclear how work was prioritised or broken up - how teams processed the right work at the right time. They were too busy to spend time on where changes could be made in an organisational way to help the situation. There didn't seem to be a common mission or vision that brought the teams together.
My plan for the first 3 months of joining the department was to listen to the people and get an understanding of the domain and the problems. Through one-to-ones with everyone in the department, I learnt that people were too busy doing real work to focus on personal development and that there was a lot of tension between teams - and even people within the same teams.
Team health checks were captured, but the safety of the environment was questioned, which could easily skew the results. Several department-wide workshops were run to get feedback and ideas of what was working, what needed to be done and how we could deliver it. A mission was created and the teams began to restructure to be more effective.
Education through presentations and discussions on various topics (eg scrum, kanban, 5 disfunctions of a team, our company’s values) started to expose the engineers to other ways of thinking and working. Most didn’t even know about our values of autonomy, collaboration, craftsmanship, trust, learn fast and leadership. Conference sign up is now higher than last year, with the head of the department signed up to multiple agile conferences; attending some training for the first time in years.
Weekly communication started to go out to the department from the leadership team and we tried to use a kanban board to visualise and manage our work. I even ran an experiment with the Unix team to do daily stand-ups, which proved to be hard work.
However, the improvements soon began to slow down. Our WIP was way too high, our initiatives were stuck in circular discussions and communication started to break down; we had 2 people start without any notice from the recruitment team and nowhere to put them! Leadership was burning out and we had no plan for unblocking ourselves or freeing others up.
This is where we are now. The next steps are to create formal team processes to protect teams from distractions, like doing unnecessary technical work or deploying faulty systems, and focusing on the most valuable work to deliver now. From there, a built-in improvement mechanism will be encouraged, through continued education and exposure to various agile principles. Stakeholder engagement will also be supported, through workshops and regular demos. These are obvious organisational steps, but not when applied to the mentality found within infrastructure departments, especially when some of the most technical leaders argue against anything labelled as agile without even trying to understand it.
I believe these approaches are rare within infrastructure departments. I see a lot of potential for agile to be applied in various ways and hope that there will be many learnings that people in infrastructure management can use to transform their departments into more efficient units.
About the Speaker
I am a development manager, with a software development background, who now supports 4 infrastructure teams. I have worked at Ocado Technology for 11 years and have been a developer, team lead, product owner and various specialist roles. My passion is getting teams to flow better and helping them to realise where and how this can be done.