A year ago I published an update to our development process, simply baptised talking to each other by Chris in his namesake post from late 2011. Time has come to take another step ahead in refining our process, and now that we’ve been using the improved version for a few weeks, we’re ready to share it with you.
To this day, not a week passes without a potential hire or a third party asking us whether we’re doing Agile, Scrum or Kanban. The short answer is: none. The other short answer, one could argue, is: all. There are in our process methods (e.g. stand-up) and labels (e.g. epic) that anyone in the industry would recognise as part of one or more of the methodologies above, but we choose to focus on a cohesive big picture that generates the right outputs for us—is it easier to develop and ship?
rome wasn’t built in a day
As with all growth, some aspects evolved organically as the team grew and fed back, while other parts of our process’s evolution had to be sorted with a thinking cap and a whiteboard marker.
A lot has also changed in terms of system components (we broke down a few monolithic structures), infrastructure, code review/ QA through pull requests, deploying and monitoring in the last year, so all that alone required a refresh of the development process.
The nature of our work has also migrated healthily from pure engineering and a hefty dose of R&D to the majority of our time spent on reengineering for scale and stability, and on boarding clients on existing live systems. One corollary is that a support roster of four needed to be scaled itself to what is now a support team of nine, and I look forward to my first support week myself.
We tweaked things as awe went along, of course, to the point that Happy Hour (our daily sit down, demo, project update, cry for help and code review) became hard to confine to one hour, and planning the weekly iteration ahead easily stretched to fill too many pockets in a long day, being tiring on all sides. But however hard the growing pains, we all saw what worked and what didn’t and felt free to talk about improvements.
this is how the cookie crumbles
As a consequence of all the above, it’s no longer possible to have one person delivering a project with just a little help from others. Or just one person knowing one code base or one technology very well. Or one project being broken down to a number of equally sized chunks. On the upside, it is more possible than before to make a case for what should be built when, for which product and why. And everything flows better.
So Confluence has gained the product roadmaps we had all craved and kept rehashing for a while across too many formats and tools. Our use of Jira moved away from releases to sprints. Projects are now sets of features, and features take a number of days till shipping. In Jira we have had to describe features as epics, but in time we will get over that hump, too.
Features have also replaced focus tasks, and as such are agreed and discussed a week in advance. Teams form naturally around features they sign up for, then chat and break down the work ahead of time. We kept our weekly iterations, but with features varying in numbers of days required for completion, we can now even more than before release to production throughout the week, which itself has removed some nasty headaches. Finally, we’re working on integrating Jira with our support process so that more of our good work becomes visible and trackable. And clients get the ticket IDs they crave (need I elaborate?).
bring back the happy in happy hour
Gone are individual updates in the sit down part of Happy Hour. Feature updates make it all quicker and more palatable for the larger team. Gone are the chats about what we should do, replaced smoothly with how we’re closer to our aims. And more than once we had it all wrapped up before the clock announced a full hour, without any effort—we have become so good at talking to each other that not all that much talking is required in our daily gathering!
Except where it suits. Last Friday, our customary company/ market update has given way to a great debate on the future of VOD where pretty much everyone chipped in. And code reviews on Wednesdays now focus on big, hard problems, cross-cutting many systems. Maybe Tom will tell you more about that 🙂
And planning? It’s a breeze! Because the right people get together at various points, with a clear view of what they signed up for as team, and arrive at a plan to make it happen, while alignment among teams, client needs and company goals had been clarified well ahead. On my part, there was opportunity for an increased number of wireframing sessions with the teams, and discussing where a product is going overall, and few things could make me happier.
is this all?
Of course not. Though we’ve only been at this for a few years overall, and the updated form—only a few weeks, glimpses of the future abound on a daily basis. For example, when James wrote heads up in Skype just yesterday evening, it struck me as exactly the kind of behaviour that would improve our lives a bit more, and today in Happy Hour we’ve discussed further improvements to pull requests and deploying.
It seems to me that when it comes to development processes, in an industry that’s been going through radical shifts in the last ten years or so, work in progress is a good thing. So if you like what you hear, we are yearning for no less than 9 more metabroadcats. Let’s keep talking to each other.