In one of his recent weekly email tips, Mike Cohn wrote about eliminating inefficiencies by making them visible.
Mike wrote about a scenario where a team was trying to work towards a goal, but made limited progress because their efforts were repeatedly diverted onto other work – such as client issues, emergency fixes, and so forth.
The solution he described for this type of situation is to make the interruptions visible so that you can measure their impact, understand the nature of the work, and then manage them.
The best approach is to eliminate these inefficiencies – but if you can’t prevent interruptions, it’s possible to at least plan for them.
If you go down the path of planning for the interruptions (adding a buffer to your iterations), then you’ll want to measure how the team is tracking against the allocated buffer.
I once worked with a team that was plagued by unplanned work – interruptions from other teams that were “urgent” and would only take a little bit of time… the “can you just help me with this” type of stuff.
To help make this work visible, we planned a block of “unplanned” time each iteration for each member of the team, then allocated them a number of “hourglass” tokens – each worth one hour of effort.
We set up a wall, the O.S! Wall, that had two columns – “Available” and “Used” – and a row for each team member. At the start of each iteration we put each person’s allocation of hours in the “Available” column.
“O.S!”, by the way, was officially known outside the team as an abbreviation for “Out of Scope”, and colloquially inside the team as “Oh, shit!” – as in “Oh, shit! We hadn’t planned for that!“.
As they responded to the ad hoc requests for work, team members recorded the time they spent by moving the hourglasses from the “Available” column into the “Used” column (an hourglass turned on its side was worth 30 minutes).
At the same time they completed an “O.S! card” that recorded, amongst other things, what the task was, who requested it, a high level category to describe it, how much time it took, and whether it had been approved if necessary by the Scrum Master or Product Owner.
The board gave a very clear visual indication as to how much of their unplanned time they’d spent through the sprint. The O.S! Cards allowed us understand the types of issues were coming up and how much time was spent. We punched the data into a spreadsheet each iteration to chart the trends over time.
The aggregae time data allowed us to predict how much buffer we needed to allow in each iteration. The details we captured on the O.S! cards allowed us to learn about the type, effort and frequency of interruptions the team experienced, and to plan techniques for eliminating these types of work in the future. For example, a high number of report requests could indicate the need for a a self-service reporting tool, or provision of some report writing training,
Being required to go through this process also helped train our team to be a bit more discerning when it came to assessing each unplanned task. Having a visible “O.S!” limit forced them to decide if a task was really as “drop everything” urgent as claimed, or whether it was something that could be pushed back on and planned as part of the regular iteration cycle.
If an individual ran out of hourglasses, then they could trade off planned work with someone who had spare hourglasses (if they were truly the ONLY person who could do the ad-hoc request).
If things got really bad and they just HAD to go in excess of their planned unplanned time, they could get permission to use limited number of “red” emergency O.S!. hours – but only after negotiating with the product owner / scrum master around the impact on the planned iteration.
The O.S! wall ended up being a really useful tool for visualising, tracking and managing these unplanned interruptions to the team.
If you have any tips on managing unplanned work, I’d love to hear them – please share in the comments!
This article is based on the session I presented with Nigel Dalton (CIO, REA Group) at Agile Australia 2016. It explores some of the things I learned about high performing teams while watching my favourite blues band, and includes insights provided by Nigel as an amateur musician.
The band is led by Geoff Achison, a self-taught guitar virtuoso, whose infectious and inventive style has earned him many fans – and awards – around the world. You can hear some of the Souldiggers’ work on Geoff’s YouTube channel.
The inspiration for this article came while watching them play at a small hotel in Belgrave, the Micawber Tavern. I realised that many of the characteristics that make these guys such a great band were the same things that can apply to Agile teams.
I’ve been following the band for about 12 years, ever since a friend loaned me a CD of one of their live shows, and have got to know Geoff well through talking with him at gigs.
That’s Geoff on the left on lead guitar and vocals, Gerry Pantazis on drums, Roger McLachlan on the Bass guitar and Mal Logan on the keyboard.
At Agile Australia 2016 in Melbourne, Jeff Smith, CIO at IBM talked about Pixar, and how they hire musicians because of their habits of rigorous practice and understanding that grim determination is part of success. But as musicians, they exhibit many other desirable characteristics when they play as part of a band. Things like trust, leadership, communication, having a shared vision, empowerment, giving & receiving feedback and having fun.
In a band, all members rely on each other to play their part – without any one individual, the music doesn’t sound quite the same.
Like any other team, to deliver the best performance, the band needs to be able to trust each other – trust they’ll keep in time, play the right tune and – if something goes wrong -trust they will cover each other.
An interesting example of how trust came into play was when something went wrong for the Souldiggers at a gig at the St Andrews Hotel. This particular night, the pressure for a great performance was high – the band was filming the show for a live DVD project and had spent a lot of money on cameras, lighting, audio recording equipment and so on. As luck would have it, Roger McLachlan – the bass player – broke a string right in the middle of a song. But because he had complete trust in the rest of the band, he remained calm and didn’t panic.
The band played on while Roger grabbed a new string, fixed his guitar, and joined right back in as if nothing had happened. When I asked Roger about this recently, and he said “it was all cool… I knew the guys would catch me if I fell.”
The resilience demonstrated was a result of the trust that the band had developed over time.
Nigel expands on this – “Agility, with its practices and humanistic foundations, leads to resilience for a team or organisation. But it doesn’t automatically lead to innovation, as everyone from Clayton Christensen to Dan Petre have pointed out.” Nigel also postulated that “maybe, Agile development should have been called ‘resilient development’?”
So how can you foster trust within an Agile team?
Pay attention to the way that team members interact – take the time to get to know each other as individuals and develop a level of care for each other. A high level of intimacy leads people to not wanting to let each other down, and builds a stronger team as a result.
Be credible – don’t let members stretch the truth about abilities or qualifications and allow them to demonstrate their expertise as part of the work they do.
Be reliable – make sure everyone delivers on commitments – be it individual or team commitments – things like arriving at meetings on time or making sure that things are done properly without shortcuts. And if someone can’t deliver on a commitment, make sure it’s communicated early.
Be open – if you make a mistake, don’t try and hide it or blame others. Own it and learn from it. Be prepared to put yourself out there for scrutiny and invite feedback.
Address issues directly – building trust relies on having courage to raise concerns with someone, rather than bottling them up or referring to a manager for action.
Trust is about creating an environment where people feel safe – safe to speak up, safe to innovate and safe to fail.
If you’re forming a new team, developing a social contract as a group is a great way to kick start group expectations and begin the process of building trust within a team.
The singer in a band is often referred to as the front-man and most people assume that they’re the one in charge.
Often though, the roles can change throughout a song or a show. In fact, the bass player has a huge leadership responsibility as they provide the foundation of a song – the rhythm and the harmony – which determine the style. It doesn’t matter, for example, if the lead guitar is trying to play blues if the bassist is playing reggae!
Nigel observed that the bass player’s leadership “…is not ‘boss-ship’. It’s much more akin to servant leadership, which is why the bass player is so under-recognised.”
In a great band, anyone can step forward to take the lead and have a major impact on the final result.
Geoff sums it up wellwhen he says “… we’re mixing ourselves as we’re playing, so at different times, different instruments will be stepping into the fore to take the lead.”
This shared leadership means that it’s not “…one dude, standing up the front playing licks over the other guys while they’re just in the background” but that “… everybody is doing something fantastic.”
In Agile teams, you want everybody to do something fantastic too, and leadership roles can and should change.
Developers can lead the direction based on technical decisions
Iteration Managers, Scrum Masters, Delivery Managers – or whatever you choose to call them – can help lead the team to continually improve the way they work.
Product Owners can affect the direction and delivery of a product based on prioritisation
The best teams work together to deliver a goal, and share the responsibility of leadership when needed.
Geoff has an interesting model for the Souldiggers. While he has a regular group he plays with when he’s at home, he can form a band with different musicians, no matter where he is.
He realised early in his career that if he was to tour internationally, it would become very expensive (and hard to co-ordinate) taking the band with him each time. So he developed the concept of forming a band in each location, using local musicians – The Souldiggers. To do this, and still be able to play HIS songs, he relies on both the skill of the performers and on being able to give them a shared vision of what each song should sound like.
Apart from sharing examples of their previous work, musicians can use known patterns for songs, for example describing a song to a musician as a Texas Shuffle, a Slow Blues or a Reggae to quickly communicate an understanding of the particular style of a song.
What Geoff is doing is art, but it’s still a business – being able to communicate the shared vision allows him to take his art around the world.
Sometimes, a band might get together for a short term “project”. Nigel’s experience playing with bands in the Battle of the Agile Bands charity shows highlights the importance of establishing a shared vision to get everyone up to speed quickly.
In a software development team, you’re not reproducing a piece of music, but working on a new “piece” each time, however there are still common patterns – a customer address form, a shopping cart, a search form or a search results page – which all provide a general understanding of what’s being built. This shared vision allows the team to work together to a common goal.
You can help develop this by getting the team involved from the very beginning, using inceptions and workshops that define the outcomes and the objectives of a product. As a result you allow everyone to understand what’s needed and attain alignment.
These types of activities also help develop a sense of ownership within the team. When everyone is so engaged and invested from the very start, an emotional attachment is formed and the (final) product becomes their “baby”.
It is also important to ensure everyone still continues to understand the vision throughout the lifecycle of a product.
Autonomy / Freedom
With a shared understanding of what your final product is supposed to be – whether a web application or a song – the team can feel empowered to make the right decisions that produce the best outcome.
In jazz and blues music, there is often a lot of improvisation. Despite seeing the Souldiggers play many times, there’s always something new in each performance that keeps the music fresh.
A different twist from the bass, the drums, the keyboard or the lead guitarist – each musician is trusted and given the freedom to tweak things as they play… improving, inspecting and adapting. Once you’ve got the basic pattern right, it’s easy to build from that. When it’s someone’s turn for a solo, they’re free to soar and let their creativity shine, whilst still staying true to the spirit of the song. Despite all the improvisation that may go on, the song remains recognisably the same.
Roger McLachlan talks about having freedom – “… it’s always a lot of fun though, because everyone’s free… to contribute any ideas.” It’s also interesting to note that Roger makes the comment that, “…you can’t play any wrong notes in this band” – the key element of trust plays a big part here – the profound trust they have in each other provides the platform for the freedom to experiment.
In Agile teams:
Share the goal and then allow individuals to make their own decisions about how to deliver it – let the team decide what development platform to use, what software architecture is best or the type of user experience they decide to implement
David Marquet, author of “Turn the Ship Around!” and one of the keynote speakers at Agile Australia 2015, talks about pushing authority down to where the information is – allowing people with the knowledge to actually make the decisions.
Tell the team where they need to go and let them figure out how to get there – Spotify’s video on their engineering culture from 2014 describes how alignment enables autonomy, and the differences between telling a team to “Build a bridge” or that “We need to cross the river”.
One of the things about the Souldiggers that never ceases to amaze me is that the band never uses a set-list – the pre-planned list of songs that many bands work from during a show.
Instead, Geoff picks and chooses songs during the performance based on how he reads the room. Throughout a show, he’ll keep an eye on the vibe and energy of the audience, and choose what the band plays based on feedback, such as applause, the number and energy of the people on the dance floor and the atmosphere in the room.
They’ll build up the intensity of songs to a peak to get the crowd dancing and then slow things down with a more laid back tune to give the audience a break . And of course, they will take requests from the crowd – Geoff welcomes fans calling out song titles as inspiration for what he’ll play next.
If we think of the audience at each performance as Geoff’s customers, then people jumping around on the dance floor is certainly an extreme example of positive customer feedback!
An Agile team can also use customer feedback, although it’s seldom as direct and immediate as a band will get.
You can use tools such as click tracking, conversion funnels, heat-maps, sales volumes and other data to measure the impact and value of your work.
Customer feedback forms, focus groups or user test sessions also provide valuable insight.
At carsales, developers spend time listening in on our customer service calls so that they can hear feedback directly from our users.
Don’t forget that feedback isn’t just about being from customers. Feedback within the team about both the product and the way that the team works together, and feedback from stakeholders is just as important.
If you look at the bottom left of the next photo, you can see a bunch of wedge shaped speakers pointing back at the band.
I always wondered what these were for, so one night I asked Geoff. He explained that they’re part of the foldback system which allows the band to hear each other so that they can stay in time and in tune with each other.
Nigel jokingly suggests that the foldback speakers are actually intended for standing on to create the perfect “rock ‘n’ roll” pose!
If you pay attention, you will also notice the band communicating throughout a show. They’ll count in a song so they can all start playing together, they’ll communicate about what song to play next, who’s going to take a solo or when to repeat a passage of music. Sometimes that communication is not verbal, but a gesture, a look, or even just playing a few notes to lead into a particular song.
Listening is key. Geoff talks about how “everybody is listening to everybody else, and you play according to what you’re hearing”.
Agile teams should also communicate constantly:
Through rituals like the daily stand-ups and regular retrospectives
Informally – by just turning around and talking to one another
Through activities such as inceptions and workshops
Using tools like Slack, Hipchat or Skype
Wherever possible, encourage face-to-face communication
Nigel reflected on his first time as a player at the Esplanade Hotel in Melbourne’s busy St.Kilda – “Being on stage is incredibly noisy. Everyone has their own amp or instrument and a foldback, which contains a mixture of their own instrument plus something they want to key off – lead vocals, keys, or bass. Everyone is different. It was such an overwhelming experience, I nearly fainted with the noise and stress of being on that stage. It was so loud, I couldn’t hear my own amp, so I just played and prayed.”
Activities like standups, retros and inceptions can be just as overwhelming for a newbie to Agile, so this should be taken into consideration when someone new joins your team.
Fun and keeping a band together
Geoff and the band have a pretty busy schedule, sometimes playing multiple gigs in a week. I thought that, playing so many of the same songs over and over, it would be easy for things to get boring, so I asked them about this. I was surprised when everyone in the band made pretty much the same comment – “if it was boring, we wouldn’t do it”.
It became obvious through our conversations that they get great pleasure from their passion for music and playing with other great musicians.
The freedom they have to mix things up – playing riffs off each other, improvising during a song or a solo, trying out new material – and the sense of being part of a great team – all help to keep it fun and fresh.
The Souldiggers recently celebrated 20 years, which is a long time for any group – so how can you keep a band together and having fun after so many years?
One way is by giving the band space to work with other people and another is encouraging them to have other musical interests.
Apart from playing with the Souldiggers, Roger, for example, has released solo albums, co-written a musical, and helped build an online singing lesson website. Gerry plays with three other bands and is a performing arts teacher.
In the Agile world, we can also look at ways of letting teams have fun, by allowing people to take on side projects, or scheduling hack days, or getting them involved in the maker movement.
All of these activities help to build mastery and provide an opportunity to express creativity and network with peers.
Sometimes you can do things just for fun.
Last year at Carsales I created a series of events called the Tribalympics – five novelty competitive challenges that teams participated in throughout the year. Tribalympics had nothing to do with our work, but was aimed solely at bringing tribes together in a social context and injecting an element of fun into our workplace.
Knowing when to stop.
Nigel mentioned that, unlike recordings on CD, “there are no fadeouts in live music” so it’s important for the band to communicate with each other about how and when to end a song.
The same holds true for Agile teams – knowing when to stop development and release a product is an important aspect of Agile.
Everyone’s heard of MVP and MMP – figure out what the core pieces of your product are, build these, and then release it!
Don’t let developers over-engineer or gold plate code… all this does is add complexity to a product and delay the delivery of value to the customer – one of the seven wastes of lean systems.
Build features based on user feedback, not what you as an individual may think could be useful or cool. Too often, products are over-done with the inclusion of features based on what someone thought the user might need, rather than based on consumer research.
Ultimately, it’s all about working together and creating the best outcome for your ‘audience’, whether they are a passionate fan or a customer. So listen to what they want and understand what they need and you can make beautiful music together!