We’ve been thinking a lot about releases in Bamboo Land recently. And I’d noticed a while back that releases of Bamboo are generally down-tempo events for the development team. None of the death marches, mandatory Saturdays, or tension I’d experienced at other companies — just another day at the office. So I asked James and Mark, our product manager and dev lead, respectively, “What’s your secret recipe for wrangling releases?” Their answer surprised me.
“Having developers own each of the story arcs in our releases,” Mark replied. …and that helps you out specifically at release time? Huh.
Let’s back up a bit
We’ll get to release time in a moment, but first I want to share more about how developer ownership of story arcs works on the Bamboo team. Maybe it could work on your team, too.
Releases of Bamboo have either one mega epic comprised of sub-epics (deployment projects in Bamboo 5, for example) or a handful of smaller epics (multiple triggers + custom one-off builds + dashboard filters in Bamboo 4.3). These epics are referred to by the team as “story arcs.”
At the beginning of a release cycle, developers volunteer to own an arc. Each arc owner takes responsibility for creating the user-facing specifications, and decomposing that into an initial set of user stories. Throughout this process, they work with James (our PM) to fine tune all this based on customer interviews and competitive analysis, and with Mark (dev lead) to craft a technical approach that is feasible and maintainable. Arc owners usually spend about a week on this, while the remaining developers get the current release out the door, and spend time on automating release tasks, and other small tasks that will improve the development loop next time.
With specs and stories in place, other devs can come in and contribute to the implementation. Each arc is represented in JIRA Agile as an epic on our rapid board, so the work is clearly organized and visible to everyone (JIRA Agile gives you the option to define the swimlanes on your board by epic, but we opted to define them by assignee). Developers who don’t own an arc self organize around which arcs they work on, and how much. And as soon as one arc is completed, its owner jumps in to help with an arc still in progress.
Throughout, James is firing up new builds of Bamboo for user acceptance testing on each of the arcs. Unlike the unit and functional tests included in our definition of “done,” these exploratory tests help him assess whether what we specced out was indeed the “right thing” and what else is needed to create a truly excellent user experience.
But he’s not the only one. Arc owners are empowered (encouraged, even) to update the backlog as work moves along: “That story we thought would be cool? Eh… not so much, actually. Let’s implement a slightly different story instead.” Or, “We have an idea for a new story that would really make this feature sparkle. I think this should be a higher priority than story X.” Changes like this are mutual decisions between product manager and arc owner, of course. The point is that it shifts more power around feature design to those who are most deeply involved in them.
Ok, so about those releases
It’s pretty simple, really: our PM and dev lead don’t need to spend time getting down into the weeds of each arc’s release readiness. They rely on their “Lieutenant PMs,” who already have a holistic view of the feature that goes beyond the task board and burndown chart.
In fact, so-called “story point tyranny” is what inspired the whole concept. Bamboons found that nobody fully understood what it meant for an arc to be finished, except to watch the remaining story points march toward zero. Nobody was constantly looking at the bigger picture and filling in the gaps to make the feature awesome for users. This meant more blitz tests, more 11th-hour discoveries, and more pressure. Our dev lead said it best:
[We see] lots of instances of where stories are being completed, but things like handling of edge cases, performance, testing, etc. fall through the gaps since “they’ll be done in another story.” Developers having to clean up after a story are annoyed at doing the dirty work, and the devs who started the features don’t get the satisfaction of seeing something through from inception to the finish.
It’s critical for our PM and the arc owners to remain in close contact — especially in the last two (or so) iterations before the release date — and for our PM to trust the arc owners’ assessments. This can mean (and has meant) delaying a release by a week, or narrowing scope a bit. Quality of code and user fit aren’t absolute dictators, but quality is preferred over speed or scope.
There are some “gotchas”…
The first thing you’ll notice is that the developer-product owner hybrid is squarely outside the norms of agile, to say nothing of canonical scrum. Blurring the separation of duties can lead to confusion (“When did that get de-scoped?!”) unless the team is hyper communicative. Plus, not every developer is born with the product management gene; sometimes building up that skill set requires extra coaching from our PM. And in all cases it takes some work from the PM to provide contextual information for each arc: the competitive landscape, what we’ve learned from customer feedback, etc.
…but it has its charms
Just like drafting Michael Vick to your fantasy football team in the ninth round, this system has a strong upside. For distributed teams like ours (PM and dev lead in Sydney; most developers in Gdansk), it means no geography holds a monopoly on decision making power. Add “time zone tyranny” to the list of successful coups. We also spend less time overall on specifications, perhaps because it’s easier to develop “just enough specs” when you yourself are the primary consumer of said specs.
But most importantly, how well the feature fits our users becomes everyone’s responsibility. Developers aren’t just code monkeys — they have a real stake and a real voice in the design of features. Not to mention the valuable skills they add. Our PM, meanwhile, is able to make a more authentic assessment of how well the feature meets our users’ needs when his vantage point is kept at a higher level. That objectivity makes him a better advocate for our customers. He can also spend more time engaging directly with end users, working on the longer-term strategic direction of the product, and mapping out story arcs for future releases.
I hope you’ve enjoyed this little excursion in to unconventional agile. If you’re team is doing something like this, or considering it, we’d love to hear about it in the comments.
Can’t get enough agile? Head to atlassian.com/agile for best practices, anti-patterns and more.