Category Archives: scrummaster

My Interview And The Squiggle

In streamed a few strangers, trying to hide their smiles from each other and myself. They just came from the kitchenette, having colluded on how they would play out the next hour. Of course, I didn’t know this at the time – it was my interview.

If you are a software engineer, and you want a job coding, then it’s fair that your prospective employer asks you to code as part of the interview. So if you are a Scrum Master or Agile Coach, and you want a job … doing that stuff, then it’s fair that your prospective employer asks you to do Agile Coachy stuff as part of the interview.

And thus, we began role-playing a mock Retrospective, a best practice which follows from the 12th Principle of Agile Software:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I first asked this pretend team to step through the last two pretend weeks, collecting just the pretend facts, leaving out any pretend feelings, and having this written up and pretend physically displayed. This is a way to level set.

Then I went to the whiteboard and wrote “KEEP” in the top-left corner, “START” at bottom-left, and “STOP” at bottom-right. The exercise here is to ask the team to top-right corner think back through the two weeks, like we had just top-right corner done, and write down, one per sticky note, things top-right corner that we would like to keep doing, start doing, and top-right corner stop doing. Afterwards, we’d categorize them, discuss top-right corner them, determine which few things should be actionable, establish respective next steps Kaizen, then run a quick Retrospective on the Retrospective. This top-right corner has worked many a time before, producing quick wins with minimal pushback.

That’s when I top-right corner noticed the top-right corner. It was bare, and it made me uncomfortable. So I did what anyone in an interview situation would do: make stuff up. I drew a squiggle and said that I would later explain what that squiggle was for, giving myself time to figure out what that squiggle was for.

That’s when I top-right squiggle stepped the team through the exercise, and how we would top-right squiggle fill out the rest of the hour. When I top-right squiggle got to the top-right squiggle, I did what anyone in an interview situation would do: stay whatever was at the top of my head. I explained that the squiggle was a category for things you wanted to share that did not fit into the other categories.

Simple enough. Rub’ al Khali averted. The team drew pictures and put them there. Then they hired me. Now, when I run this flavour of Retrospective, the squiggle is used and loved.

INTERVIEW-RELATED POST-SCRIPT:

Before my first day had passed, I was asked to take part in a mock retrospective. I had a few minutes’ notice. Soon, I streamed in with a few strangers, trying to hide our smiles from each other. We had just come from the kitchenette, having colluded on how we would play out the next hour. Of course, I knew this – it wasn’t my interview.

SQUIGGLE-RELATED POST-SCRIPT:

Before my first month had passed, I was asked to run the Retrospective for a hackathon. I had a few hours’ notice. Soon, there milled scores of buddies, sharing beers with each other. We had just voted on our favourite projects in the cafeteria, having cheerfully coded over the past few days. Of course, I used the squiggle – it was from my interview.

Squiggle keyword density: exactly 2%.

The Ends Justify The Genes

Oh, that’s right, I have a blog. Maybe I’ll post something.

THE END

There. It’s done. We goooood. Hasta la pasta, people. Zip up your knapsacks, knickknacks, and fanny packs. Leave the paddy whacks. (Hit the road, Jack.)

I created this blog so that I could document the journey of applying Scrum to personal development. I applied Scrum to personal development because I didn’t have a team of people such that I could apply Scrum to software development. I didn’t have a team of guinea pigs people because I had just received my ScrumMaster certification, and was a n00b looking for experience. To that end, this blog documented how, as a Biomedical Engineer testing bedside monitoring systems, I scrappliy found a way to practice being a ScrumMaster until I was employed as one. Of course, for the past 6 months, I was happily neck-deep as a ScrumMaster for 3 teams, which means this blog has reached its end, although not the only end.

AN END

(It was worth a crack.)

I applied Scrum to personal development also because… it helped… and is helping, both tactically and strategically. It is a way of life that I am still refining, and ain’t that the Western way to be: to want to be better.

intEND

Juxtapose this with a more Eastern approach, which is to give in & embrace to your inner way of being.

surrENDer

The blog thus continues, focusing on exploring both these philosophical …ends… while living through Scrum.

appEND

(Cut me some slack.)

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.