This is a guest post contributed by Paul Mucur – CTO at Altmetric.
Following on from Oliver’s recent post about the inner workings of Altmetric, I’d like to talk a little more about how we work on the development side of the company, and more specifically about how we’ve had to change our working practices as we’ve grown.
In the past year, we’ve had several new developers join the team and while we’ve been improving our infrastructure to cope with more sources and an ever increasing volume of mentions, we’ve had very different challenges scaling the team. Specifically, how can we successfully juggle the following:
- Support for existing customers (typically via our support site);
- The maintenance and development of new features for our existing products;
- The development of new products (such as Altmetric for Institutions).
More importantly, how can we do all that in a sustainable way?
When I first joined the company, we kept track of all the work we wanted to do (bugs to fix, features to develop) in a single Trello board. All work was arranged as cards in various columns such as “Unimportant”, “News”, “Pipeline”, etc. with “Doing” and “Done” at the end. However, there was one particular column which caught my eye: the ominously titled “Cabinet of Dreams”.
This board contained all the various things we could pursue as a company and the Cabinet of Dreams in particular was our unfettered wish list.
As a new starter, the board was quite a bewildering thing but just because it wasn’t familiar didn’t necessarily mean it was bad. Cautious not to prematurely change something that was working, we kept a close eye out for potential issues and routinely asked ourselves, “what’s the problem with this approach?”
It wasn’t long before we noticed a pattern in our daily stand-ups: during their updates, people would frequently say “I’ve finished what I was working on. What should I pick up next?” This would require our founder, Euan, to weigh in with the next big priority. This would be fine except the team is not always in the same place at the same time and this critical dependency was quite a risky one.
Of course, it’s natural for a small company to be reliant on its founder but we grew increasingly conscious of our Bus factor: “the total number of key people who would need to be incapacitated to send the project into such disarray that it would not be able to proceed.”
The more we considered this, the more we identified places where information was concentrated within only a single person (perhaps the knowledge of a particular system or process) and trying to spread this information became an extremely important goal. Through code review and pair programming (largely following the GitHub Flow workflow for managing code changes), we tried to break these silos between developers but this larger product direction issue remained.
The other cause for concern was simply the sheer number of cards we had: after all, this was every idea we had, saved for posterity. I was reminded of Darren Taylor’s “The Perils of the Large Backlog” in which he quotes Dan North:
How can you respond to change when you have 600 stories in your backlog?
If we were working through all these cards, how could we respond to feedback from our customers? The reality, of course, was that we never really intended to go through the whole board before responding to a customer so what purpose did it really serve?
Finally, the issue of sustainability: with priorities unclear, direction frequently needed and information concentrated unevenly, our pace was extremely inconsistent. Here, the principles behind the Agile Manifesto say it best:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
So how could we improve on these aspects? A simple trick is to just make things visible: in this case, instead of enjoying the infinite expanse of a board in a website, we decided to transfer that same board to a physical whiteboard in our office. Following advice from Dan Brown at the Kanban Coaching Exchange, we tried to mirror the virtual board exactly: after all, our board should reflect reality and covering up the ugly parts would benefit no-one.
So, armed with a lot of sticky notes and copious amounts of magnetic tape, we produced the following real-life version of our beloved board:
The message was immediately clear: we had done a great job of deciding what we could do but now was the time to decide what not to do.
By maintaining all these different columns we were deferring making the tough choices but ultimately hurting the team. We needed to focus and to prioritise, to be realistic about the amount of work you can possibly do in parallel and ultimately enable everyone to be more autonomous.
Luckily, the annoyance of having several hundred sticky notes frequently cascading onto our desks quickly incentivised this change and we made those difficult choices. Jean took on the mantle of our Product Development Manager to constantly maintain and prioritise our new product backlog and, in concert with the team, we have improved our pace and moved from “what shall I do next?” to different challenges.
If you’re interested in methods of working in software development, I recommend attending the monthly Kanban Coaching Exchange as well as watching the recent video from Spotify on their engineering culture which talks in more detail about the autonomy of their teams.