Music, Product discovery

On iZotope’s Product Development

No Comments

I’m a music buff. In fact, I’m a bit of an amateur producer, creating music “in the box” whenever I can.

In the box means I pretty much exclusively use my laptop or iMac as a recording studio. The audio production tools available to producers and musicians are stunning, and used by every top studio on the planet, pretty much. Exponential growth in computing power has allowed this.


But with all this power comes great responsibility. The users of such software care deeply about their music, and that’s what they want to focus on. But the world of audio engineering is highly technical and can take years to master. So how do software companies that create digital audio workstation (DAW) applications, and their associated plugins, marry this need to be creative with the deeply technical nature of production?

One such company is iZotope, based out of Cambridge, Massachusetts. They’ve been developing DAW plugins (all DAWs have an architecture that allow them to be extended using plugins developed by 3rd party companies, like iZotope) for years. They’ve made headlines recently with the release of iZotope Neutron.

Take a look at this short video describing how they tackled writing such a complex piece of software. You don’t really need to understand what it does; instead notice how they talk about pair programming, TDD, and code reviews. You’ll probably spot developers demonstrating software to their peers, and I think you’ll catch glimpse of what looks like a User Story Map.


Product discovery, Scrum

On Discovery Of Product Discovery


What A Difference A Year Can Make!

About this time each year, I don my scrum master cap and visit the University of Sussex to deliver a lecture to under graduates and MSc students on Scrum. And each year I find myself having to modify my lecture to take into account the ever-changing state of the framework and the experiences I’ve picked up during my agile travels.

Some lecturers might find this constant evolution a pain in the ass (after all, rewriting a lecture isn’t exactly fun), but I think it’s testament to how awesome practices like Scrum are.

What A Difference Three Months Can Make!

Earlier this year I quit my relatively secure scrum master job in Brighton to go freelance. It was a daunting move with, typical of so many big decisions, the procrastination being more painful than the execution. I walked into a scrum coaching role expecting to use my well-practiced skills on a new scrum team. You know the stuff: mess with the rituals, add some vigour where it’s needed, help the team find their happy place. All great stuff and indeed the bread and butter of scrum mastery (yes, I know there’s way more to it than that, but I need to keep this post relatively short and most of you know this stuff already, right?).

If you spend too much time thinking about a thing, you’ll never get it done. – Bruce Lee

The team’s product owner is a really bright star, eager to take the product to another dimension. I recall having a chat with him over coffee about roadmaps. We were talking about Roman Pichler, goals, MVPs and all that well-documented awesomeness and I dropped into the conversation that I particularly loved Jeff Patton’s work on User Story Mapping and Gojko Adzic’s Impact Mapping techniques. I’d been aching to use these techniques more and now I had an opportunity to introduce them to a team that hadn’t dipped their collective toe into such waters. I eventually ran a User Story Mapping workshop with the product team. I ran five Impact Mapping sessions with “the business”. Both techniques were received positively.
But I found myself questioning the validity of it being me doing this work. “Is this a normal scrum master duty?” I asked myself. “Am I abandoning my teachings?” I postulated as I rubbed my stubbly chin.

Intellectual growth should commence at birth and cease only at death. – Albert Einstein



Fast forward to today. I’m now no longer my client’s scrum master. Instead, I’m their newly appointed product coach, helping the product management team adopt discovery and delivery techniques, otherwise known as dual-tracking. The work I’m doing now is upstream of the typical Scrum team. We’re focussed on creating experiments, challenging assumptions, hypothesis testing, rapid learning, and user development. Of course, all of these artifacts and rituals can be considered to be under the general agile and Lean umbrella, therefore my experience as a scrum master is still relevant and applicable. But am I a traditional scrum master? I don’t think I am any more. My eyes have been opened to the value of product discovery, and I’m hooked.
I wonder how many of you reading this have found yourselves on a similar path. Please share your experiences in your comments.

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.

Other blogs, Science

Time Is An Illusion…

No Comments

…lunchtime, doubly so.

The immortal words of Douglas Adams. He had a point.

As a Scrum Master, I’m always dealing with matters of time, be it with estimates, planning, development, rituals, lunch.. time is part of the furniture of software development. But I have other interests, two of which are neuroscience (and specifically the subject of consciousness) and physics. Both of these disciplines have a lot to say about time, and how its passing basically is an illusion.

On my travels around the web, I curate a couple of public Flipboard magazines. This one is stuffed full of stuff about Agile things and in this one I collect stories about science. Today I added this Scientific American article entitled “Time on the Brain: How You Are Always Living In the Past, and Other Quirks of Perception.” I recommend you read it. If you have time..