4 steps to create trust within your business following the Lean principles
The surprising truth about how a team can be more reliable while preserving Agile ways of working.
At Gousto, everything is moving really fast. This is why business agility and lean ways of working are crucial for us to be successful. As with many other companies, we always try to learn from our mistakes and aim for continuous improvement. At the end of last year, we held some project retrospective to identify problems when executing big deliverables.
What came out of that was a list of issues including big bang releases, cross-team dependencies, fixed scope, manual testing and late engineering engagements. This ultimately led to unpredictability and lack of trust — sound familiar?
Luckily, as we’re growing quickly, we’ve immediately had multiple opportunities to improve on the way we deliver big initiatives.
The changes we’ve made affect all the different stages of our software development lifecycle, from product ideation to delivery, including how we get feedback from our customers to close the loop. Let’s take a closer look.
Step 1 — Product ideation and discovery
In order to own the solution, the engineering squads are involved early, when a new product is first conceptualised. Once the concept is defined, Product Managers are responsible for creating a story map and planning how to deliver the product in different phases.
Software developers are subject matter experts, that’s why it’s crucial to involve them early and empower the team to make the best decisions
The engineering team, then conduct architectural sessions and make a first round of high level estimations. This allows the PMs to make informed decisions on what to prioritise first in order to release early value to our customers.
Early engineering involvement is key to empower the team. Software developers are subject matter experts who bring a unique perspective which may critically influence important decisions.
Step 2 — High level estimations and burn-up charts
There are different industry methods for providing high level estimates, t-shirt sizing being one of the most common. However, for the purpose of estimating projects, at Gousto we use relative points estimates. As these are high level estimates of epics, as opposed to low level sprint tasks, we refer to the points as “magic points”.
The team order the epics (high level backlog items) from smallest to largest, and then group those of similar size. The engineers then estimate the groups relative to one another using magic points.
Magic points are Fibonacci numbers times 100, e.g. 100, 200, 300, 500, etc. We use this numbering system to clearly distinguish high level estimates from low level sprint estimates.
With the relative size and value of the epics, the Product Manager and team are able to prioritise the work in different phases, with each delivering value to the customers.
Once the first epics are complete we can begin to understand our velocity in magic points. Using this we can begin to predict a delivery window via a burn-up chart.
Depending on the phase of the development, the velocity of the team may fluctuate and project scope may not be thoroughly understood. In order to represent this uncertainty on the burn-up chart, we use a concept of confidence that results in a cone of uncertainty in the chart. This cone is expected to shrink as the team learn more about the project and improve their ways of working together.
Burn-up charts help to create transparency and alignment, therefore increase the level of trust from the rest of the business
Burn-up charts are not an Agile version of Gantt charts — instead they are a tool for transparent communication within the team and with the stakeholders. This allows everyone to align, identify issues and put remedial action in place where necessary.
Step 3 — Scoping and refinement
During the development of the project, the squads go through two different types of activities that help them understand what’s coming up: scoping/design sessions and backlog refinements.
During the scoping sessions, we look at the work that’s coming up next, e.g. the next phase of the project. This involves understanding and defining the high level system design and architecture, but does not include low level code definition.
We also break down epics into smaller stories and estimate in weeks or Sprints.
During backlog refinements, on the other hand, we look at the next one or two Sprints, go low level to understand the codebase, break down the stories into smaller tasks and estimate in story points.
To help scoping and refinement, we use a separate Kanban board to track the tickets through the refinement process until they are ready for development. The teams alternate between individual and group refinement sessions. This allows both time for individual scoping and analysis, as well as group refinement and estimation. This maximises the chances of stories and the necessary implementation being well understood before they are pulled in to sprint.
We like to think that we’re following one of the Lean principles¹ that says decide as late as possible, identifying the last responsible moment to make a decision. So, while we do just-in-time estimation for sprints, we also look at the design system ahead.
Step 4 — Learning from our customers
Following two more of the Lean principles, deliver as fast as possible and amplify learning, we try to learn from our customers as much as we can. As a result, the feedback loop is shorter.
In order to achieve that, we use a mixture of A/B, multi-variant and painted door testing to assess customer interest and validate hypotheses.
To recap
The image above shows both the sequence of events and those sequences in parallel. As we’re developing one set of tasks we’re ideating, scoping and refining the next set.
However, as we also want to get feedback and learn from our customers, the best representation is actually the one below, a loop.
The next phase of the journey…
As a result of these ways of working with big deliverables, we’re already making our stakeholders happier, giving them more transparency and visibility and improving the level of engagement. This is already helping us to be more reliable, manage the expectations and ultimately get more trust from the rest of the business.
Stakeholders are already happier and more engaged thanks to more transparency and visibility
We’re now looking at ways to further improve our ways of working. For example, getting more involvement from the relevant stakeholders from the beginning, shifting from an output to an outcome mindset and empowering the teams to define how they’re going to meet their objectives.
In order to do this, we’re experimenting with one purely cross-functional team. We have created a cross-functional retention team which includes people from our marketing and proposition teams, as well as web and mobile engineers, product managers, designers and data analysts. This pod, as we call it, share a single objective, and work together to define opportunities, brainstorm tactics and deliver experiments which will help them to achieve their desired outcome.
How do Agile and Lean work for your company? Please share your insights in the comments below.
If you wish to know more about what we’re up to at Gousto, please check out our tech blog!
[1] Lean Software Development, Mary and Tom Poppendieck
[2] The Lean Startup (Eric Ries)
