analysis – Page 14

Kaizen Story

As I’ve worked with Scrum in a context that is not software development, I’ve come to define Scrum thus:

Scrum is a framework for getting stuff done that embraces change, while promoting transparency, inspection, and adaptation.

You get transparency from the Daily Stand-Up meeting (this is called the Scrum, too), and both the Sprint Burndown Chart and the Release Burndown Chart. Everybody starts the day on the same page, blockers are identified, and outside parties are privy to the progress during the Sprint and towards a release-worthy product; these are formats for easy sharing and digesting of Sprint-related information.

From all the data being laid out from the Burndown Charts, we can get inspection. The Sprint-end demonstration (part of the Review) also allows for a frequent check on the state of the software and acceptance of the stories done during the Sprint: inspection of the work. Inspection of the process is done during the Retrospective.

And the Retrospective is THE place where adaptation is determined. After inspecting the process, using methods I’ve mentioned in the previous two posts, we ideally get a somewhat prioritized list of stuff we either want to keep, stop, or start doing: a backlog of adaptation options.

Now, we pat ourselves on the back, go straight into Sprint Planning, and restart the Sprintly cycle.

And fail.

I mean, if we just come up with a list of ways we can get better, but don’t really do anything about it, then the Retrospective was a jolly ol’ waste of time. Does this sound like post-mortem meetings you’ve been a part of? Were they called ‘Lessons Learned’ meetings? See, I passionately dislike that term, ‘Lessons Learned’. You cannot say you’ve properly learned your lesson unless you repeat a situation and then exhibit ‘better’ behaviour, thus proving that you have indeed learned your lesson. Until then, you’re just talking about ‘how it all went’, an ‘Issues Encountered’ meeting, sharing what you’d do better next time.

The Retrospective is different.

At the top of the backlog of adaptation options, there must be an immediately actionable process improvement that can be implemented. How to ensure you do this? Make it a story for the upcoming Sprint: the Kaizen Story. Kaizen? Yeah, it’s Japanese:

Kaizen is a Japanese business philosophy of continuous improvement of working practices, personal efficiency, etc. Kaizen literally means ‘improvement’.

So, via Kaizen, we adapt. Via the Kaizen Story, a properly formed Sprint backlog item with points and acceptance criteria… and is independent, negotiable, valuable, ‘estimatable’, sized to fit, and testable… and is otherwise meeting a Definition of Ready for stories, the team is constantly working on improving the Scrum process, specifically using a measure uncovered and set by the team itself. (What’s that? At the back of the room… is that… is that the ‘self-management’ flag being waved? Why yes. Yes it is.)

I don’t have a clever way to end this post besides expressing how I think this idea is just so damn cool: Scrum becomes a framework for both getting stuff done and for improving how stuff gets done.

Genius.

Hot Or Not, Fist Or Five

If you’re in Boston, you know it’s, like, 105 degrees. Or 85 degrees, dipping into the 90’s, but we adamantly complain about this weather like it’s suddenly our jobs, so it might as well be 105.

(Attempt at a smooth transition in 3… 2…)

Moving to what we can control, and might equally have a few opinions about, Retrospectives are meant to, yes, get people thinking back and talking about the Sprint. You might read that at the end of a Retrospective, there is a meta-Retrospective: the team talks quickly about how that meeting went. One way to do this is via the ‘fist or five’ technique.

At the same time, so have some fun with it by counting down from 3, everybody sticks up a hand with the number of fingers representing how much they liked the meeting. Five fingers mean they really liked the meeting, got a lot out of it, thought it was a solid use of time, and they’re so happy, they want to make love to everybody, like Roberto Benigni.

No fingers is a fist, and this means they really did not like the meeting, are now dumber for it, thought it was a total waste of time, and they’re so unhappy, they want to conduct atrocities of great evil, like not commenting code.

I’ve started applying this neat little technique to not just the Retrospective, but to each artifact and ceremony of the past Sprint. Do this at the beginning of the Retrospective by listing Stand-up Meeting, Sprint Planning Meeting, Sprint Backlog, Product Backlog, etc., and getting the team to vote on each of these, tallying up the number of 0s through 5s for each Scrummy thing.

Et voila: the team opines on pieces of the process as a primer to providing pithy ponderings on the previous passage of purposeful participation.

Tying this back to the last blog post, we now have more to consider for how to adapt in the next Sprint.

Squeezing Twice As Much Out Of Retrospectives

Looking to adapt via Scrum? That’s what the Retrospective is for, and there are a number of ways to conduct this meeting. I’m a particular fan of one way that gets the team to share twice as much input.

We start by everybody getting a few of those sticky notes. Watch ’em comment over the color of the sticky notes – it’s cute. Personally, I go for the neon pink – nothing wrong with standing out.

On a whiteboard, divide it up into three sections: Keep, Start, Stop.

ROUND 1: GET IDEAS

Now we get the team to sit and think. One idea per sticky, they each think back through the Sprint and write down ideas or events, one per sticky, that they would like to keep doing, start doing, or stop doing. Watch how a few ’em will have lots to say, sometimes asking for more stickies.

Alright. If folks haven’t been walking up to the board to put ’em in the appropriate area already, let’s do so. Watch ’em say things like, “Hey, I said the same thing,” as they place their stickies next to similar ones.

Now we walk through each sticky. Retrospectives are the one meeting in Scrum where the most discussion takes place, so things can get a little emotional, and watch a few of ’em change their vocabulary in describing events so as to not directly implicate anybody. This is also where the kudos come out. Encourage verbal back-patting.

During the discussion, group the stickies, maybe even draw a circle around them on the board to clarify. Get the team to agree that the stickies have been appropriately grouped. Excellent. Give yourself a back-pat. Surreptitiously.

ROUND 2: GET VOTES

We continue by everybody getting a few of those sticky dots. Watch ‘em comment over the color of the sticky dots – it’s cute. Personally, I go for the taupe – those are unfortunately rare.

Now we get the team to stand and deliver …a total of 5 sticky dots. One vote per dot, they get to distribute them however they like across the groups of sticky notes, voting for what they would like to keep doing, start doing, or stop doing. Watch how a few ’em will deliberate aloud, ~~undottedly~~ undoubtedly influencing others.

Now we walk through the dot clusters, tallying up the votes per group of sticky notes. Step back. State the obvious, like a sports reporter, “Well folks, looks like this group over here got the most votes, with this other group here in second place.” Things won’t exactly get emotional, but watch a few of ’em nod their heads, with fewer still pumping their fists in the air.

Et voila: the team sources ideas, the team votes on the ideas: the crew is surveyed twice, going deeper into the heart of the issues that matter.

Regardless of the vote distribution, the most voted note groups will be the focus of how the team will want to adapt for future sprints. Excellent. Give yourself another back-pat. This time, don’t hide it.

Between You And Showing Up

Ah, the motivation to get started on something. Sometimes, that is the hardest part of the activity. The example for me where this applies in spades is the morning run.

I love running. Sure, you get tired and sweaty and just want to walk at times and something or another might start hurting, but all that… I have no problem with; all that is fun. AND… I feel great afterwards: more than the endorphins, it’s feeling fit – maybe they’re the same thing. I prepend that to a workday, and I walk into the office feeling like a bad-ass, having proactively done something to better myself, feeling alive.

If I could just open my eyes and find myself running (sleep-running?), I’d keep running. While it’s effort, it’s ironically not the hardest. So what’s been coming between me and giving myself a radiantly awesome start to every day after turning off the alarm clock?

Not rolling back into bed.
Getting my feet to touch the floor.
Getting my butt off the bed.
Not checking Facebook, or email, or the news, on the laptop.
Getting running clothes on. Then shoes.

Hmm. It starts with feet and ends with getting them dressed: out of bed and into shoes.

Maybe… just maybe… if I put my running shoes next to my bed at night, I can slip into them in the morning and jump-start the whole process (’cause I’m not gonna roll back into bed with my shoes on).

MAYBE… just maybe… if I put the alarm clock ON the shoes next to my bed at night, I’ll be holding my shoes, facilitating the shoe-to-foot process.

Wow, this post was going to be about how showing up is the hardest part (the problem/challenge/opportunity), and just by going through that little exercise of asking myself, “What is coming between me and…” while writing it out in detail do I have something I can look over and subsequently fall into coming up with a potential solution, from the point of view of more easily showing up. I’m not sure if it’ll work, but at least I have a plan I can try out.

What is something you want to do or be? Ask yourself, “What is coming between me and…” this thing. Write it out. Each blocker. Each annoying or silly or serious blocker between you and this thing you’re after. Now, look over this list.

What can you do to more easily just… show up?

On Point…s

You have something you want to do. You’re doing it for a reason (it has value, or benefit) and it doesn’t come free (it has cost, like time or money or focus). Generic enough of a start for a blog post? Good. Let’s talk Scrum.

You have a story. It has a benefit (business value) and a cost (effort). The backlog is a list of things to be done (stories), where this list is ordered (prioritized) by business value (fine, personal value since we’re in ScrumOfOne-land, or just value), with the highest / most important at the top. Each story has points associated with it, representing effort.

Business value is represented by backlog priority. Effort is represented by story points.

This is simple. This is Scrum101. And this is something I didn’t fully get until the Product Owner training last week. From this simple and clear concept, I am amending how I’ve been doing my ScrumOfOne.

More important stories are not ‘worth’ more points. How much a story is ‘worth’ is represented by its position in the backlog (be it the Sprint backlog or the Product backlog) and by this qualifier ONLY. Yes, the more valuable a story is, the more effort it might be, but not necessarily. For a recent example, I look at how I handled stories related to getting the Product Owner training.

I started with an ‘epic’ (just a large story): Become a Certified Scrum Product Owner. Then I broke it down to investigating the training options & timing, signing up & paying for it, getting reimbursement paperwork underway at work, and attending the classes. The epic, though important and thus close to the top of the backlog, is too large to fit into a Sprint, so it was broken down. Of those stories, ‘attending the classes’ was relatively the easiest (least effort): just show up! Of those stories, ‘investigating the training options & timing’ was relatively the hardest (most effort): spend time.

These stories, in retrospect, in and of themselves do not require a lot of effort, so they should not get a lot of points. Yes, working towards another Scrum-related certification helps me in better crafting this ScrumOfOne idea and improves my marketability, but this does not mean it gets lots of points. Instead, it gets a better/higher position in the backlog.

In the business world, coming up with a value per story means find the dollar value. In the world of personal development, coming up with a value per story is… harder. In both cases, this is one of the jobs of the Product Owner: prioritize the backlog, i.e., identify the value (thus, relative value) of each story.

With my example above, I would say this set of stories had high value and low effort. One would think these types of stories would be ones to do first – prefer to implement stories with the highest benefit to cost ratio. Or I could just look at the title of slide #52 of the slide deck from last week’s training:

Prioritization of Business Value / Effort Can Cut Cost and Time to Market by 50%

Filtering out the MBA-speak, this might look like:

Prefer to do the coolest stuff that’s not that hard to pull off.

And this starts with getting the idea behind ‘points’ straight.