Posted on by & filed under distributed teams, management, product management, Tech.

I can remember quite clearly the sense of pride inside the audience at Office Optional, the first (?) conference about remote work and distributed teams. We knew that together we were charting unexplored territories of collaboration and work. The closing keynote burst this bubble: management speaker/thinker/academic Bob Sutton reminded the crowd that the Romans and Catholic Church had been doing the distributed teams thing pretty well 1,000 years ago. I’ve tried to remember this humorous jab whenever I think there isn’t precedent for a problem I’m struggling with.

As software people, we have a tendency to reinvent the wheel. I’ve repeatedly found myself dismissing existing solutions just because they’re not shiny enough. The most stark example of this is my rediscovery of published budgets, which have been as helpful in managing relationships and setting expectations as they are “lame”.

I have a background as a developer, but I’ve had the pleasure of leading an IT team as a newcomer for the last few months. Like most companies, the IT group (and often the design department, project management team, and others) serves the entire company. This cross-functional position inevitably leads to conflict, as the pressure of shifting priorities inside the wider company strain the relationship each group has with IT. The team itself typically favors efficiency and output whereas the other departments often want predictability and a sense that they’re getting a fair slice of the pie. The fluidity of some agile processes, or a mix of processes between teams, can make this sort of environment a mess on both sides. We’ve cleaned this mess with a budget:

A spreadsheet outlining the number of story points for a range of teams (and percentages)

Every two weeks, our IT team publishes a draft budget that outlines how we hope to spend our “money” (Story Points, in this case), for the next two week Sprint. With the help of our project manager, we try to come up with an allocation that fairly represents the needs of various teams, including our own needs internal to IT. She shares it with the various other teams inside the company as they are doing their own planning. We haggle.

A budget, despite being unglamorous and often associated with bitter struggle, can sometimes help move disagreements toward an economic mindset. It has certainly transformed the relationships inside our company for the better. Each team now knows exactly how much they can reasonably ask from the IT team, what other the allocation for other teams look like, and how much we’re holding back to work on shared infrastructure. As in politics, we often see horsetrading or requests to shift money from one budget cycle (Sprint) to the next. I take these behaviors as positive signs, as they happen in the real world with fiscal budgets too. We reserve a block of points for emergencies for the same reason, just like a budgetary reserve.

After the draft sprint is worked out, we let each team fill their portion of the IT budget on their own during their Sprint planning. This moves the really hard work of figuring out what tickets are most important away from the Team-IT relationship and keeps it inside the requesting team itself, where it belongs. After the planning is complete we pull all of these Sprints into a single Agile board to work from in JIRA and apply some artistic license to sort issues fairly across teams. Our followup at the end of the Sprint is to check the totals against the previous budget to make sure we’re doing a good job with planning honestly.

It’s been working, and we’re looking at applying this process to other shared-resource teams as well.

Tags: agile, budgets, IT, metaphors involving romans, planning, sprints, story points,

Comments are closed.