The Agile Manifesto, Explained for Musicians
Or, music explained for agile programmers.
Recently, I have been finding myself interviewing for tech jobs, sometimes rather spontaneously. While this is definitely a cause for celebration (my adoption of the foetal position can now be accompanied by Kool and the Gang), I can’t help but feel a twinge of apprehension. This is partly due to having had limited experience of being able to use actual words when in the process of being scrutinised by prospective employers (see my previous article), but also due to the hypothetical hysteria that I tend to go through while attempting to pre-empt the moves of the arbiters of my fate.
Like many, I brace myself for the introduction of certain topics into the conversation, knowing that my response is likely to be more stammer than sentence. One such topic is Agile, the ever-ubiquitous keyword that has been shoehorned into pretty much every tech job ad I’ve seen so far, and is probably also a trigger for the ATS bots to joyfully cast my CV into the furnace. This may seem like an odd choice of interview topics to fear, especially when agile methodologies aren’t completely alien to me; but I think this is due in part to some agile principles feeling eminently sensible, to the degree that they become difficult to describe. Common sense, if you will.
But if agile methodologies really are rooted in “common sense”, then why do they get such prominence in job ads, company blogs, and LinkedIn profiles? Why is “Agile Coach” an actual job title, and not just “Magic Bus” by the Who after a return journey through Google Translate? (Totally got that stuck in your head now — even better, the word setting still scans with the new lyrics.) Why do agile principles feel sensible to me, despite my not being inherently sensible? (My wife can back me up on this…)
Perhaps it is the case that agile isn’t actually that intuitive, but merely appears to be, as I’ve been unwittingly doing a lot of this stuff in my other job for years?
Let’s investigate! Helpfully, a collective of eminent software engineers curated an Agile Manifesto, with twelve core principles that can be found here. I’ll take each principle in turn, and retroactively apply them to my freelance cellist life. (Also, don’t be fooled by the super-generic globe favicon that can be found in the tab for the Manifesto’s website — these guys have generated an entire library of important programming books between them.)
Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.
Okay, so I know the “software” in this context will be sound waves rather than ones and zeros, although there’s got to be an easy pun about binary form in there somewhere. Plus, another one about ternary form and ternary operators… but I digress.
No (London-based) freelance musician can put food on the table without performing constantly — one gig does not pay the bills! My personal record was three in one day, which has happened more than once. As for the “valuable” part, the performances have to be of a consistently high enough standard to ensure that your audience members are happy to sit through more of your concerts in the future.
Welcome changing requirements, even late in
development. Agile processes harness change for the customer’s competitive advantage.
If concerts were predictable, there would be less of an appetite around attending them. Unplanned things happen! Broken strings prompting mid-performance instrument swaps with other players; extreme acoustic differences (sometimes even between different venues on the same tour), prompting last-minute rethinks of tempo, articulation and balance; opera singers doing, well, anything… Adaptability is crucial.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
To expand on what I described in response to the first principle, in any given month the turnover of performances will be necessarily high, and often varied; it may involve a combination of orchestral concerts, solo or chamber recitals, studio sessions, theatre shows, functions and probably a few other things I haven’t considered. Now what’s more agile than agile…?
Business people and developers must work
together daily throughout the project.
There are a number of scenarios where music provision is bespoke or ordered to spec — situations like weddings, funerals or even private recitals. Under the circumstances, liaison between musicians and client can be pretty constant. Similarly, if I’m premiering a new cello composition, it’s likely the case that the composer and I will be communicating regularly while the piece is being written. This has a couple of definite benefits:
- For the composer, this is an opportunity to establish what is and isn’t doable on the cello
- For the cellist, this is an opportunity to intercept and neutralise anything that isn’t actually playable
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The best conductors I have worked with have tended to refrain from micromanaging, opting instead to convey a concept and conviction for the music that encourages unity and commitment from all of the performers in the room. I also suspect that this would be the description of the favourite conductors of most of my colleagues. Orchestral musicians, by and large, want to be trusted — if we made it through all of those gruelling years of training to reach a level where we can be playing in major orchestras, it’s safe to say that we want to do a good job.
With that said, a clear beat never goes amiss. We’re not superheroes, you know.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
It’s amazing how much rehearsal time is spent discussing ideas, phrasing, bowings and colours, sometimes in a *ahem* “heated” way… In the past, there have been times when I have tried to reduce the non-playing time by emailing my thoughts to my colleagues ahead of rehearsals, especially if we were based in different parts of the country and could only meet in sporadic, focused bursts.
It basically never worked.
Working software is the primary measure of progress.
I’d like to give a shout out here to any of my current and former students who have ever attempted to justify moments of flagrant musical stinkery by:
- exhaustively describing how much practice they did that week, or
- exhaustively describing all of the reasons that they left the cello in the case.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
I would also like to give a shout out to any students of mine who have clustered a week’s worth of practice into the evening before the lesson in the misguided belief that I wouldn’t know the difference.
Continuous attention to technical excellence and good design enhances agility.
This. Just this. All the thisses.
Classical musicians are plagued by the paradox of having to acknowledge that perfection does not exist in music, but also having to perpetually strive to get as close to perfection as possible, musically and technically. This ongoing pursuit of perfection is undoubtedly the biggest driver of innovation and refinement in classical music. It also has rendered us dysfunctional and neurotic, but potato potahto.
Simplicity — the art of maximizing the amount of work not done — is essential.
Whenever I witness one of my students trapped in the infinite loop of practicing-without-listening-or-stopping-or-changing-anything-or-introspection-but-hoping-it-magically-works, I point out to them that the aim of golf is to play the least amount of golf. Similarly, the aim of practice is to do the least amount of practice — the more focused, patient, considered, intentional, consistent and granular you can make your practice, the less time and energy you waste.
I do have to be careful in how I explain this though, in case some opportunistic smartarse leaves the cello in the case, believing that they can magically turn into Mstislav Rostropovich through the power of “agile practice”…
The best architectures, requirements, and designs
emerge from self-organizing teams.
For many classical musicians (myself included), chamber music represents an ideal marriage of all that is great about music making. There is a wonderful mix of autonomy and authority, but also discussion, teamwork and compromise; it is an opportunity to learn, but also to educate. Also, the lack of a conductor means that players often take more active individual roles in guiding the artistic and professional direction of the group. Probably out of sheer joy.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I sort of feel that this could continue on from the previous principle. Any chamber group that does not allow their rehearsal techniques to evolve according to experience, mutual familiarity, time constraints and wisdom will do so at their own peril.
In conclusion, some of these links may have been tenuous, but others were very solid matches. It is at least a starting point for me to be able to explain agile principles in an interview, drawing upon examples from my career as a muso; and given that I was unaware of Agile until I’d been a professional musician for well over a decade, I’d say that’s doing pretty well. Perhaps I’ll even have the confidence to highlight some examples of agile principles in action in my CV.
The ATS bots can discuss a new strategy for filtering it out in tomorrow’s stand up.
