Introducing a Frontlog: Experiments in Process

Here’s an SAT-style analogy for ya, partially because I like wordplay, partially because I value effort over outcome, partially because I like Simon Sinek, and partially because I dislike New Year’s Resolutions.

Backlog : Product Experiments (the what) ::
Frontlog : Process Experiments (the how) ::
Forelog : Vision Experiments (the why)

This isn’t the best analogy, since ‘the how’ per Sinek’s Golden Circle is more akin to ‘principles’, but this’ll work well enough. Continue reading Introducing a Frontlog: Experiments in Process

How to Measure a Scrum Master: Effort as Meta-Metric

CONGRATS! You have Agile metrics that are ‘good’, or even improving: cycle time, code coverage, heck, even Sprint velocity. Now, how do you know if the Scrum Master had a part in that ‘success’? YOU DON’T. These metrics track team performance, not Scrum Master performance, thus I’m proposing “new process experiments over time” as the meta-metric uniquely aligned with the Scrum Master role, which can be a leading indicator for the other metrics. Continue reading How to Measure a Scrum Master: Effort as Meta-Metric

How to Measure Agile Coaching

Carrying on from the “value is sustained change in behaviour” opinion I shared previously, allow me to humbly submit my idea (a strong opinion, loosely held) for how to measure how we are doing as Agile Coaches.

Agile Coaches (plural!) are usually brought on because some company (BIG!!) wants to go through an Agile Transformation (ZOINKS!!!). The word “transformation” means, to me, a change in state, thus this company has made a determination:

change to a better state… an “Agile” one, whatever the heck that means.

Continue reading How to Measure Agile Coaching

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.)