On the topic of Trombones…

I got thinking a bit more about playing my trombone. Something I need to do more. I don’t get to play much any more, but I really did enjoy playing for many years. Maybe I’ll find some others to play with.

I played in orchestras. I played in concert bands. I played in military bands. I played in jazz bands. I played in brass quintets. And I played in other various groups with various other instruments. But the group I enjoyed playing the most with is the brass quintet. There are a bunch of reasons for this, and it very much relates to how I like to work today.

You see, in a quintet, there are five voices. It’s a small group, and you get to really know your peers, and have to work really hard at working well with them. It’s not about any of you individually, but about the five of you together. No one is in charge; there’s no leader, per se. We’re all leaders, and we all have accountability to each other, and to our audience, or customer. It’s just the five of us, all working towards a single, shared common goal. We all have to work together, listening to each other, complementing each other, supporting each other, critiquing each other. If we don’t? Well, there’s no one to hide behind. It’s just us. Each playing our part, which come together to produce something amazingly superior to the sum of our five parts.

It also forces five committed people to be their best, and continually work to improve personally, and each other. There’s nowhere to hide in a quintet. Not that I ever hid in any of the other settings, but it’s not the same when you’re one of a number people playing a similar – or even the same – line of a piece. That doesn’t happen in a quintet. There’s no one else playing your line. It’s just you. It becomes pretty obvious pretty quickly if you’re not pulling your weight. And it’s the same with everyone else in the quintet so they’ve got to be equally committed, and equally interested in being the best they can be, finding ways to get better individually, and helping each other make the quintet as a whole even better.

By the way, if you want to see some of the best musicians in the world, a team who practically invented and popularized the brass quintet, have a look at the Canadian Brass.

Trombones and Agile. Wait… What?

So, this might be less about the trombone. It could be about any musical instrument. But, in my case, it happens to be a trombone. Actually, for many years, it was a bass trombone.

The funny thing about the trombone is that in an orchestra, concert band, or military band, the bass trombone very rarely caries the melody. It very rarely caries the counter melody. There are pieces where the trombone is featured, but really, not most of the pieces in these settings.

If you look at who gets the recognition and rewards, it’s the soloist. It’s not the bass trombone player. Believe me. But, being the bass trombone player, playing the music in front of me, I get a huge amount of personal satisfaction. You see, I know that for that soloist, for that melody, for that thing you reward: I’m the one who made it sound great. Yep. It’s true. The melody of pretty much every piece of music is hollow without the counter melody, the accompaniment, the supporting foundation that allows the melody to sound amazing. And I get to be the one to provide that.

It took me a long time in my career to realize that the role I play with my team is the same. I don’t want to be in the spotlight. Not that I’m not great at what I do – or at least think I am. I am pretty darn good at what I do. But what makes me great as the Scrum Master or Agile Coach is that it’s not about me, and I don’t want to be the focus of anything. I’m just the guy who helps the team be amazing. I’m the guy helping the team remove anything and everything that’s preventing them from delivering great quality code and delivering iterative and incremental business value every single sprint. I’m the guy helping everyone involved with the project work together.

If the team I’m on, the team I’m working with, succeeds, then I’ve succeeded too. It’s not about me. But it’s sure great to see the team succeed, and knowing that I played my part in helping them shine.

A Recent Experiment on Reporting

I’ve been working with one client, well, not just one, but this post is about one. I helped them out a year or so ago launch a new website, although it was the entire team, and I was just a very small part of it. But, for the purpose of this post, I’m going to take full credit for everything.

It went pretty well. We delivered what they were asking for, but it took a lot longer than we expected it to. There was overtime. There were additional sprints. There were sections we threw out and then rebuilt because we didn’t like them as we learnt more. But in spite all of this, it really did go okay. The client was mostly happy, and the end product was far better than had been originally envisioned (and wireframed by a design agency).

In spite of the road bumps along the way, the client came back and asked us to do another site for them. So, step one was to look at the wireframes they’d spent about six months creating and getting sign-off on. No problem… We’d built a site for this client less than a year ago, had familiarity with their domain, and building it with the same technologies. So, we estimated the time it would take us to build what had been designed. We came up with a number, and took that to the client.

I was lucky. I wasn’t in the room when that number was presented. I was told it wasn’t a fun conversation to be a part of.

Basically, the number we’d come up with wasn’t in what they thought it would cost, or how long it would take. But we knew, because of our experience on the first project, that we were in about the right range, for what they were asking.

Round two: We had a look at their scope and tried to figure where we could reduce some of the scope or complexity. We found a few places, and reduced the length and cost of the project by about 20%. Maybe 30%. Still, we’d be delivering a pretty functional site, with pretty much everything asked for, but just streamlining some of the designs and workflows.

This time, I was asked to come along and present this to the client, so I could help them understand the amount of work required. The meeting went a lot like this one: https://www.youtube.com/watch?v=BKorP55Aqvg – especially the part when they point out they’re only asking for seven red lines, it’s not like they’re asking for 20 red lines… Sigh. Our estimate was still over double what the client was expecting.

I asked for the client’s budget and timeline. Why keep guessing, if they’ll just tell me. And they did. So, off I went, not really sure if I’d be invited back. Ever.

But I was invited back. And this time, I was prepared. I’d taken their budget, and we’d figured out what we could do for that amount of money and time. We’d figured out a way, at least our best guess, to deliver a fully functional site for the amount of money they had. And we closed the sale.

You might be thinking that’s the end of this story. And you’d almost be right. Except that now that we’d sold the project, we had to deliver it. And I was under a huge amount of pressure to be able to show if the project was on track or not. After all, we’d shortened the delivery time by more than half from our original guess.

The problem with this is that we didn’t have a fully created backlog, no way of really knowing the total scope. In order to sell the project, we’d eliminated any up front work, opting to just start development. What a novel idea…! And, about three days into this project, the client came to me and told me that there’s a new section they’d like to include. A very complex section. Never scoped before, never discussed before. But this was absolutely needed, no matter what, for the site to launch. My response? Of course we can do it; other features might need to be deferred to a second phase, but of course we could do it. One other thing I did – I asked if we could restructure three of the six sections we’ve already got in scope, streamlining them to not only deliver a better user experience, but also afford us more time to work on this new, must-have, feature. There was agreement on this, and off we went.

I spent the first sprint trying to get a handle on all of this, and at the end, reported it “red”. After all, I had no way of proving one way or the other if we’d get everything done. And as our first sprint, we didn’t get nearly as much done as we would have hoped.

By the end of the second sprint, I was still reporting this project in red. I still couldn’t prove, with hard data, if we were on track or not. But if anyone had a conversation with me, or asked what was going on, I would have told them that we’d already figured out two of the most complex parts of what we needed to do. We had a backlog now that would take us to the end of the fourth sprint.

During the third sprint, the backlog that we’d been working on changed again. Yes, we’d learnt some stuff along the way that would impact future work, and would impact what we could deliver. In a good way. We figured out how to deliver a couple of things slightly differently that would reduce the development effort. And, new features were identified.

For the fourth, and fifth sprints, I was still reporting the project in “red”. I was being berated for my inability to move this project out of red, and not know what the future would hold. My customer, by the way, wasn’t ever fazed by this – they took in stride. They knew what work was being done. They could see huge velocity improvements, and could see that their site was coming together. They were creating and publishing content along the way, and providing feedback on a weekly – often a daily – basis. They were totally engaged with the development team and were all working towards the same goal with a shared vision. This entire time, I was told on a regular basis that I’m wasn’t meeting expectations.

By the time we arrived at the end of sprint six, through lots and lots of conversations, and an amazing dev team who had been improving every single sprint, and identifying new ways to deliver better code even faster, the client was thrilled with the progress and at a point they were able to think about actually going live and replacing their current site. I started reporting the project health as “green”.

We completed the work in eight sprints. The decision to go live was now totally within the control of the business team, when they determined the timing would be right for them. This was faster than our final guess – we’d actually sold a fixed price project with nine sprints. But, we completed the work in eight. In fact, we completed way more work than had been originally scoped for those nine sprints.

Some might think I got lucky. Perhaps. But I know how much work I did managing expectations, saying no without actually saying no, refocusing asks on ways we could deliver something that would solve their problem… And, making sure that the team felt safe to identify things that were getting in their way, and helping to get those things out of their way… And creating a safe environment for the team to try things that they thought might help them go faster, without worrying about someone speaking to them about doing something, or implementing a tool, or writing a script, that wasn’t part of any story, but just something that would allow them to deliver better quality code, faster.

Yeah, it was an interesting experience and experiment for me. I’m pretty proud of the team I got to work with; pretty proud of the product; pretty proud all round.