Alex Howard Whitaker

Welcome to the Ocado Technology Webinars, where you can hear from the people building the ground-breaking, game-changing technology that powers Ocado, the world’s largest online-only grocery retailer.

In this webinar Alex Howard Whitaker, cloud services engineer at Ocado Technology, talks about the challenges and opportunities involved in adopting a cloud-first strategy using Amazon AWS.

Key Takeaways

  • When Ocado Technology decided to adopt a public cloud solution, the main challenges revolved around automation, security and microservices deployment
  • Ocado Technology used an Agile approach to cloud adoption
  • Constantly building for failure helped mitigate security and performance issues
  • The cloud adoptions strategy was shaped by a set of well-defined best practices and guidelines
  • The growing list of technology stacks made it clear that a managed services-focused platform provided the best solution for the team’s specific needs
  • Creating an environment where the cloud infrastructure and cloud development teams worked together ultimately improved the overall platform and the tools around it
  • Ocado adopted Amazon AWS for operational services and the Google Cloud Platform for data analytical services
  • Having a separate AWS configuration for each customer made data segregation easier to manage
  • APIs are a great way to implement access control for applications

00:46: Starting from scratch means there are many choices and there is no right or wrong answer

01:08: Ocado Technology wanted to use AWS for existing systems and had to take an Agile approach to its implementation

01:39: Adopting a public cloud solution brought questions around security and performance

02:28: The development team looked at various cloud success stories, including Netflix

02:49: In order to ensure consistent adoption, the cloud teams created a set of best practices and guidelines

03:36: Ocado chose to use managed services offered by a service provider wherever possible to accelerate development without any downtime

04:08: The systems created to manage the cloud were also hosted in exactly the same way as the cloud applications themselves

04:34: The cloud teams evaluated both AWS and GCP and found the former better suited for front-end, operational services while the latter more focused on back-end, data analytical systems

06:08: Amazon AWS provides a myriad of services and there was a lot to learn about their individual characteristics

06:28: The first AWS implementation was relatively simple and straightforward

06:59: The second attempt joined the network hub account with a VPN back end

07:50: The third configuration aimed to decentralize various end points to improve access speed

08:44: The cloud team learned a lot from deploying live applications into the AWS configurations, particularly around data segregation, service limits and throttling

11:53: In the fourth version of the AWS implementation, the Ocado Technology team used the information gained from live deployment to create a more flexible configuration that could scale easily

12:19: The new architecture was based on microservices that used APIs to ensure abstraction of resources

13:00: Using access control and tagging to create better permissions for AWS applications

15:40: The architecture of our deployment process included an app registry, cloud provisioning, AMI build automation, cloud formation scripts and more

17:25: Using AWS Elastic Beanstalk, Ocado Technology deployed 250+ applications over a choice of stacks (Java, Python, NodeJS) and servers

17:52: Concluding remarks

More about our webinars

You can keep up to date with the webinars by subscribing to our YouTube channel. This article provides clickable links that take you directly to the highlighted part of the video clip.

January 9th, 2017

Posted In: Blog

Tags: , , , , , , ,

Ali Major

In this blog I’ll show you how to create simple, easy-to-follow roadmaps for the whole team to buy into (and stick to!).

My roadmap philosophy is ‘plan to achieve specified deliverables over a defined time period. This plan is dynamic, and goal and data driven (measurable)’.

A few key points:

  • My roadmap is NOT completed in isolation but involves other Data Department Product Owners (POs), the Business and my development teams.
  • The Data Department roadmaps span a three month period (we call them seasonal roadmaps).
  • My roadmaps must take into account: legacy, new development, and support across multiple stakeholders.
  • It’s dynamic, kept up to date, and not hidden away.

My approach

Step 1: Time to think

In the month prior to the start of the new roadmap, I ponder what is it we should be working on to meet our Data Department, clients and Ocado Technology requirements. I create a draft and run it by my development team lead and the Business representative/s. This is all high level and, importantly, not the specifics of how we will do the work.

Step 2: Stop pondering, draw circles

After we, the Data Department POs, finish pondering, we schedule a circle session (I love this exercise). We each explain what we think we should be working on and jot this on a board in one or two words.

Where we have the same theme – for example, monitoring – we circle this with a coloured marker. Each colour represents one of our teams. We also discuss dependencies and mark these accordingly. At the end of the exercise we can gauge:

  • Range of work proposed and if we are trying to cover too much
  • Common themes e.g. we have lots of circles around monitoring
  • How many of these themes are dependent on other teams

Circle session

Step 3: Finalise and socialise

Next is to tweak and socialise the draft roadmaps with the development teams and relevant stakeholders.

During the finalisation process I do four more very important things:

  1. A retrospective on how we performed against our previous roadmap, and what lessons-learned we should concentrate on during this new roadmap.
  2. Story Mapping to break into epic and stories, the ‘how’ of achieving the goals and features (the Post-it note company must love the take up of Agile…).

Roadmap goals

Story mapping

  1. Once I have prioritised the themes, the team then rank the epics and stories into order for working on. Then we estimate time based on a comparison to other epics.

I disagree that this is a non agile approach. They are very rough estimations, done quickly. We will in the future groom the epics and stories to a Ready state when we get closer to needing to work on them. The estimation provides us with an idea of what we reasonably think we can commit to on this roadmap, for example we are asking the question can we do story C within the three months taking into account story A and B?

  1. Lastly we jot down story acceptance criterias AND we play some games throughout the process. I suggest Pictionary as it lets you know who not to work on your UI!

Encountered Problems

Sometimes I am in the difficult position where I know one of our key features is lacking detail to adequately break into epics and stories. And if it’s not clearly defined, we shouldn’t work on it, right?

In reality, sometimes you just need to get on with it, so below are approaches I’ve taken in the past to mitigate the issue. Remember to always keep the stakeholders in the loop, and the team must agree.

  1. Add feature to roadmap and allocate a percentage of time during the three months. We postpone breaking the requirement into epics and stories until I have the missing information. Then we storymap, estimate what we think we can fit in, and update the roadmap because (repeat after me) the roadmap is dynamic.
  2. Add to roadmap with target metrics but agree between all stakeholders that this may not be achieved. As more information comes to light we update the roadmap.
  3. Leave it off the roadmap, with stakeholder agreement to add it to the next roadmap instead.

A dynamic roadmap should not mean mission-creep

By ‘dynamic’ I mean it stays relevant. It is a living document and kept up to date. I use the roadmap as a tool to push back, but I don’t become inflexible. The highest priority tasks can always be done.

My roadmap means I can identify the opportunity cost (e.g. feature X won’t be completed), and I can measure what changed and what was impacted during and at the end of the three months. It is a balancing act.

What’s crucial is communication, communication and, one more time, communication. I make a call based on discussions with senior managers, the business and the development team. It is also imperative that once the roadmap is updated it is socialised again.

Only three months? What about the long term vision?

Focusing on longer terms goals, but delivery in small chunks with metrics to measure against, works best for us. It allows flexibility where technology or goals are shifting.

I know many disagree that a roadmap should be less than six or even twelve months. It’s important that my roadmap goals are linked to the Data Department’s long term roadmap or the long term Business requirements. Both my products and the Data Department have far reaching vision statements, so we know if we are heading down the wrong path.

What my roadmap looks like

I use Roman Pichler’s Go Template. It is simple and doesn’t come with preconceptions like a Gantt chart does.

I was so proud when, for the first time, I could cut and paste directly from the Data Department long term goals roadmap into my seasonal roadmap! It seems for many POs their roadmaps don’t have a direct correlation with the next level above, or the level above that etc.

Road map

Roman Pichler source on roadmaps: http://www.romanpichler.com/blog/working-go-product-roadmap/

To wrap up

A roadmap is a great tool, but you need to find what style and process works for your team. Keep it dynamic and refer back to it each sprint planning.

Measure your success and enjoy crossing out deliverables as they are done.

Ali Major, Product Owner

Read more Product Owner advice from Ali

January 5th, 2016

Posted In: Blog

Tags: , , , , ,

We all know that what developers want to do with their time is write code, but in Logistics Planning we took a whole week away from that. So why? And was it really worth it?

I began working for Ocado Technology in October. In this short time we have moved from basic principles to build a big-picture overview of our product that the team understands and buys into, and which adequately meets the complex business needs. This is how we went about it.

 

 

Challenges

Our journey started with a set of a challenges which included missing domain knowledge, new starters to the company, and the fact that the Logistics Planning was performed in a very large set of a complex Excel document.

We had to overcome these challenges in order to build a high level overview of our product and proceed with development effectively.

Additionally we did not want to replicate the existing Excel documents but rather provide a software product allowing users to perform the end to end actions. And just to make things more complicated, the development team is located in Krakow, potentially a real practical barrier when the business has its head office in Hatfield.

Team meeting

The Workshop

In order to build a mutual understanding of the challenges and to bring the development closer to the business, we organised a set of workshops with key users and the development team. Our goal was to create an environment where our combined brain power could be used to drive the product development, instead of relying on a single point of contact.

To start the workshop, we had to define the relevant group of people responsible for planning deliveries. During the workshop, Operations and Resource Planners explained how customer goods are delivered and planned. The business team highlighted the most important challenges and the frustrations during their day to day activities. Additionally the development team was able to ask questions to gain a better understanding of the problem domain.

Each workshop was finalised with a summary session, where the development team and I built a picture of the challenges. This included the processes that they are currently experiencing while using our systems, and the boundaries of what the system can do. When the set of workshop sessions were finalised, each development team member went for a half day visit at a CFC (our massive warehouses) to spend time with the planners, observe the way they work and experience their challenges.

The cycle of workshops took us a week, after which the whole team had enough confidence and domain knowledge to proceed with defining the Product Scope and Roadmap. The approach we took was to define a scope of work and concentrate on the end to end user actions and behaviour.

Workshop

Scope of Work

We kicked off our work on the scope with an aim to define and list all features and actions we thought our product should cover. We had a cycle of a sessions where the whole team thought of the functionality and reasons why we should (or should not) implement certain behaviours. The Product Scope brainstorm sessions focused on providing a product which would solve end users problems in line with defined product vision.

The whole activity took us three days. The outcome was: a set of updated mockups, a list of the features we want to provide, and a list of additional discussions and workshops we would like to have with the end users.

At this point the list (product scope) looked quite scary, so the next step for us was to define the strategy for our journey from the place we were, to the place we wanted to be. In other words we wanted to build a roadmap with backlogs which would allow us to build a great product.

The Roadmap

To drive the evolution of our product, we needed to look at the prioritisation of features according to their value to end users. The key outcome of this workshop was to align our priorities and meet the needs of our end users. This process enabled us to divide the entire product journey for Logistics Planning into multiple phases.

Each phase would be finalised with feedback sessions with our stakeholders, therefore planning required us to define the goal of each phase, and the user experience we want to bring.

The whole set of roadmaps activities allowed us to build a clear vision for every phase, and proceed with the first.

Conclusion

We believe that the time was well spent. By fully emerging the entire development team in the problem domain, we have not only accelerated everyone’s understanding but have also evolved and matured the product vision.

Similarly, the scoping session allowed us to look at feature development with a focus on the product as a whole, bringing consistency and coherency to our product from a logical perspective.

Is this anti-agile? We believe the opposite: by having a strong vision and structure to our work, we believe that we will receive more structured and constructive feedback. Having goals and a clear strategy on how to achieve them will allow us to react to change and unforeseen challenges in a more meaningful way.

The reality is that we have software engineers, not simply ‘coders’; what we really love doing is writing valuable code. Sometimes the best way to do that is to take a significant break from the keyboard!

December 16th, 2015

Posted In: Blog

Tags: , , , , ,

Scroll Up