(this blog was written by Mike Bessuille and originally posted here)
I lead an R&D team at Rogue Wave Software and, in my spare time, I have attention deficit hyperactivity disorder (ADHD). Well, attention deficit disorder (ADD), which is just like ADHD but without the running around. Those who know me would likely re-insert the H. My project is Klocwork, our static analysis tool, which helps developers find bugs in their code. It’s just the first step in my plan to replace developers with A.I.-controlled monkeys, but I digress. (Told you…)
For many years leading software teams in several companies, I’ve struggled with how to get non-feature engineering work done. Work that we, the developers, know we need to do, but which doesn’t add new capability to the product and which customers won’t see. At least not directly. Stuff like refactoring code to be more easily maintained, improving our automated test framework so it’s easier and quicker to add new tests, and improving our build & test infrastructure. We know we need to do this work because we believe it will improve product quality and help us develop features more quickly. But the benefit is harder to quantify. And here’s the kicker: product managers don’t care about it. I’ll call this stuff “engineering work” – not to imply that features aren’t engineering, rather it’s work that’s driven by the engineering team.
We have a giant backlog of features and bugs that our product managers prioritize. Some of the work on that backlog will never see the light of day but a lot of it is in the category I’ll call “Stuff we really want to do.” There is a lot of it. Customers want a ton of new functionality from us and that’s a good thing! Our product managers do a fantastic job at prioritizing this backlog. They balance bug fixes, features, and longer term innovations thoughtfully. They work tirelessly with engineering to figure out what goes into the next release. There is just never enough time.
How can we ever find the time to fit in some engineering work, when we’re already swamped with features and bugs? Here, I’ll describe a few different ways that we’ve tried.
One backlog to rule them all
I subscribe to the Scrum notion of prioritizing all stories relative to each other in a single backlog. We tried putting engineering work into our product backlog, and holding meetings with product management to influence how those stories should get prioritized. But they never made it near the top of the backlog. There was always something more critical to do. And it can be really difficult to prioritize something customers urgently need, like “improve page load time for large projects,” relative to “split test suite into sub-suites so they can be run in parallel across multiple VMs.” It’s just not easy to weigh one against the other; kind of like deciding between eating broccoli for dinner or taking a weekend trip to the lake. Most of the time, the engineering stories ended up way at the bottom of the backlog, not even being reviewed at all when it came time to plan the next release. They were getting really lonely down there. I’d get drunk texts from them, late at night, pleading for attention.
We moved engineering stories into a separate backlog. This had the advantage of allowing us to name a different Product Owner (PO) – let’s call him “me” – for the engineering project. It became much easier to prioritize items of a similar nature. But it created a different problem as teams were now pulling work from two different backlogs. How were they to decide what came first?
A nest full of squirrels
We tried asking each team to dedicate around 10 percent of each sprint to the engineering backlog. This generally didn’t work. Because of customer pressures, they’d often neglect this duty for several sprints, until they “owed” 40 or 50 percent but at that point, late in the release with several unfinished features, it was too late to do any. Even when teams picked the allotted amount of engineering work for a given sprint, the biggest problem was that of focus. We were enforcing a rather extreme level of ADD on the teams. Context switching between two stories in the same component is one thing, but context switching between features and engineering stories is entirely worse. They are usually very different in nature. They require different skill sets and experience which generally wasn’t available on any team. It was Attention Deficit Chaos, and priorities were never clear.
We started having an entire sprint dedicated to engineering work, immediately following each release. This worked to some degree – at least the team was focused. But it wasn’t ideal. Often, some progress would be made on a particular thing like test reporting but then the project sprints would start up again and the test reporting feature wouldn’t move forward at all for another few sprints. As PO of the engineering project, it was very frustrating to have such long delays between engineering sprints.
Similarly, creating little short-term “project teams” for a sprint or two didn’t help either. It put focus on a particular engineering story and made progress but pulling people out of their product teams was very disruptive to things like team velocity and team cohesion, and it disrupted the progress of feature work.
With several teams all pulling from the same engineering backlog, how could we determine which team was best for a particular job? “Evaluate code review tools” – anyone have any interest in that? “Add more platforms to the set of test systems” – which team wants to do that? Anyone? Nobody? There was no ownership of that common infrastructure, so if there was a problem once the story was completed, who would fix the bug? There was no continuity from one sprint to the next. We spent about 6 sprints working on code coverage tools and each sprint, a new team or person would take a story related to getting code coverage working, with no continuity from the previous sprint, no benefit from what had already been learned or tried. It. Just. Didn’t. Work.
We created a small team dedicated to the common, cross-engineering bits: automation frameworks, test infrastructure, build systems, development tools, etc. It’s not a big team: 3 people, but we have the right people dedicated to the job and they are focused. There is a high degree of “ownership”. Having this separate team allows the product component teams to be focused on their components. Fewer distractions. Less ADD.
We now make a clear distinction between “common” engineering work (which belongs to this common team) and component-specific engineering work – for example, refactoring a component or adding new tests for legacy code in that component. Every new story, whether a new feature or a bug fix, gets an automated test to cover that case. But sometimes we discover that some legacy functionality isn’t fully covered by tests. It’s not easy to convince product managers to prioritize adding tests for a feature that was added a couple years ago. But as developers, we know that our ability to maintain the code is directly related to our confidence in the tests. So we’ve empowered teams to own the engineering work for their own component. They can put that work first, as needed. They have to be reasonable about it, of course. You know how engineers can be: constantly wanting to refactor everything. They’re like children, tearing apart and rebuilding their Lego sets every day.
But I want my cookie NOW!
I’ve found that the best way to justify that kind of work is to tie it to product features. We won’t refactor a section of code “just because”. But if there are several bugs all related to the same area, we may group those bugs together into an epic whose size estimate includes refactoring (fixing it “right”) instead of dealing with each bug individually as a tactical hack. We’ll tie a new feature to some prerequisite engineering story. To the PM we can say, “If you want the feature, we’ll need to do this non-feature stuff first.” Tying engineering work to stories that have a customer-visible benefit seems to lead to the right balance and makes the conversation between engineering and product management easier.
Putting the “H” back in
A common misconception is that the ADHD brain can’t focus on anything. True, it is easily distracted – for repetitive or uninteresting tasks, it has difficulty focusing for very long. But it can actually hyper-focus rather obsessively on something it’s interested in. While I still have trouble writing more than a paragraph at a time without getting distracted, at least our developers can now focus on their work without constantly having to switch between different priorities, backlogs, and teams.
We should only do engineering work if it leads to higher quality software or if it helps us build software more quickly and efficiently. Otherwise, we shouldn’t be doing it. We don’t want to spend all our time fixing bugs tactically as we’ll be slower in the long run and product quality will suffer. But we also can’t afford to drop everything and spend the next six months rewriting everything, either.
It’s a balance. You get there with great communication, trust … and focus.
Senior director, Klocwork product development, Rogue Wave Software