When you face something urgent, noisy, and insistent, your impulse is to feed the beast even if it isn’t the most important thing right now.
I knew a team that was well-regarded but wasn’t delivering as fast as the business wanted. They worked by picking the most important and valuable stories, and focusing on those each iteration. These were challenging features, and sometimes the team took longer than expected.
The Intervention
At the request of the business side, management increased the team size by adding an “offshore” team. (India, to the original team’s United States.)
Perhaps you think this will be a rant about use of offshore or multi-site teams, but it’s not.
Sub-team A (the original team) was a “whole team” – product, developers, & testers – everyone they needed to deliver on their own.
Sub-team B (the new team) had only developers, with a plan to add a tester at some time in the future. They were good but inexperienced developers, unfamiliar with either the domain or the system being developed.
This new team structure set up the “feed the beast” dynamic.
Consequences
Now, there was a new concern: “We added sub-team B so we could deliver faster, and we need to use them.”
Planning was harder – it not only had to consider “What’s valuable?” but also “What can sub-team B possibly work on?”
The stories for sub-team B had to be simpler, because that team didn’t have the background to handle anything too hard. They were too many timezones away for easy collaboration.
So, sub-team B was given less valuable stories, but at least they could make progress. Feed the beast.
At first, they struggled: the stories required analysis, either by the designated analyst or by developers who already had the background. Without help, the new team was blocked, so the original team analyzed the stories more deeply for them.
Why was it so important not to block the new team? Well, the new team’s manager knew that if his team didn’t show results, the contract would be canceled. “You’re paying us all this money to help you – you need to help us help you or it’s wasted.”
Once sub-team B was unstuck, what they were producing things also needed support. Their code needed to be reviewed, what they delivered needed testing, and they needed someone to work with the customer to make sure what they delivered was acceptable. All of this required work from sub-team A’s developers. Feed the beast.
What’s the Impact?
For the business, they went from seeing value flow like this:
$$ $$$$ $$$$ $$$ $$$$
to this:
$ $ $$ $ $ $ $$$$ $ $ $ $$$$ $ $ $ $ $$$ $ $ $ $$$$
The number of features delivered per iteration went up, but the average value went down significantly. Worse, the valuable features were being delivered more slowly than ever.
The business had wanted “valuable stuff delivered more quickly” but they were actually getting “valuable stuff delivered more slowly, plus a bunch of little stuff we don’t care about as much.”
How about the sub-team A? Planning sessions took longer, since they had to plan for the whole team (A+B). And they couldn’t just pick the next prioritized story – they had to work in advance to find ones in the “the range” of sub-team B.
During the week, these developers had less time than ever for valuable work. Each day, their priority was “Don’t let team B stay stuck”, so they started most days by answering questions, reviewing code, supporting analysis, etc. Feed the beast.
The developers went from “delivering value but not as fast as the business wanted” to “delivering value even more slowly, but now under more pressure, with less time to work on valuable things”.
And sub-team B? They weren’t happy either. They just wanted to do work, and they knew they needed help if they were to get anything done. They were always under pressure: stuck waiting for answers, always owing more, always treading carefully to not pester sub-team A.
So here they were: three groups, all wanting things better, but things getting worse.
Was team B the beast? No. I think of the beast here is the dynamic of importance being ignored in favor of urgency. Culture added to it: the company valued supporting others (since you’ll need it some time in the future); they valued not wasting money; they valued supporting all stakeholders. But the constant demand and noise drove them to support a system that was making things worse.
Reflection
Brooks’ Law (from The Mythical Man-Month) is the notion that adding people to a late project makes it later. That was clearly at play to some extent.
The Sunk Cost Fallacy says that we tend to over-weight what we’ve already spent rather than realizing that money’s gone, and we have to figure out the best way from where we are.
But in this case, the issue wasn’t sunk costs, but at least partly the desire to reduce ongoing and future costs.
But “Feed the Beast” adds a psychological element. People are under pressure, and this reduces their ability to take a neutral view. Instead, the pressure pushes people to juggle instead of focus: deal with this, and move on to the next thing and the next, and for heaven’s sake don’t drop anything.
I can’t help but think of Winnie-the-Pooh: “Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it. And then he feels that perhaps there isn’t.”
Too many teams are put in that position – unable to stop, think, and fix things.
Other Examples
- (Seen many times) Companies “save money” by giving developers cheap hardware or having a flaky network. This supports the desire of the finance team to keep costs low – silently costing big bucks in wasted salary. Capital costs look great.
- An excessive desire for new features, at the expense of supporting existing features and updating libraries and tools. In one case, the company went six months with lots of shiny new features but the product could not run on recent hardware or operating system releases.
- Over-focus on metrics: test coverage, commitment-met ratio, velocity, code quality, bug-counts, … Elevating any of these can over-shadow real needs. (The worst case I saw of this: a team of 4 or 5 working for 3+ months on increasing code coverage, but their tests had no assertions and ignored all exceptions.)
What About You?
What is the beast in your world? Something you feel you have to focus on, but in reality it’s costing you too much?
Are you stealing time for less important things? Do you neglect things you know you “should” do?
“Urgent” always feels so… urgent. There are times when short-term needs must push aside long-term concerns, but reducing sustainability can’t go on forever.
Are you considering the big picture: what’s important and valuable for the whole?
The beast is noisy and demanding, but it’s not always wise to feed the beast!
References
The Mythical Man-Month, F. P. Brooks
Winnie-the-Pooh, by A. A. Milne