One good, if fairly glib, way of summarising the purpose of a manager is that he or she is there to prevent the next crisis. This involves all the ingenuity and wisdom that human experience can bestow. Management is anticipation, organisation, and diplomacy; everything else follows.
When a crisis does occur, though, overcoming it is surprisingly easy (assuming that it’s possible at all). There’s none of the effort of anticipation, because the next big problem is already happening around you. Everything you need to know is available, and the number of exits is strictly limited. As if that weren’t enough, most of the circuitry of the human brain is wired for reactive thought: people are at their resourceful, energetic best in times of difficulty.
So, most fools can govern in a crisis (unless it’s a political crisis); the true hallmark of skill is preventing one from happening in the first place.
It’s now two or three weeks since the events of the last article unfolded, placing me squarely in the ‘most fools’ category. To recap, we were left with about three working days before a major tour of the US, gazing at a supremely broken keyboard and facing a very irritated CEO. What we needed to do was obvious:
- Stop adding features and refactoring, except to fix bugs.
- Tackle problems in the order of greatest-impact-first rather than easiest-first.
- Decide every day which bugs we were going to fix, circulate this list, and include the CEO in the circulation.
- Honestly demonstrate steady improvement to restore the CEO’s confidence in the team.
- Keep testing our work by buttonholing an independent product specialist every evening, to get a user’s perspective and to reveal new bugs.
And, of course,
- To work really crazy hours until we’d won.
If you’re part of a software team and you haven’t been chained to a radiator for the last two decades, you’ll recognise a fascinating convergence. That list, without the addendum, can be translated into software-speak as:
- Prioritising bugs over features.
- Managing the expectations of important people outside the team;
- Holding daily stand-up meetings to review progress and triage new cases;
- Employing regular, independent, integrated testing.
These are cornerstones of software best practice and, more importantly, of Agile project management. So it seems that Agile fits our problem!
Agile almost certainly had its genesis in the reaction to a crisis such as ours, but it goes much further. The textbooks I have read on the subject recommend just foisting a flavour of Agile onto your team in one huge, indigestible thrust. I hate doing this to any fellow human being, so I am happy to discover that it is possible to creep towards new working practices effectively, little by little, minimising disruption while sharing complicity and control. When done properly, Agile should be liberating and democratic, and there’s no reason why the transition itself should resemble an abduction.
Naturally, it helps to have a crisis, and our predicament provided the necessary catalyst for change. The great surprise to me, as it had been at Focusrite, was how hungry everybody is for more formality, and for better delineation of working rules.
The founders of Agile must have invented the art in a piecemeal way too, without access to flashy collaborative software, burndown charts, or the lexicon of trademarked, capitalised, frat-boy words that Agile practitioners seem to love. The weird portmanteau words like after-party and touchdown are alien to British nerds; use of sports metaphors like sprint and scrum spark memories of weekly abuse on playing fields. While those sweaty signifiers are everywhere, it’s an oft-demonstrated fallacy that everybody must imitate the winners or die. Google, Apple, and Oracle look very different, and they didn’t get there overnight. Better to evolve, to question, to cut one’s own clothes, and to pass each milestone at a sustainable pace.
The beginning was messy, as it had to be: the day’s top three bugs (along with the next three, in case we had a good day) were scrawled on a whiteboard and marked with asterisks, and crossed out with a flourish whenever a small victory was scored. Reports and updates were circulated two or three times a day via emails and ephemeral, free-form documents. Our testing was fairly ad-hoc, usually starting some minutes late and skipping from feature to feature with everybody talking at once, but it actually did the job and we ended up with a really decent, demonstrable product that supplanted our old prototype in a matter of days, and a happy boss who trusted us again. I characteristically resist enthusiasm, but a few minutes of playing a Seaboard now makes an electronic piano feel primitive.
The last few weeks have left a lingering taste, and some time to tidy up and consolidate our new system. It’s no shame to admit that a talented software team has occasional organisational difficulties. Everybody does; it’s a fact of life. Mistakes make great lessons, though. Biographies that chronicle noble failures are far more informative and more honest, if lamentably rarer, than those that focus only on success. Creative teams are always caught between between having enough formality to collaborate effectively on really difficult tasks, and respecting those sparks of individual brilliance that will make a product shine. The equilibrium between the two must adapt continually — often painfully — to fit the evolving team, but that’s what Agile is supposedly all about.
Our jobs are constantly in flux. Focusrite, six months after I left, has put in so many new practices that, were I to return, I wouldn’t know where to put myself. And yet, Agile is a peculiar beast to shoehorn into a hardware company, as it doesn’t fit well with the process of making physical objects.
The next article will probably be about how software-centric Agile collides with hardware-centric ROLI. Particularly, we’ve been thinking about how we can make the necessary heaps of planning and due diligence work in our favour, by softening the boundary between our work and its documentation.
Actually, that’s not an article. It’s a career.
