Growth Mindset in Software Development, a practical example
By
Ana Barbosa
Aiming for quality and perfection in a fast software development environment with Adidas on my feet.
View All Posts
I have been an Engineering Lead at FARFETCH since 2015. There are several engineering teams at FARFETCH and each one is responsible for the development of different services/products and is organised by business area or scope.
Those teams usually work with scrum but they have the autonomy to change their work methodology. My team used to work with scrum, like most of the engineering teams at FARFETCH at that time.
We used to work in 2-week sprints, following the scrum ceremonies for almost 2 years. Every 2 weeks we had our sprint refinement of the stories and tasks for the next sprint. At the end of the sprint, we held retrospective sessions to focus on what went well and what went wrong.
Here is an example of our sprint workflow:
The work we delivered at the end of the sprint was not always the one we had planned at the beginning. This meant we started having carryovers from one sprint to another which impacted the team's motivation and performance.
At that time the metrics we used to measure productivity were the number of stories delivered at each sprint and the sprint carryovers, as well as the number of stories that were not completed in one sprint and therefore left to the next one. In retrospective sessions, we reflected on these metrics and shared feedback within the team about the work achieved in that sprint.
This led us to start by committing to work at the beginning of each sprint and increasing the scope during its execution, leaving room for new priorities to be included as part of the sprint.
When the end of the sprint approached we were careful about adding more work to the sprint. We knew we could do more but we were worried about possible carryovers. This started to affect the team's spirit and productivity, so something needed to change.
On dailies, we started focusing on the stories, looking at the story that was closer to going Live, checking its status and assessing if there was any blocker to progressing the work.
We also reviewed our workflow development stages and established Work In Progress (WIP) limits for some of them. The WIP limits are a maximum and a minimum number of stories that should be at that stage at the same time - if the limits were not respected, they would be marked with a red flag. This way if the limits were at maximum or above, we would make sure that those stories were dispatched first until production, eliminating all the bottlenecks, before pulling new ones. If the limits were at minimum or below minimum it meant we needed to start some new stories.
One strategy we implemented to avoid reaching the maximum limit of stories (and resulting in a blocker because we had dependencies from other teams) was to start deploying those stories into production disabled, aligning the contracts and requirements with the other teams before we started working on them. This ensured we weren’t blocked at the work we needed to do and it meant we were ready as soon as possible to activate the feature in production when the work from other teams was ready.
Example of the workflow development stages:
With this new approach, we saw the team’s mindset begin to change. The team was more focused on unblocking and delivering the highest priority stories first instead of starting new ones, which meant we "Stopped starting and started finishing”.
In a few months, we noticed some improvements in our performance - the team was more committed to delivering value in small interactions in a short cycle time.
But the carryovers were still a barrier. Although we stopped focusing on this metric, the carryovers continued to exist, which was impacting the team’s morale. The team suggested that we stop working in sprints and start working on kanban, keeping a few scrum ceremonies and changing the concept of some of them.
At first, we kept the sprint planning meetings, using them to review and manage our backlog priorities and make sure it was up to date, but we eventually stopped these meetings since it became part of our daily work.
We decided to continue the refinement meetings, but instead of focusing on story refinements, we started refining the initiatives as a whole, breaking them down into high-level stories. The refinement of the individual stories was then done as part of our daily work and we included it as a new step for our development workflow. If there is a priority change or a new priority initiative, we schedule some time to refine it and plan its work instead of waiting for the refinement meeting to do it. This allows us to be more flexible with changes to priorities, as we can reflect them on our backlog on a daily basis.
We also kept the sprint review meetings, renaming them to team reviews, but only when needed - for example, when a major initiative is fully delivered or when we need input and feedback from interested parties.
In retrospectives, we began to measure our cycle time and our throughput and started reflecting on outliers - stories that have bigger cycle time than the average - and what we could do to improve them, instead of focusing on carryovers. Some of the actions we took from these sessions were to break down the more complex stories into smaller ones whenever it was possible and release each one into production as soon as they were ready, even if it meant that we were going to do multiple releases per day for the same product or service.
We ended up working on a Hybrid solution - kanban with some of the scrum ceremonies. The next diagram is a representation of our daily work:
All these changes helped the team to improve their cycle time, their performance and also their motivation. Since we made the changes, we have already reduced our cycle time by 85% and increased our throughput by 88%.
I believe that the team’s mindset change was the key factor for our improvement -without their commitment and willingness to improve, this would not be so easy.
If you’re considering changing your team’s way of working, my advice is:
Those teams usually work with scrum but they have the autonomy to change their work methodology. My team used to work with scrum, like most of the engineering teams at FARFETCH at that time.
We used to work in 2-week sprints, following the scrum ceremonies for almost 2 years. Every 2 weeks we had our sprint refinement of the stories and tasks for the next sprint. At the end of the sprint, we held retrospective sessions to focus on what went well and what went wrong.
Here is an example of our sprint workflow:
The Challenges
FARFETCH is an agile company that is constantly changing, adapting to the evolving needs of the market. One of the challenges my team faced was due to this constantly evolving environment, meaning that our priorities always changed within the 2-week time frame.The work we delivered at the end of the sprint was not always the one we had planned at the beginning. This meant we started having carryovers from one sprint to another which impacted the team's motivation and performance.
At that time the metrics we used to measure productivity were the number of stories delivered at each sprint and the sprint carryovers, as well as the number of stories that were not completed in one sprint and therefore left to the next one. In retrospective sessions, we reflected on these metrics and shared feedback within the team about the work achieved in that sprint.
This led us to start by committing to work at the beginning of each sprint and increasing the scope during its execution, leaving room for new priorities to be included as part of the sprint.
When the end of the sprint approached we were careful about adding more work to the sprint. We knew we could do more but we were worried about possible carryovers. This started to affect the team's spirit and productivity, so something needed to change.
The Change
One of the first things we did was to stop focusing on measuring the carryovers. Instead, we started measuring our cycle time and our throughput on a monthly basis and focused on improving it. Cycle time is the time that a user story or task takes (normally in days) from the start of the development until the moment it is released into production. Throughput is the number of stories released into production for a given period of time, in our case in one month.On dailies, we started focusing on the stories, looking at the story that was closer to going Live, checking its status and assessing if there was any blocker to progressing the work.
We also reviewed our workflow development stages and established Work In Progress (WIP) limits for some of them. The WIP limits are a maximum and a minimum number of stories that should be at that stage at the same time - if the limits were not respected, they would be marked with a red flag. This way if the limits were at maximum or above, we would make sure that those stories were dispatched first until production, eliminating all the bottlenecks, before pulling new ones. If the limits were at minimum or below minimum it meant we needed to start some new stories.
One strategy we implemented to avoid reaching the maximum limit of stories (and resulting in a blocker because we had dependencies from other teams) was to start deploying those stories into production disabled, aligning the contracts and requirements with the other teams before we started working on them. This ensured we weren’t blocked at the work we needed to do and it meant we were ready as soon as possible to activate the feature in production when the work from other teams was ready.
Example of the workflow development stages:
With this new approach, we saw the team’s mindset begin to change. The team was more focused on unblocking and delivering the highest priority stories first instead of starting new ones, which meant we "Stopped starting and started finishing”.
In a few months, we noticed some improvements in our performance - the team was more committed to delivering value in small interactions in a short cycle time.
But the carryovers were still a barrier. Although we stopped focusing on this metric, the carryovers continued to exist, which was impacting the team’s morale. The team suggested that we stop working in sprints and start working on kanban, keeping a few scrum ceremonies and changing the concept of some of them.
At first, we kept the sprint planning meetings, using them to review and manage our backlog priorities and make sure it was up to date, but we eventually stopped these meetings since it became part of our daily work.
We decided to continue the refinement meetings, but instead of focusing on story refinements, we started refining the initiatives as a whole, breaking them down into high-level stories. The refinement of the individual stories was then done as part of our daily work and we included it as a new step for our development workflow. If there is a priority change or a new priority initiative, we schedule some time to refine it and plan its work instead of waiting for the refinement meeting to do it. This allows us to be more flexible with changes to priorities, as we can reflect them on our backlog on a daily basis.
We also kept the sprint review meetings, renaming them to team reviews, but only when needed - for example, when a major initiative is fully delivered or when we need input and feedback from interested parties.
In retrospectives, we began to measure our cycle time and our throughput and started reflecting on outliers - stories that have bigger cycle time than the average - and what we could do to improve them, instead of focusing on carryovers. Some of the actions we took from these sessions were to break down the more complex stories into smaller ones whenever it was possible and release each one into production as soon as they were ready, even if it meant that we were going to do multiple releases per day for the same product or service.
We ended up working on a Hybrid solution - kanban with some of the scrum ceremonies. The next diagram is a representation of our daily work:
All these changes helped the team to improve their cycle time, their performance and also their motivation. Since we made the changes, we have already reduced our cycle time by 85% and increased our throughput by 88%.
In Retrospective
There is always room for improvement, so we need to continue evolving this growth mindset and be critical about the work we do. We should also continue adapting the methodologies and our ways of working in small iterations, allowing us to change and adapt if something goes wrong along the way:I believe that the team’s mindset change was the key factor for our improvement -without their commitment and willingness to improve, this would not be so easy.
If you’re considering changing your team’s way of working, my advice is:
- Don’t be afraid of change
- Adapt the methodologies to your team’s reality
- Do it incrementally, step by step, reviewing the impacts of each step before moving to the next one, introducing as few as possible changes at the same time
- If one step didn’t work, review and improve it or even discard it, but don’t give up
- Always focus on improving the team’s work, looking into the bottlenecks and coming up with ideas and solutions to overcome them
- Listen to your team’s ideas, put them into action and let your team be proactive about them
