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.
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
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.
Alex Voica January 9th, 2017
Posted In: Blog
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:
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.
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:
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:
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?
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!
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.
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.
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.
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.
Roman Pichler source on roadmaps: http://www.romanpichler.com/blog/working-go-product-roadmap/
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
Ali Major January 5th, 2016
Posted In: Blog
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.
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.
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.
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.
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.
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!
Lukasz Kucharski December 16th, 2015
Posted In: Blog