Agile, retrospectives, Scrum

On Being Mad, And Glad, And Sad

No Comments

And no, I’m not incredibly confused nor clinically insane (although others may have a different opinion).

Reveal: I love retrospectives

In my early days of Scrum Mastering, I typically stuck to the same retrospective exercise because it felt safe. But there’s only so many times that you can do “The Speedboat” before it becomes stale or irrelevant (by the way, The Speedboat exercise is great for looking back on an iteration; the team I worked for would regularly change the speedboat for other vessels: X-Wing fighters, submarines, tall ships, radar-invisible stealth cruisers..)


Fig 1. A Speedboat With MC Hammer Obstacle

Over time, I learned that not only were there different retrospective techniques tuned for certain project scenarios, but also for the different stages of the retrospective (checking in, setting the scene, gathering data etc).

Buy “Agile Retrospectives – Making Good Teams Great” by Esther Derby and Diana Larsen. It’s the retrospective bible, in my humble opinion.

So after messing about with The Speedboat for a few sprints, I switched to Starfish then to Team Thermometer and even Pictionary (one of the funnest). If you want to read up on them and others then buy, “Agile Retrospectives – Making Good Teams Great” by Esther Derby and Diana Larsen. It’s the retrospective bible, in my humble opinion. However, one retrospective technique stands out for me as being truly engaging: Mad, Sad, Glad.

Welcome to Madsadgladland!

On the beaches of Madgladsadland, inhabitants rub shoulders rather than converse across a table. They move around each other in a dance of cooperation rather than let their humble servant-leader direct their choreography. They invoke human-evolved pattern recognition rather than have those patterns pointed out to them. In short, they Own.

Sadly, in our office at least, there are no beaches and there is no dancing. But Mad, Sad, Glad is retrospective technique that encourages lots of cooperation. I’ll explain.

The suburbs of Madville, Sad Town and Glad Central

Find a big whiteboard and write the headings “Mad,” “Sad” and, “Glad.”

Ask the team to write down things that really stuck in their throat (for Mad), things that they wish didn’t keep happening and need fixing (for Sad) and things that they really get a kick out of (Glad). You can use your own definitions for the headings. It helps to have different coloured stickies for each of the categories.

Ask the team to place the stickies under their respective headings.


Next ask the group if they can spot anything about what’s been put on the board. Ask them what it felt like to write what they each wrote. Ask them if anything surprised them. There are other Powerful Questions you can ask, and you’ll find them in the literature.

Before I continue, it’s at this point that I’m reminded of how much of an impact this technique had on me. Until I’d run this exercise, many of my retrospectives involved putting stickies on a board, but then the team would sit down, relax, and let the facilitator drive. On the first time I ran Mad, Sad, Glad my heart fluttered with pride and a big grin appeared on my stubbled face as I witnessed normally static team members move and interact and debate!

So, next you ask the whole team to get up out of their comfy seats, walk over to the sticky-infested board and work together to identify patterns in what has been written. This is regardless of where each sticky was originally placed; the colour coding maintains whether it was a Mad, Sad or Glad. If your experience is anything like mine, you’ll witness people collaborating (“what about putting this one with this one”), you’ll see them negotiate (“I’m not sure this Jenkins one should go with code quality; shall we create a new category for it?”) and you’ll see them query (“what does this one refer to, Jon? Why did you feel that way when Jane was super happy with the same issue?”)

Some groupings may have Glad stickies and Mad stickies in them; if this is the case, enquiry why. This can reveal misunderstandings and tensions.

In short, you’ll get the level of collaboration you wish they maintained during their normal working day. But let’s not be too hard on our teams; collaborating in a retrospective is as good a place to do it as any.


Fig 2. A Grouping Of Stickies About Team Size

During this physical interplay between team members, you should notice some healthy chat happening. If you see that one or two team members are the ones doing the organising of the groupings, politely ask that they step aside to let others review what they’ve grouped, or to add some new groups. Remember, in a retrospective, we’re all equivalent despite not being equal. When they think they’re done, I ask them to look over the groupings one more time and then label them with an appropriate heading.

In my opinion, if the technique ended there (and I guess it can, if you wish) then it would be a success, solely judged on the increased cooperation between team members. However, the next natural step is to allow team members to vote for action on the groups they’ve created. (Some groupings may have Glad stickies and Mad stickies in them; if this is the case, enquiry why. This can reveal misunderstandings and tensions.)

From this point onwards, it’s upto you how you deal with voting. In the team I serve, we try to commit to no more than two actions for improvement in the upcoming iteration. If there are others that also seem important, I’ll note them and ask the team in the next retrospective if they want to deal with them.

Just do it

My recommendation is to try Mad, Sad, Glad in your next retrospective. Its simple title belittles its awesome impact. And as with all retrospectives, don’t forget to check-in, set the scene and evaluate the meeting.

Agile, Planning, Scrum

On My Phobia Of Sprint Planning

No Comments

Yes. You heard it here first. Sprint Planning sessions fill me with fear.

Like most Scrum Masters, I’ve attended many Sprint Planning sessions – for many different projects, for many different teams. The ones in which there’s a distinct client (rather than for a product owned by the business) strike a particularly strong sense of foreboding into my soul. What if I don’t understand the requirements? What if the client gives me a hard time and I have to think on my feet? What if I can’t contain the developers’ enthusiasm to underestimate everything to keep the client happy? What if I can’t contain the developers’ enthusiasm to wildly overestimate in order to protect themselves? What if I go over time and we’re not finished? What if, what if, what if???

And then I take a deep breath, turn the door handle and step, once more, unto the breach..

The fear

Of course, if all Sprint Planning sessions turned out to be as bad as I feared, then I would have quit Scrum Mastery a while ago. Maybe I would’ve taken up something like shark painting or oil rig wrestling.

The first mistake I make is to be fearful for myself. Two things then come to mind, and provide immediate comfort:

  1. if I’m scared, how do I think the team must feel?
  2. it’s a team effort and the developers know more than I do; draw upon them for support and give them yours

By now, my heart rate has dropped a little. Then more lifelines get thrown down to me by my reasoning:

  1. being brave is about being honest. The outcomes are better following an honest appraisal of a problem than from following one given under duress
  2. the last iteration is behind us, we’re closer to the finish, and there are new discoveries ahead. Rejoice!

Facing it

As with checking in during retrospectives, I combat my fears by trying to be the first person to speak when the meeting kicks off. I state the intended outcomes of the session, the duration and all that administrative stuff, and I make it clear that the meeting is about discovering work and focusing on creative ways of addressing the Product Owner’s goals. By making this first stab, I’m quickly able to bury my nerves and get on with it.


Image courtesy of Frederick Homes for Sale, Flickr (CC)

But some Sprint Planning meets can be…. difficult. So what happens when my nightmares start to come true?

I’ve been on the brink of an argument with a client during one memorable session. But rather than let emotions get involved, I reminded myself that lives were not at stake here; just assumptions – some valid, some not. I assured the client that I was only labouring a point because I felt I had evidence to back up my claims (about estimation, now you ask) but that we, as a Scrum team, were there to not only validate his assumptions, but to challenge them and present hopefully better alternatives. After all, we’re paid to think, not just do.

Keeping your head and your cool is key.

Sometimes the problems are closer to home. Like the time the team I was serving never finished any stories, and each planning session was a repeat of the previous; always choosing the same not-yet-Done stories. In those cases, your skills as a Scrum Master are tested quite hard. You have to come up with a way of breaking the deadlock, lifting spirits and ensuring all parties, stakeholders and Product Owner included, know the facts, no matter how painful they are to admit. You need to extract valid points of learning from failures such as these. And, of course, you need to establish a way of not going down that alley again in the future.

So, with all this going on, it’s no wonder I get a little shaky! But, that all said and done, a little adrenalin can certainly add gusto to your mastery.

Agile, Planning, Scrum

On My Love-Hate Relationship With Tools


I don’t hide the fact that, given the choice, I’d rather have my feet swapped out for frying pans, than have to use Agile “management” tools. I make it clear to the teams I serve that nothing really beats what we’re finely tuned to be good at: face to face encounters. I keep away from software tools when it comes to working within the Scrum framework.

This resentment began, I think, when I was introduced to Jira. (My recall is foggy because my brain has put a lot of effort into erasing that moment.)

I was in the throes of becoming a Scrum Master, and was feeling particularly excited about the prospect of using big whiteboards and PostIt notes and marker pens and magnets. In fact, I may already have started using them. I’m not sure.The company I was employed by was rolling out Jira as a means of not only tracking defects but, God forbid, sprints.

No matter how hard I tried, at least one team refused to move to a physical board. It was a team of three, and they sat next to each other no more than 1m apart. Yet they insisted on using Jira to keep themselves updated. And just half a metre from them was a shiny new whiteboard on wheels, ready to be drafted into action at the drop of a hat. I’ve no doubt they probably used Google Talk to chat to each other too.

“Individuals and interactions over processes and tools.”

Tool usage in itself may not be a problem, but the tools themselves restrict us. For example, in the same company, the Product Owner wanted to see how the team was doing with her stories. For the aforementioned renegades, we had to arrange a Jira login ID (but we’d run out of users so had to boot someone off to make room for her) and then train her in how to use the tool. I’m not convinced we’d bought into Scrum’s “information radiator” ethics. Information coolers, more like.

But the issues aren’t just around visibility. I’ve used other Scrum tools that absolutely insist upon the users entering estimates against stories. But if you’re working with a team that has moved beyond estimation, the tool becomes unusable. The workaround? Type in any number against the estimate. This is fine for the developers, but I had one case where the stakeholders also had access to the same software and they raised concerns about the velocity of the team. The software told them that the team was going to be late on delivery based on the numbers they’d punched in. I’ll repeat that. The software told them. Not the team. Not the Scrum Master. But some software.


Physical boards give you the freedom to modify your way of working without waiting for a change request to go through to a team of open source developers spread across the globe. For example, I’ve recently been using Taiga. It’s a great looking bit of software and really easy to use. But hold on, what happens when you want to close a sprint? Well, normally, you’d make a note of the stories that didn’t reach Done, maybe note also the ratio of stories Done vs not Done, and close the sprint. But Taiga operates on the policy that a sprint closes when all the stories are Done. Until then, the sprint can’t be closed. OK, so I’d love my teams to get all their stories to Done. But in reality, this doesn’t always happen In fact, Scrum works on priorities, so sometimes you half expect the stories near the bottom of the sprint to not get finished. C’est la vie. Taiga, instead, operates on the fallacy that teams will get all their stories to Done. Always. The solution? At the end of the sprint, you have to move all off the not-Done stories out of the sprint and back into the backlog. The sprint then closes. Oh, but now the tool will tell you that you completed 100% of your stories in that sprint, which was zero. Gah!


Recently, I’ve found myself acting as Scrum Master for a team that’s located about 200 miles from me. I’m using agile management tools. It makes me feel a little dirty, but the team is getting some use from them. We were using Taiga (see above) with some manual note taking thrown in to cater for its restrictions. I can live with that for a while. But what about retrospectives? This is an area that I really enjoying indulging in. But that’s when I’m in the same room as the team, reading emotions, watching body language and, in many cases, veering wildly off course to cater for something crazy that pops up during the exercise. With a team that’s 200 miles away, I had to revert to tool usage again. I scoured the web for a cloud-based retrospective tool. I found some. I tried one for two retrospectives. It worked. But boy, by the end of each retrospective I was exhausted! Why? Because I had imagine the feeling of the remote room; I had to work hard to listen over VoIP to gauge the sentiment of the team. It was very very hard work. The tool allowed us to type things within certain columns (like Mad, Sad, Glad) but what was missing was that human touch. The unsaid.

I don’t blame the tool for this; it was making a good job of a less than desirable situation. But boy would I have preferred to be there, in the thick of it.

So, I’m no tool playa. I’m a hata. Word.

Agile, retrospectives

On The Need To Keep My Mouth Shut

No Comments

We all know why we have retrospectives, right? Ultimately they’re a mechanism with which a team can reveal and discuss dysfunction whilst concurrently identifying actions that lead to real improvements and less dysfunction. Self improvement at the team level. When done well, retrospectives can truly energise a team and even bring its members closer together.

End of story?

A retrospective involves an often-overlooked team member: the facilitator. In Scrum, that role is normally played by the Scrum Master. Typically, the facilitator of a retrospective will keep the session moving, giving the team the tools to express their views fairly and with focus. The facilitator will help draw out facts, present data, ask powerful questions, entertain, feed, protect team members from abuse and help to temper overwhelming voices. But, despite this rich menu of responsibilities, the retrospective is rarely for the facilitator.

It needn’t be this way. As facilitators, we also have the means to reflect, improve and learn. The main difference, however, is that we must do this silently within, instead of with the plethora of retrospective exercises available to our team.

My partner is a therapist and encounters this exchange each time she works with a client. A therapist is not only providing a safe space for her client, but she also uses that time to look inside herself, especially when having to digest the feelings and words coming from her client. There’s really no such thing as a passive therapist; therapy can change both the client and the therapist. (And if you’re keen to know more, try Googling, “countertransference.”)

And so it is with retrospective facilitation.

It took me at least a year of being a Scrum Master before I started to modify my behaviour beyond the normal. Until then, I was doing Scrum by the book: sprint planning, daily scrums, story points, reviews, backlog refinement and retrospectives. None of these things is bad (in fact, done well, they’re awesome), and the teams I served seemed to be getting a lot from them. It wasn’t until I switched employer and started working with new characters that I quickly learned that being relatively dogmatic was not helping any of us improve.

Changing exercises

I started by learning new retrospective exercises, mainly gleaned from Esther Derby and Diana Larsen’s fantastic Agile Retrospectives – Making Good Teams Great book. I’d use one exercise for a few retrospectives, then switch it to a new one for a few more, and so on. This simple adjustment taught me to be brave and to embrace change – something I preach during retrospectives!

But changing a retrospective exercise is actually quite simple. Other improvements are harder.

Being silent

You’re a Scrum Master facilitating a retrospective with your fellow team members. You ask something like, “OK so we’ve identified this issue. It’s a toughie. Does anyone have any ideas about how we go about sorting this one out?” You look around the room, wait a couple of seconds then, “Anyone? Maybe we could try <insert your brainwave here>?”


From the teachings of Lao Tzu and Buddhism, to songwriters and the multi-faceted world of psychology, the virtues of being silent have been steadfastly encouraged. Yet for most of us, silence can be awkward, unsettling, deafening even. When we’re greeted with silence, we feel compelled to fill it. Silence is an opportunity for us to jump in, much like when there is a gap during a debate or conversation. However, silence is also an opportunity to allow others to think, to speak, or even to do nothing.

Scrum Masters are generally expected to be impartial facilitators, removing themselves from the content of the meeting (the main exception is when the content centres around the Scrum framework. In which case, we can dive in with our wisdom!).

So humour me: Next time you’re facilitating using this impartial mode and ask a question of the team – maybe it’s a question that helps form a picture of an event – but you get no immediate response. Don’t fill that silence; instead, wait. And wait some more. Notice how time seems to slip by at half-speed! Try hard to not even make a sound. Let the silence unsettle.

“In 1930, the Republican-controlled House of Representatives, in an effort to alleviate the effects of the… anyone? anyone?… the Great Depression, passed the… anyone? anyone? The tariff bill? The Hawley-Smoot Tariff Act? Which, anyone? Raised or lowered?… raised tariffs, in an effort to collect more revenue for the federal government. Did it work? Anyone? Anyone know the effects? It did not work, and the United States sank deeper into the Great Depression.”

Classic. The economics teacher from Ferris Bueller’s Day Off was filling the silence after each of his questions. By doing so, even if the students wanted to answer (rather than chew gum and stare out of the window), they weren’t given time to do so.


It’s hard to do this. But by restraining yourself, you’ll allow the team to fill the silence. And when they do, it’ll most likely be with something that is relevant to the question asked (and maybe even better than your own brainwave!). Silence is thinking time.


Finally, tolerance. This is closely aligned with being silent. Tolerance is one area I’ve certainly needed to improve on.

During a retrospective we are likely to hear many things; from astute observations to nonsensical ramblings! And at times we hear arguments that antagonise (sometimes intentionally). I’ve struggled at times in these moments.

The next time you’re in that situation, before jumping in to offer a piece of your mind, or to counter a controversial point of view, stop and ask yourself who will benefit from your response. Is it just you? Will your response add useful information to the debate or will it simply let you vent some steam? With this in mind, try your hardest to only add useful information to the debate, things that will help the team come to a clear conclusion. Tolerate nonsense and antagonism by providing meaningful input, and never reactionary put-downs.

As Scrum Masters or facilitators, we are in very powerful positions; team members will look to us for guidance as well as subconsciously regard us as leaders by virtue of our manner of speaking, our consideration towards others and also by what we don’t say. These virtues don’t come easily, but retrospectives provide us the space in which to learn, practice and develop them.

#noestimates, Agile, Other blogs

Scrum Master Toolbox Podcast

No Comments

Scrum Master Toolbox Podcast

If you haven’t come across the work of Vasco Duarte, then I recommend you tune into him and especially his take on #noestimates (I consider him one of the three #noestimates musketeers, along with Woody Zuill and Neil Killick).

Some time ago I was invited onto his Scrum Master Toolbox Podcast to talk about the typical issues that Scrum Masters face. I urge you to check out the other podcasts; there are some very enlightening conversations on there from some great Scrum Masters including Neil Killick, Woody Zuill and Henri Karhatsu.

Agile, Music

Mark Ronson’s TED Talk

No Comments

I’m currently finishing off part 2 of my On the Agile Nature of Music Composition series. Something popped into my Twitter feed this morning which is related to my music composition ramblings: a TED Talk by music producer Mark Ronson on how sampling transformed music (sampling is the act of taking snippets of an original recording and using them as the basis of, or to help form, a new musical production). Take a look.

Agile, Life, Planning

Life Feels Better When You Have a Plan

No Comments

On my walk to work each morning, I pass a bus stop sporting an advertising hoarding for Scottish Widows’ life assurance products. (The Scottish Widows mascot is such a young widow, poor woman.)
Their strap-line for this current campaign is, “Life feels better when you have a plan.” And on their website, they talk about how having a plan makes life feel “lighter.”

What caught me about this new campaign is its truth; life does feel better when you have a plan. But I suspect that, in an effort to sell more life assurance policies, the campaign managers were hoping readers would interpret this as “Life is better when you have a plan” and therefore, “Life sucks unless you have a plan” and onto the conclusion, “Life follows a plan. Buy yours now. Rest assured.”

Plan To Be Happy, Don’t Be Happy To Plan

When you see detailed plans in software development projects, you can tell that a certain group of people draw great comfort from them. They provide the illusion that a chain of events will happen, culminating in the plan’s ultimate delivery or conclusion. And when these plans are printed large and bold on a massive wall, their impressiveness is hard to resist. They look awesome!

If you’re an Agility fanboy (or girl) like me, and specifically if you’re a Scrum Master, you’ve probably preached to developers and Product Owners and Stakeholders about the need to not have a plan. Or rather, you probably educate them about how plans change and how by not having a firm plan is actually an enabler and permitter of change. It also breeds the ability to cope with change. After all, how many agile projects do you know of that use a Gantt chart to work out what’s happening deep into the future?

Death and Taxes

Life’s two certainties, according to Benjamin Franklin. I’ll add a third: uncertainty. Nature has no plan and has little respect for yours. Making a plan for life is fruitless.

OK, harsh and depressing words admittedly,  but allow me to provide some solace. The journey you embark upon while trying to realise your life plan is likely to be more fruitful than the plan’s conclusion. In fact, I’ll bet it’ll always be more fruitful. This is because life and Nature throw things at you which you never expect, and it’s by coping with those changes, those curveballs, those monumental cock-ups, that can force you to change direction, make a new plan, invest in coping strategies (in case the same thing happens again), run away and hide until you think of a way to deal with it, and the rest. And it’s highly likely that after you’ve made these adjustments, you’ll feel happier or, to quote the aforementioned ad campaign, “better.”

And so it is in software development. And music production. And bathroom installations.

I’ll end with these words from humanistic psychologist, Carl Rogers

The good life is a process, not a state of being. It is a direction not a destination.

Agile, Scrum

Keeping It In The Retrospective

No Comments

“What happens in Vegas, stays in Vegas” so the saying goes.

Retrospectives are a well-known, but not necessarily well understood or well executed ritual from the Scrum framework. In fact, retrospectives have been around in one form or another long before Scrum became mainstream.

This is what the Scrum Guide says about retrospectives:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”

Over time the retrospective ritual has grown to encompass not just the previous sprint’s activities, but the well-being of the team. Esther Derby, co-author of Agile Retrospectives – Making Good Teams Great, says:

“..retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so.”

At Bright Interactive we have several teams of different sizes and with different purposes and goals. For each of them, we have regular retrospectives. If they are facilitated well, and certain constraints are put in place, they turn into valuable gatherings where real change can happen.

Retrospectives deserve and have many books written about them, so I’m not going to delve into the subject any further, but there is one thing I want to share with you: transparency.


Much is made of being transparent within agile practices. In Scrum, for example, the Scrum Board is an information radiator, allowing everyone and their dog to see the progress made by a development team; the Definition of Done is supposed to be a publicly-visible contract, open to scrutiny; and likewise, the retrospective is a time in which all team members have an opportunity to talk openly (bound by the team’s Working Agreement). However, recently at Bright Interactive we’ve been trying something different with our retrospectives: secrecy.


OK, so “secrecy” is a bit strong here. Up until recently all of our retrospectives have been published internally for the whole company to read. This in itself is not a bad thing, as openness and honesty are good things for teams to practice. But we tried an experiment with one of our teams: we said that everything said in a retrospective would stay in the retrospective. Once a retro’ exercise had finished (for example, variations on Speedboat, Starfish, Mad Sad Glad and the like) and an action or two had been agreed upon – this is important – the board would be wiped clean and all stickies consigned to the bin. We did this with agreement from the team first, naturally.

As soon as we tried this, the team was more open and explicit (in a good way) about a lot of the things they wrote up on their stickies. At first we were concerned about the items that gone thrown away, but once they had been discussed and an action settled upon (which we do for every retrospective) this didn’t seem to irk the team. Normally, many of the trashed items related to specific events from the previous week, and those items which transcended several weeks or iterations would come up again in subsequent retrospectives anyway.

That said, this is an experiment. If the team decides that documenting retrospectives bring more pros than cons, then we’ll resort to that. In the meantime, we’ll keep it in the retrospective.

Agile, Music

On the Agile Nature of Music Composition – Part One

1 Comment

When I’m not working as a Scrum Master, and when I’m not doing my dad duties, or decorating my house, or the myriad other things life throws at us all, I try my best to write music. How I go about doing this warrants a couple of posts in which I’ll share my methods and maybe you’ll end up understanding why I think there’s an essence of agility to music composition. I’m also delivering a presentation at the Brighton Lean and Agile Group where I’ll be attempting to demonstrate, live, how I go about composing a track.

Part One: Something From Nothing

cassette-tapeElectronic music has been a passion of mine since the early 80s; aged 11, my teacher thrust a cassette tape into my hand and said, “Listen to this!” – it was a recording of Jean-Michel Jarre’s Oxygene and Magnetic Fields albums – and it blew my mind. It sounded like the sounds of the Universe. Of course, back in the 80s synthesisers and sequencers and drum machines were not only prohibitively expensive (particularly for an 11 year old) but large and clunky. I could only dream of being able to create the stuff I was listening to on vinyl and on the radio..

Fast forward a few decades and making music has become something far more accessible to the masses. Of course, one needs the determination and time to navigate round the multitude of software synths, DAWs (digital audio workstations), drum machines, sequencers, effects, samplers, loop and sample libraries. But that said, music composition is now a pastime that anyone has access to. I even know artists that have released commercially successful albums created entirely on their iPhones!

Mixer view from a Digital Audio Workstation or DAW (in this case, Apple’s Logic Pro X)

However, all of this technology means diddly squat if you’re lacking creativity.

Creativity Defined

Wikipedia has an entry for creativity saying it can be defined as, “the process of producing something that is both original and worthwhile.” It goes on to talk about some of the empirical studies into creativity and how it may arise in the mind. I’m truly fascinated by all of this, but on an everyday level, I am more taken aback by the apparent ability of the mind to create something from nothing.

“Creativity requires the courage to let go of certainties” – Erich Fromm

Is Composition Agile?

Being an agility practioner, it dawned on me last year that the process I go through while writing a track seems to reflect many things that are spoken about in agile software development and the greater agile community. But before I try to answer the question, “Is it agile?”, let me share with you how I start attempting to write a piece of music.

I Don’t Know What I Want

When I sit down at my Mac of an evening, I’m normally in the mood for creating something. But, I don’t know what. I have a rough idea of tempo, or sometimes genre (such as ambient electronica, a remix, banging techno or just a noise-fest), but that’s it. Unlike other more traditional composers, I don’t have a tune in my head. Nada. And this is where the intrigue starts.

It Begins With A Sound

Some composers have a melody in their minds before they sit down and start writing. They may find themselves whistling a tune, or humming a chorus and have a eureka moment, immediately putting their ideas down on paper if they can read and write music, or audio recorder or other tool. Sadly, I’m not one of these gifted people. When it comes to a new piece of music, my mind is a blank canvas. For me, a new composition emerges from a sound.

A Wave!
An audio wave

Sitting in a folder on my Mac are gigabytes of audio samples. Some are from purchased libraries, others are freebies given away on the cover of magazines, some are my own recordings taken ‘in the field’ so to speak. Their source is irrelevant. What’s important is their potential to be distorted, mangled, reversed, looped and chopped and therefore turned into something which barely resembles their original form. Like software developers, music producers have a seemingly never-ending choice of tools at their whim. And like developers, we all have our own favourites and preferences. I use Apple’s Logic Pro X; a pro-grade DAW used in bedrooms and professional studios across the world. But the tools aren’t important for this story. I take a piece of audio and within an hour, I’ve put it through an LFO-driven low-pass filter, routed it to a stereo delay effect, taken the signal and applied a little bit of plate reverb, then a bit-crusher, a channel EQ and finally a smattering of compression.

Another source may be a synthesizer loaded into Logic. Almost every synth works on the basis that you have an oscillator, a filter and an amplifier. With just these three basic building blocks, I can create a sound (or ‘patch’ because in the old days synths literally had patch cables that allowed you to route the signal output by one oscillator into the input of another) that is truly unique.

The end result of this experiment is normally a sound with a rhythmic aspect to it. This provides me with the backbone of whatever comes next. Listen to the Before and After sounds, below, for an example of how I took a sample from NASA’s Cassini mission to Saturn, and turned it into something ever-so-slightly more musical.


In my next post: Happy accidents and serendipity..