2023-01-19
- A good friend of mine recently wrote an article on focus (in product delivery), aka limiting the work in progress and focusing on one thing to completion.
- Today I had a salient reminder of why it’s so important.
- Let me start by saying that I know how valuable it is to limit your work in progress (WIP) and focus on one thing until completion.
- I purposefully structure my teams to achieve this and manage our backlogs to ensure that the team can follow this maxim.
- However, life rarely runs smoothly when you’re running an agency, and more times than I’d like, we have to manage competing requirements and sometimes, the teams have split objectives.
- We work hard continually to prevent this but sometimes, usually for financial reasons, this isn’t always possible.
- The story I’m telling isn’t in my team directly but with another team, we work closely with.
- In this team, there has been a problem with the deployment pipeline, and the test environment is blocked.
- This has meant the work we’ve been doing has backed up and has impacted some timescales around some quite essential security releases.
- Also, two separate teams have been working on competing outcomes that conflicted with each other.
- When the test environment broke, the other team couldn’t fix it and didn’t reach out for help.
- Rather than stop, reset and figure it out, they doubled down on continuing to make their changes in the hope the next release would fix the issue.
- It didn’t, and the situation worsened.
- We now had more untested code, a broken test environment and a whole bunch of other changes languishing in GitHub branches.
- Eventually, the dam broke, and we got everything unblocked but not in a positive way.
- One impact of all these issues contributed to a member of the other team being signed off work for two weeks with stress. (It wasn’t the only issue, but it contributed to that person being overwhelmed)
- Unfortunately, that person has all the tacit knowledge of how the build and deployment systems work, which meant that the Hail Mary approach to deploying new code to fix the issue couldn’t be deployed!
- It was at this point I was able to step in and reset the work effort.
- We asked a member of our team to investigate the original issue blocking test.
- Three hours later, we found a config file with an error. Once that was fixed, everything else became unblocked.
- The momentum of the other team’s work had narrowed their vision. They decided against the obvious thing and continued with a strategy which compounded the issue.
- There are several significant issues here.
- 1. The configuration issue was in a part of the stack the first team was unfamiliar with. Rather than ask for and accept help, they decided to work around the problems.
- 2. The knowledge needed to complete the critical task was in someone’s head, not the world, for someone else to pick up and resolve.
- 3. The wrong thing was prioritised in the first place. The issue on Test could have only been a config issue, this was apparent weeks earlier when the changes were rolled back to some code known to have worked, and it still didn’t work.
- It’s so easy when you’re in the thick of it to continue regardless. Movement is good, right?
- No, movement isn’t good, momentum is good, and we weren’t building up any.
- It’s better to stop and have some team members under-utilised so the priority issue can be focused on and fixed than to keep going in the hope that it’ll be alright.
- Sometimes it might be alright, but in my experience, you usually end up weeks down the line fixing the thing you should have fixed much earlier.
- We now have two things:
- 1) a working test system to test and deploy the backed-up changes to Prod. Freeing intellectual capacity in the team.
- 2) time to ensure the code written in haste to fix the test environment issue is properly working and tested.
Reading: The case for working with your hands by Matthew B Crawford. (64% Complete)
Matthew Goddard 