Hello – Is It Me I’m Looking For?

I can see it in my eyes.
I can see it in my smile.
I’m all I’ve ever wanted.
And –

…if we check out the System page of this blog, we see how this whole ScrumOfOne set of practices I’ve forged actually increases my Inner Peace.

Man does that sound awesome – I want me some of that existential goodness.

Sometime before the home settling, the wedding, the move, the move prep, and the wedding prep, I stopped being fully engaged in applying Scrum principles to my personal development. I had been working off of a Scrum-Lite process where, yes, I had a backlog, but it was to keep track of the things to which I was largely reacting. While the days were focused on mostly logistical issues, and rightfully so, what was missing was personal growth, and the accompanying Inner Peace.

Now that things have calmed down, with the state of the home being that folks have been able to stay over without being warned to mind the bear traps duffle bags and to watch out for that tree box, I’ve returned to putting things in a number of personal backlogs, prioritizing them, and siphoning off a few into the current sprint. And just the process of doing all that has felt grrrrreat! The relief has come less from knowing where I am going and more that I am not missing anything. I can’t get all the things done now, but they’re not forgotten, and the most important stuff is getting addressed. Very Scrum. What’s that tingling in my toes? Oh yeah. Inner Peace.

So I’m back on the bandwagon, and man do I not want to fall off and lose my growing Inner Peace… or… get dysentery.

Want more transparency? Fine. I thought it would be enough to tell y’all that I’m wicked pumped to be back in the game, but you’re egging me one… I’ll publish my velocity and the Kaizen story so y’all can learn along with me. There. You’re welcome.

The more important bits of Kaizen will fall into an improved System page – I’ll update that section to reflect what has been practical and repeatable.

First piece of Kaizen (for Sprint 141, which is the number of paychecks I’ve received, with a biweekly schedule that conveniently aligns with the sprintly schedule): Actually read the Sprint Backlog each morning. It’s simple, but this is the piece of adaptation that is independent, negotiable, valuable, ‘estimatable’ (such a clumsy word), specific, and testable that gets Scrummin’ back into my daily routine. And Inner Peace. Let’s not forget that.

New Perspective On The Daily Stand Up

That morning meeting, where you stand-up for 15 minutes, and folks go around the room answering the 3 questions (and for a ScrumOfOne, I answer them for myself without feeling like I have multiple personality disorder), you know, the Scrum… how are you liking it?

Does it tend to feel like a status meeting?

The Scrum is meant to… have a different feel. Yes, when the Scrum founders whittled down product development process into a few core meetings, the Scrum was one of them, and it was meant to do a number of things:

  • intensify team focus
  • collaborate & clarify
  • crush impediments
  • motivate team spirit

We get to this different flavor of morning get-together via asking a modified version of those 3 questions:

  1. What did I do for the team yesterday?
  2. What will I do for the team today?
  3. Is there anything blocking me from maximizing team velocity toward the sprint goal?

Team-focused. Go team. Sounds corny, sure, but it does do a great job of removing the focus from ‘me’ to ‘us’ and how fast ‘we’ are moving, ’cause it’s not the individual that wins in Scrum: it’s the group. I think it’s a clever spin.

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.

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.

From The Front Lines: Task Ownership

This is a success story since becoming a tactical ScrumMaster at work. It’s nothing that directly relates to personal growth, yet the following practice can aid in not taking on too much during your Sprint, just as it is helping my team members work at a sustainable pace.

In theory, Agile teams are made up of generalists: coders, testers, requirements folks, release engineers, all these people can do the jobs of the others; they are, well, agile. This way, anybody can do any task associated with any story in the Sprint backlog. In Scrum, this is encouraged; assign your name to a task that you are doing, or about to do. Nobody assigns your name to a task without your permission, since this violates the principle of Scrum teams being self-managed.

In practice, folks aren’t as agile. For example, I test medical devices. (To younger folks, I say something along the lines of, “I break expensive equipment, and they give me money to do it.” To complete strangers at my favorite cafe, I lie.) You want me coding? Fine, but I’m rusty; it’s inefficient and will drag down team velocity unnecessarily. Thus, per story, coding tasks will most likely be done by one of the coders, testing tasks will most likely be done by one of the testers, etc.

Introductory passages out of the way, here was the pain point. Our team is doing better than expected regarding velocity, in part due to the high level of commitment to the team each member has, as per a recent survey, and as per my own Spidey-senses. This commitment was so high, that sometimes, a team member would dive into implementing a story, realize it was hairier than the number of Story-points reflected, and (not-so-) quietly trudge uphill to get it done in time for testers to play with it before the Sprint end. This meant longer hours, which is not a sustainable pace – bucking against another Scrum principle.

Each morning, we do that 15-minute stand-up meeting, taking turns saying what we did yesterday, what we plan on doing today, and if there is anything stopping us or slowing us down. Ah, transparency, right? How much more see-through could we get? Well, this meeting did not cover a simple comparison: remaining hours of tasks assigned to me vs. remaining hours in the Sprint.

I recommended that we tweak a Scrum principle of self-managed teams: Assign your name to every task you think you will most likely do. The benefits:

  • The tool we use for Scrumming (tracking tasks, stories, backlogs, etc.) shows a simple graph of remaining hours per person, so we can all use that to ensure nobody is overloaded from a pure numbers perspective.
  • Assigning a task to yourself is not an etching in stone, so we can all see who might need help completing their tasks: you can hand off your tasks.
  • We can all see who is wrapping up their tasks and thus has bandwidth to help somebody out in completing a story.
  • With testing tasks usually done towards the end of the sprint, we can all see roughly by when the coding tasks for a story should be done, thus acknowledging inter-dependencies.

I asked that we all do this, not so that management could see what everybody was up to, but so that we had opportunities to help each other out as we got stuff done, at a sustainable pace. This added level of transparency was adopted by the team and I think it’s been helpful. We’ll see at the next Retrospective.

How does this help you with your ScrumOfOne? If you have hours associated with stories in your Sprint backlog, just total them and compare that with the number of hours left in your Sprint that you think you can dedicated to stories.

Be realistic: do at sustainable pace.