Berry With A Beat

I am now a professional mime.

When the Internet decides to be slow, in turn cutting out the audio component of a meeting I’m in the middle of with my teammates in Romania or India, the HD webcam stays rolling, like an out-of-date analogy, my face lights up, like Garry Kasparov playing chess, and my hands are all over the place, like an Italian stereotype.

I lead teams that are not in the same room, so to mitigate the 3 continents and 10.5 hours between me and, say, Vivek & Mihai, I:

  • tell stories to bring people together, like how I ran into Kevin Spacey at a Starbucks
  • show and tell the random things lying around our conference rooms, like little trinkets like oversized clothes pins and 3D-printed Sesame Street characters
  • intonate exaggeratedly, because our budget doesn’t allow for teams to have studio-grade microphones & speakers to share speech subtleties
  • apologize liberally, because I am often cutting people off since it is not always clear when somebody has finished sharing their thought because of an audio lag
  • pause often, because teammates often start talking for a few seconds before realizing they have yet to unmute themselves
  • insult them flatteringly, like, “oh no no please, the top of your head is so well shaped… please don’t ruin this experience by showing the rest of your face.”
  • explain that what I had just said was a joke, because sarcasm does not always travel across national borders fully intact
  • crack jokes, because it brings people together via laughter

I will sing and dance and still be productive so that people know that when you come to my meetings, you know you will leave with a little more funk, and your day will be a little sweeter. This is my flavour of ScrumMastery; I am a berry with a beat. My goal is for you to leave as a berry with a beat.

Oh, what joy it is to create a berry with a beat.

Pain Is Just Information

I took a systems physiology class in college one summer, and on the very first day, the professor said, “If there’s one thing you remember from this class, it’s that ‘Pain is just information’.” Pain let’s you know something is up. Or down. Or out of place. Or stuck in place. Or generally amister amiss.

(This blog post is about a conversation from work. I’ll try not to make these boring and solely technical, but if you decide to give up on reading this because you’re emotionally distraught over Scotland not being its own country, remember: Pain is just information.)

Now that I’m a ScrumMaster by day (your local superhero by night), I get to talk through sticking points that my team members have with parts of the process, and the point that was sticking this time involved the Sprint backlog.

(I can’t believe it… to be your own country… you get to stay up as late as you want, eat haggis whenever you want, drink scotch whenever you want…)

During the Sprint, something may come up that we as a team end up working on, with the Product Owner’s blessing, that wasn’t planned for in the Sprint Planning meeting. The question is: If we can add things to the Sprint mid-Sprint, why can’t we remove the things we now know we won’t get done mid-Sprint?

(…skinny dip with my sheep in whatever loch I want…)

Seems like a decent enough question: by accepting sudden stories, you’ve already blown out the original plan, so why not update the plan based on new information? Since the Spring backlog is what the team committed to doing at Sprint Planning, it’s easy to understand why the team doesn’t want to see this thing they know won’t get done: it’s embarrassing, or it induces anger, or it elicits some kind of negative emotion (or else the team wouldn’t be asking to get rid of it), some kind of pain.

(…wear kilts as short as I want…)

The way I sell this is via acknowledging this ‘pain’ as not necessarily bad, but useful: at the end of the Sprint, the stories that do not get done represent a quantifiable adjustment to consider during the next Sprint Planning session. If no ‘outside’ stories were brought in mid-Sprint, then the undone stories represent the team planning to do more than they could pull off. If the story points associated with the dragged-in ‘outside’ stories were the same number of story points associated with the undone stories, then the undone stories were neatly ‘displaced’ by the sudden stories and the team did a spot on job of estimating how much work it could pull off.

(Did you hear about the Scottish cross-dresser? He wore pants.)

Sure, it feels icky to leave things undone, especially when you said you’d do ’em, but if it’s because the Product Owner asked you to do something else, then heck, it’s totally not your ‘fault’ – the person in charge of prioritizing work… reprioritized work! And this was the particular scenario of the sticking point – there was pain, and it was reframed as information.

My systems physiology professor would be proud. If I only remembered his name… this sucks, I really liked that guy… man, this is embarrassing…

(Pain is just information.)

Oh shut up.

Trial By ScrumMaster

Folks, I’ve made it – it’s been 2 months since I’ve lasted blogged, and that’s because I had been transitioning away from being paid to break expensive hospital equipment test medical devices in Andover, towards being paid to crush the spirits of insolent coders coach software development teams in Boston’s Fort Point district (by South Station).

I don’t always change careers, but when I do, I prefer Dos Equis it’s exciting and a whirlwind of activity, from sending off and being sent off by my close-knit awesome team (and colleagues of 6 years), to welcoming and being welcomed by a couple of virtually-knit teams (half of my colleagues are in Romania!).

My first job was to reduce the number of unknown unknowns, i.e., yes, there’s an onboarding process to becoming a new employee (the formal stuff) and learning the social structures (the informal stuff) at a new place, so I’ve got to figure out what they even are to then address them.

My second job was to familiarize myself with the teams and the state of Scrum within each of them, i.e., learning Indian names and Romanian names, then how to pronounce them, then getting a sense of how much Scrum they know. Lucky for me, I’ve got a couple of crews that WANT to get better at this game. They LIKE the theory, and they WANT help with the practice. They’re smart and they push back on me, forcing me to lead discussions so everybody’s on the same page and willing to experiment with new processes.

It’s been trial by fire.

It’s been drinking from the firehose.

It’s been the starkly punctuated evolution of my wanting to be better at Scrum from leading a team of just me to now leading two teams of international team members.

It’s been trial by firehose trial by ScrumMaster.

I feel awesome, and since my theme song isn’t on YouTube yet, I’ll give you the next best thing.

Ladies and gentlemen, Kashmir by Led Zeppelin. You’re welcome.

Channel Your Inner Tim Gunn

I don’t always watch Project Runway, but when I do, I drink Dos Equis I watch Tim Gunn. In terms of a competition show, it’s easy to see why it’s appealing – the fashionable hopefuls take on a new challenge with 30 minutes to design and at max 2 days to make the thing.

Yes, people get kicked off the island (it’s Manhattan!), people get immunity each challenge, people get prizes, and only 1 lucky winner gets to be called the next America’s Top Model American Idol Food Truck Foodie Trucker Apprentice Top Designer. So yes, there’s pressure, and people losing their cool.

And that’s where Tim Gunn comes in.

What makes this show different is that there’s this impartial person who’s EVERYBODY’S BUDDY – he’s not a judge (although, with the ‘Tim Gunn Save’, he can veto one elimination per season now), he’s a mentor. He’ll walk into the work room and work the room, going from bench to bench, asking each designer how they’re doing, hearing out his/her design, and giving feedback, be it technical, aesthetic, or emotional.

He’ll give hugs AND he’ll give tough love. He’ll give his opinion AND he’ll tell you to show the judges who you really are. Be authentic? We need to hear more of that message! Signature phrase? Make it work! TIM GUNN FOR PRESIDENT!

And that’s what Tim Gunn does.

And that’s what a ScrumMaster does.

She gives hugs AND she gives tough love. She gives her opinion AND she tells you to show the Product Owner who you really are. Make it work!

(Oh boy… and now to apply this to ScrumOfOne…) And this is what I do.

I give myself hugs AND I give myself tough love. I give me my opinion AND I tell myself to show me who I really am. Make it work!

Yes, you’re right – that doesn’t translate as cleanly, and maybe it’s partially because the notion of coaching yourself is inherently paradoxical. Balancing what you want (“More!” says the Product Owner) and what you need (“Less!” says the ScrumMaster) is why there are two different people taking on these forces in a normal Scrum team. This echos the struggle of an artist: More! / the drive to keep working on it until it is perfect, versus Less! / the need to stop working on it and then share it with the world. So, yes, you’re right – it’s not easy.

And that’s why I forgive myself when I fall off what feels like a ScrumOfOne Wagon. Moving, getting married, settling into a new home, plowing through a couple of Ruby books, getting sick a couple of times, closing out the storage unit, all in a couple of months, means I’ve been way more focused on the ‘now’, and barely looking into the ‘next’ / short-term future.

So this is how I forgive myself for falling off the ScrumOfOne Wagon… by writing a blog post about forgiving myself. How self-serving. (Kinda like this whole blog. There. I said it.)

And this is where my inner Tim Gunn comes in.

I give myself a hug.

Thanks, me.

(I’m welcome. Now pull myself together and stop talking to myself. Make it work!)

Art of the Possible

In one of his Google Tech Talks, Jeff Sutherland, co-founder of Scrum, uses the term ‘Scrum-but’ to describe companies that incompletely implement the software development framework. When he consults, he’ll hear, “Yeah, we do Scrum, BUT…” and then some reason why they’re not a pure Scrum shop. In my head, they’re showing Sutherland around and at some point, flash-mob-style, folks congregate around the ping-pong table and sing it a la Annie:

It’s a Scrum-but life, for us,
It’s a Scrum-but life, for us,
Our velocity’s not – so – sweet,
But our process can’t – be – beat,
It’s a Scrum-but life!

And this is the reality of it. Here you are, introducing the new kid process on the block, leading the crew with a new philosophy as a ScrumMaster, or in ScrumOfOne land, at times competing with the existing processes or priorities of life. I like how Ken Schwaber, co-founder of Scrum, discusses it in his ‘Agile Project Management with Scrum‘ book:

…the ScrumMaster has to operate within the culture of the organization.

The ScrumMaster walks a fine line between the organization’s need to make changes as quickly as possible and its limited tolerance for change.

…sometimes these changes are culturally unacceptable and the ScrumMaster must acquiesce. Remember that Scrum is the art of the possible. A dead sheepdog is a useless sheepdog.

Back in ScrumOfOne land, the organization’s culture is… us. This can make it stressful, but it doesn’t have to be!

I used to hold my personal and formal 15-minute stand-up meeting at 5:31am. Past tense. My stories are not complex enough to be broken into tasks. I haven’t invested in any Sprint Burndown chart. I don’t have a formal demo for myself. I don’t always go through and clearly describe the acceptance criteria per story. I have tried each of these things, but none have stuck thus far.

So did I beat myself up for sucking at my own ScrumOfOne?

Yes.

I’d create stories to add more rigor to my personal development system, and then implement them. Slowly, through practice, I felt more and more in control. Not all processes would stick, though. And did I bet myself up for continuing to suck?

Yes.

At some point, I stopped feeling like a putz for seemingly setting myself up to fail. At some point, Schwaber’s words sank in with the deeper appreciation of that phrase: Art of the Possible. Via finding solutions that were good enough (better than perfect), and working with myself instead of against myself (tendencies, social pressures, bow tie affinity), I understood that this system is fully mine! I don’t have to be pure Scrummin’ if I am getting stuff done while promoting the principles of transparency, inspection, and adaptation.

So you start scrappy, but you’re getting stuff done, a la Jay-Z.