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.

Personal Overhead

This is the post where I share my ScrumOfOne existential doubts.

Do I doubt this whole “Using Scrum for Personal Development” idea? Yes I do, yet I think it’s somewhat healthy. It is very encouraging that Scrum encourages critical thinking by building in a time to be retrospective and thus adapt: choose to amend the set of processes I’m imposing upon myself, which includes killing off all that overhead altogether! There is a question from ‘The 4-Hour Workweek’ by Timothy Ferriss that fits this all too well:

Am I being productive or just active?

Rephrase:

Am I inventing things to do to avoid the important?”

I’ll admit that I feel this ScrumOfOne idea is kinda my baby; I really like the idea and have found it key to managing how I purposefully get things done. So that I can analyze if these ‘Scrummy’ practices are a good return on investment, I have turned to these existential questions from ‘Rework’ by Jason Fried & David Heinemeier Hansson:

Why are you doing this?
Is this actually useful?
Will this change behavior?
What could you be doing instead?
What problem are you solving?
Are you adding value?
Is there an easier way?
Is it really worth it?

Man, those questions are straight-up down-right (left hook?) harsh! And I like ’em. A lot. They bleed with the spirit of Getting Real. I had huge plans: waking up at 5:31am to step through the three questions (I even convinced a buddy to be a part of this pre-dawn Scrum), stepping through and documenting a formal Retrospective, writing a PERL script to manage a text-based Product Backlog, reading weekly a set of quotes & phrases & book notes I’ve collected over the years as my personal set of Psalms. These weren’t just plans… I actually did them for a while!

So do I still do all this? Hellz no! These ceremonies were just not sustainable for the long term. My commute schedule changed, so 5:31am turned into an ungodly hour to be awake, although I still have the 531am.com domain name. My Retrospective currently covers what happened over the past two weeks, how process adaptations fared, and what process tweaks to adopt. My Product Backlog is a Google Doc with the Sprint Backlog at the very top – a text editor in the cloud suffices. My hours-long re-centering read now happens monthly. I pared down the personal overhead to manageable levels based on fruitful returns.

Sure, ScrumOfOne takes discipline, which connotes a struggle, though what I’ve found as I’ve been massaging this system of processes is you can change the nature of the motivation when you see the fruits of your labor. The morning stand-up has turned into 15 minutes of alignment, mental prep, and a generally feel-good start to my day. It’s a trigger to personal finance documenting, reading a few fruity-sounding affirmations, and walking into the day with a purpose. When I do this, I literally walk differently. (I do!) This whole Scrum business is just that transforming.

Thus the system continues, yet only because it started with a habit: a small step: the seed of a fruit I hoped would work out. Upon processes that proved their own worth, I added, modified, and removed (…mostly removed) as I evolved this personal overhead, like trimming a fruit tree.

Alright. Seriously. What’s up with all the fruit in this post? I think I’ll grab a pear…

Two Metrics At Any Time

The last post talked about measuring life and how ScrumOfOne can do this to manage life, in a sense. The morning Scrum allows for a granularity of a day, but what about a measure with higher resolution? And would you even want one?

In ‘The $100 Startup’ by Chris Guillebeau, he proposes that in the monitoring of your business, select one or two metrics and be aware of them at any time, such that you can determine ’em in very short order. Examples include sales, cash flow, and incoming leads. To balance out the monitoring overhead, any other metrics would be subject to a biweekly or monthly review.

From a Scrum perspective, the burndown chart could be a visual representation of one of these metrics: how many hours left to complete all tasks associated with Sprint stories. For myself, I don’t have stories that I need to break into tasks quite yet… nor do I have a means to track this at a low enough overhead that I care to use.

The metric in this category that I do follow is how close to my Sprintly (financial) budget I am.

What would yours be?