Helping a team that is struggling to deliver
Issue No. 2
Sunny greetings from Thailand!🏝
This week's post is coming to you late as I wrapped up my time at OCUS last week (I am still drafting a post about what I learned from the previous year as their CTO). So, I've been travelling and taking a little break with my family before I start my next role in a couple of weeks (more in a future issue).
💬 In this issue, I cover:
- How to react to a situation where a team is struggling to deliver.
- Early warning systems you can put in place to detect if delivery is slipping.
- Dealing with a slow down in delivery.
- Some practices that can help a struggling team.
How can you help a team that is struggling to deliver?😩
I originally wrote this for the same skills test I mentioned in last week's newsletter.
❓What would you do in this situation?
Imagine this scenario in a hypothetical B2B SaaS business.
The Onboarding Team is responsible for the new customer signup site for our imaginary company. Its mission is to guide users through delightful and frictionless onboarding to maximise conversion rate and customer satisfaction.
The team is involved in a broader company-level initiative to optimise the acquisition funnel, with Growth upstream and Ops downstream.
The team includes:
5 Product people
- 1 Product Lead managing 4 Product Managers
20 (+ 5) Tech people
- 1 Backend Lead managing 10 Engineers + 3 working on customer authentication, a separate feature assigned to the Onboarding team.
- 1 Frontend Lead managing 8 Engineers + 2 working on customer authentication.
They work on several streams:
- Features and Improvements provided by Product
- Bug fixes and Scaling, prioritised by Tech ("Scaling" means "nothing breaks when we have ten times as many customers & engineers"; it's broader than "paying off tech debt")
Both Tech Leads are experienced and trusted by their management to operate with little supervision without running into critical problems. In addition, the teams have a good mix of seniority.
However, multiple signals reveal that Onboarding is struggling to deliver.
The Onboarding team has many projects that are late by 20% to 50%; the reasons aren't always clear. They have difficulty keeping their inventory of bugs under control; this appears to be caused by a relatively high flow of new bug reports. Their code base is pretty old, and it's unclear how much progress they're making in paying off tech debt.
They started a project to redo a new customer flow. (The product supports both existing companies and newly-created companies.) This project doesn't carry all that much complexity, apart from a mix of online and offline workflows, which the team has done before, and being a new separate app, which they haven't done recently.
The project was initially estimated at two months. However, six weeks into the project, the team communicated six weeks of delay for the delivery with significant cuts to the scope.
- How do you react to this situation in the short and medium/long term?
- Specifically, what system would you implement to detect earlier if a deadline is at risk?
- How do you get that team to deliver the right quality at the right time on all workstreams, with good team morale? (Hint: where is the waste?)Please highlight good practices and traps they may encounter. Explain how to monitor success.
🚨Initial Reaction
My initial reaction to this situation would be to do Gemba walks with the team to try to uncover what has been causing us issues:
- Understand the team's Charter and Mission and any operating principles in place.
- As this company uses visual management, I would want to visually understand what the team is working on by looking at their Kanban board. I would also want to know what work looks like upstream and downstream to the team.
- Is the team working on just one initiative, or do they have other work in progress?
- Are there any apparent bottlenecks where work is accumulating?
- What is the mix of work between the two streams of "features" vs "bug fixes and scaling"? How much time/resource is allocated to each and how fast they flow through the system.
- Understand how the "Company Creation flow" project has been broken down, where the dependencies are between the Frontend, Backend, customer authentication, and any other teams.
- I would want to understand if the delays are due to this being a separate app or not.
- Did the team build a skeleton and have CI/CD working from the start of the project to deploy it to production in "dark mode," or are they going to integrate it and deploy it at the last minute?
- Is there a need for more of a particular skill set in the team? (e.g., not enough Front or Back engineers)
- I would dive into some of the team's different types of bugs. Do they come from a particular area of the codebase?
- Understand what the user level metrics look like for the team.
- See how long the team's Pull Requests (or Merge Requests in GitLab) are open before they are merged and how long their code takes to be deployed to production.
- I would also want to understand the team's definition of ready (DoR) before starting work and their definition of done (DoD) for completed work.
🕸 Systems for Early Detection
In the medium and long term, I would work with the team and their leaders on their approach to problem-solving and retrospectives. I would try to help them address the issues we encountered during our Gemba walks.
A big red flag is that the team hasn't been signalling early enough that they might miss their commitments. Secondly, they don't seem to be able to rectify the situation on their own. So, I would want to understand if the team has an "Andon Cord" process in place and, if so, why they hadn't been using it. Finally, I would want to ensure that someone experienced can work with the team to increase their autonomy.
I'm a big believer in continuous improvement (I believe the retrospective is the most critical ritual in Agile). Additionally, lasting change means the change has to come from inside the team. Therefore, I would ensure someone provided coaching on how to change their team from the inside.
In terms of what controls would I implement to detect problems earlier if a deadline is at risk, I would:
- Make sure the team is delivering work in small product increments that are a maximum of three weeks long. (see post on sustainable delivery in Engineering for more info. Three weeks seems to be the limit of a person's ability to estimate their work accurately).
- If possible, track the team's lead time and how many deploys they do to production to spot trends. See my mention of metrics from last week's post.
- Weekly product demos of working software are a powerful way to visualise our progress together. If the team are not doing weekly demos, I will ensure they started.
- Perhaps introduce simple reporting such as a tweet-length initiative description, current product increments in progress with their RAG status, and a table of risks. A report that doesn't take more than 15 minutes to write and 5 minutes to read is sufficient.
- Track the amount of unplanned work that team does and regularly inspect unplanned work to understand its root causes.
Finally, I would ensure we embed delivery best practices across the organisation in a more codified way rather than relying on folks learning these best practices from scratch in every new team by continuing to update the company's standards and having a training academy.
When I worked at Red Hat's Open Innovation Labs, we used an immersive training Dojo four to eight weeks long for new teams, but this could apply to existing teams that need a periodic refresh.
👌😊 Deliver the right quality at the right time with good team morale?
Question 3 was How do you get that team to deliver the right quality at the right time on all workstreams, with good team morale? (Hint: where is the waste?)Please highlight good practices and traps they may encounter. Explain how to monitor success.
Amongst other things, I believe that happy teams are teams that feel like they are making progress and having an impact. Conversely, team morale dips when they feel bogged down or stuck.
Team morale and productivity are impacted when there are many interruptions and a high percentage of unplanned work (in this case, a "high flow of new bug reports" is an indicator).
This team is impacted heavily by unplanned work and re-work, affecting their ability to make progress and have pride in their work.
The team's technical debt seems to be causing waste. Over time our assumptions accumulate, and while code behaves as we expect, we discover that our expectations were wrong. As a result, our velocity slows, and developer happiness decreases. We might have to consider investing heavily for a while to bring our product back into a state where we can quickly build with it again.
(for more on this, see the section Iterate and Invest in my post about sustainable delivery in Engineering).
A bad situation that teams can get stuck in is an accumulating bug backlog that slowly increases over time. It is like a frog in a bucket of water gradually getting warmer. Of course, it is possible to have zero known bugs when we ship. Still, it requires discipline in how we work and having good conversations in the team about our current situation and ways of working.
Places to check are our DoR (Definition of Ready) and DoD (Definition of Done) because these are critical control points for work flowing in and out of our system.
I mention a few good practices below in my post about sustainable delivery in Engineering. Some that would help here are:
- Maintaining two boards for the team's work and being very intentional about the time allocated to "Chores." If more and more time is required to do "Chores," the team can have a good conversation about handling the situation.
- Tracking our Lead Time and Cycle Time (or deploys to production is a good proxy for this). If these increase, we know we have dark clouds on the horizon.
- As mentioned above and below - DoD and DoR are critical documents for the team to define their working agreements.
That is it from me for this week, have a great week!
Don't ignore your dreams, don't work too much, say what you think, cultivate friendships, and be happy.
