Walking before running
Background
Years ago, I was brought in as a consultant to a company that had recently developed and deployed a ‘version 2′ of their core internal software, then had the entire development team leave (well, one person remained behind). Smallish business of maybe 50 or so folks, but no development team to support and grow this new version 2. For a bit of color, this was largely an internal scheduling/reporting system used by their inbound customer service team to help their customers and the customers’ customers.
We connected, and learned a bit more back story. They’d contacted an old PM from years earlier who came back on to help right the ship, and they’d hired a handful of new devs in the area, but none had experience in the core language (indeed, it was a moderately niche language – had some power, but definitely a small adoption base at that time).
Problem
The PM was scheduling work with the team a month at a time. This isn’t quite the normal ‘2 week sprint’ that many people are accustomed to, but in and of itself, it’s not necessarily *bad*. What was bad was the scope they kept attempting.
Month after month, they’d attempt around 20 issues from their backlog; each of the 4-5 devs would try to get 4-5 issues ‘done’ in a month. For experienced teams that have worked on a shared stack for a while, that might be reasonable. For a new team of generally inexperienced developers, working with a niche language, that has little documentation, grappling with a brain drain, it was … far too aggressive (I think I used much harsher language in the moment!)
They’d been working this way for about 4 months, and every month, things got worse. They’d ship a new version at the end of the month, and cause more problems than they’d solved. Tech debt was growing, not shrinking, week by week.
Solution
After talking with the dev team, the PM, the owners, and the internal users, I convinced the team to have a month of joint effort work, vastly scaling back the effort. I wasn’t even sure what we’d get done in a month, so I didn’t even try to plan that far ahead. The goal was to have everyone work together on one issue, until we all understood it, agree the fix is OK, and then document it and perhaps even ideally write a test for it.
Side note: Testing for everything would be great all the time, and we all agree we should work towards it, but we didn’t always even have enough internal knowledge about how/why things should work, and the test harness in place was (to my recollection) essentially non-functioning. The previous team had written their own test harness, a handful of broken tests, then left. Testing as a matter of course might have to wait a bit while we got up to speed on the core a bit more.
I got a lot of pushback – “We’ll never get anything done at that pace!” “We have too much to do!” – as you might imagine. But I pointed out multiple times that every single thing they’d “delivered” had simply caused more problems. We can not avoid that entirely, but we needed to slow down before trying to go faster.
So we did it. It took us around 3-4 days to get “done” with one ticket. We all individually thought we knew the root cause, but as we traced through, everyone’s assumptions were wrong. End of that week, we pushed that one change done. Nothing broke. That was good. Slow, but good.
The next week, we split in to two teams, and attempted two tickets in parallel. And each of those still took around 3 days for folks to grapple with then fix. End of the week we shipped those two items. Same cadence in week 3.
Outcome
We had a some of the internal users come over and thank us for not breaking stuff. “You fixed something and nothing else broke – this is great!” There was a genuine excitement that a corner had been turned.
Lesson
You need to walk before you can run. Teams that are both new to a codebase, as well as new to a company and new to each other need time to gel. The previous team had worked together intimately for 18 months… expecting a new group of less experienced people to deliver at the same pace was setting everyone up for continued failure. Resetting expectations – even if the short term impact is reduced output – should always be considered, both to boost morale and avoid additional bugs.