Stash, our Git repository manager, is one of the hottest products at Atlassian. If you follow us on Twitter, you may have noticed that the Stash team delivers new versions about every 5 weeks. That’s as tight a release cycle as it gets for on-premises B2B software! So what is the Stash team’s secret recipe for lighting the world on fire without burning themselves out? I sat down with product manager Jens Schumacher and development manager Stefan Saasen to get the scoop.
K.I.S.S. – Keep It Small, Stash
Stash decided from the beginning to release small batches of features in tight iterations–the main advantages being that smaller releases are naturally easier to stay on top of, and customers don’t necessarily have to wait half a year to get whatever feature they’re most eager for. You might think that, seeing as we’re a collaboration & dev tools company, the key ingredient for 5-week releases is hyper-slick, whiz-bang tooling and automation. I won’t lie: that stuff helps. A lot. But according to Jens and Stefan, the real magic is “high-speed voice communication”–also known as talking.
A lot of the talking happens at the beginning of a feature’s development though a collection of kick-off meetings (the dreaded “M” word!) that bring devs, QA, product management, documentation specialists–and soon, support–together. Depending on the nature of the work, the team may hold kick-offs to solidify functional specs, technical implementation, performance considerations and/or testing approach. Complex features like hooks get the full kick-off treatment, while they do just a sub-set for smaller features like the ability to move a repository to a different project space. “Doesn’t sound very agile”, you might say–and you could make a reasonable argument in that direction. Regardless, the Stash team has found the up-front investment to be well worth it because getting everyone on the same page saves great deal of back-n’-forth down the line.
And that’s wisdom gained through experience. The performance kick-off, for example, wasn’t part of their process originally. But after a couple encounters last year with performance degradations that had to be remedied before shipping, the team decided to add it to the repertoire–building for scale is one of their core values. Turns out the overhead of agreeing on performance requirements and testing for them throughout development is nothing compared to the pain of excavating through layers of code to address performance late in the release cycle!
Talk early, talk often
Once development is underway, there are two weekly discussions related to the release as a whole. First is a 45-min huddle every Monday with Jens (product manager), Kostya (QA) and the team leads to check in on release readiness and risks. The second is the iteration demo, conveniently held at beer o’ clock on Fridays. The team is adamant about the 5-week cadence, and prefers to adjust a feature’s scope or even the set of features being released if the original plan looks iffy. Hooks was pulled from its intended release because, in order to really do it right, it needed about 8 weeks of development. This was raised at a release check-in early on, and because of that they were able to swap in a smaller feature instead: the integration with Bamboo that pulls build results into Stash.
In between kick-offs, check-ins, and demos, the team is in constant communication by way of daily stand-ups amongst each working groups and the full-team HipChat room. They also do a lot of informal testing with over-the-shoulder reviews–”User acceptance testing by committee”, as Jens calls it. This sometimes raises user experience questions that feed into the weekly demo or release-readiness huddle, though most of the time, adjustments are agreed upon on the spot.
So there’s nothing going on here that you haven’t heard of before, and you’re probably doing a lot of these things on your team, too. My purpose today isn’t to reveal some new and sexy secret for agile development. Just to share a story about doing agile right using the simplest, most easily-accessible tool we have: words. And I’ll raise a pint to that any day.
Ps: If you haven’t checked out Stash yet, go see what all the excitement is about >>