daily standup – Page 2

Agile Habits

Google “Aristotle quotes”. Here’s the first one I see:

“We are what we repeatedly do. Excellence, then, is not an act, but a habit.” – Aristotle

(Oooh. Starting with philosophy. Dorky. I like it.)

In his book “Atomic Habits“, James Clear builds off of this notion. Habits are those actions we take without trying – they’re automatic. The reason they’re automatic is we have found value in making them automatic – we either do them very frequently, or we have practiced them a lot. The benefit of automating them is so that we save brain energy to think through things that are novel, or things that matter, instead of things we do with a high enough frequency, like brush teeth before bed, or wash hands after coming back home, or wiping our sword on the grass before putting it away after the weekly field battle for the Hill of Arowyn with the neighbouring tribe.

(Oooh. An attempt at a Welsh word. Gaelic. I like it.)

You’re Making Something Cool

You’re making something cool.

Congrats – now let’s make some assumptions.

You’re a crew of lads and lasses who code for a relatively small start-up. You’re recently out of college, so you haven’t worked in a larger organization. This means you have not had to code under the auspices of a large process – quite the opposite: because there are so few of you, y’all are frontierfolk, coding in the wild wild west, ~~gangnam-style~~ garage-style.

You’re successful. Sales are up. So are profits. You’re making something cool, and you want to make more cool things, so you grow by hiring more coders. Your one team has grown to a handful. Because there are now more of you than the good ol’ garage days, general complexity has increased, so the founders of your start-up want to reduce some of the chaos by adding a little process.

What?!?!!!111!1one1!1oneuno!

You don’t like this.

We’ve been working fine without process. Now you want us to follow what? Scrum? What is this, rugby? Sales are up year over year. So are profits. What’s the problem? Don’t tell me what I can’t do!

You don’t like this one bit.

When folks in the software industry move from a big, rigid process to a small, Agile process, there are obviously increased freedoms. Heck, when folks talk about Scrum, they usually end up comparing it to the (more burdensome) status quo for software development. But you’ve been blessed.

Not blessed in a sense that you had an enviable upbringing – the software equivalent of parkour camp and paintballing and go kart racing and fueling all those adventures with home-made ice cream.

More blessed in a sense that you didn’t have a wretched upbringing – the software equivalent of… the beginning of most Roald Dahl stories.

Why do I have to use Scrum?

I was asked this not too long ago. And thusly I commenced my reply…

Hear ye, hear ye, oh ye crew-of-lads-and-lasses-who-code-for-a-relatively-small-start-up. I come bearing procedural gifts of enhanced freedoms and daily salvation.

…this was all I had in my Ye Olde Towne Crier pocket scroll. The ‘enhanced freedoms and daily salvation’ bit comes off as hyperbole, but now that my Sprints are 1 week instead of 2, I plan for less and actually get stuff accomplished, progress towards my life goals is measureable and tangible, and I feel I have a better handle on my path each day, where I’m better able to enjoy the journey, in the mirror I see a relaxed and happier face. And I’m a believer.

I told the crew that, off the bat, nobody has to do anything. There’s gotta be buy-in from the team, and that’s because the benefits and costs are explained and understood. Now, the costs are a lot easier to see – the regular meetings, breaking down tasks to a smaller-than-comfortable level, the brighter spotlight – and if this is all you see, and all you experience, then of course it’s gonna suck.

Those regular meetings are… constant, sure, but they’re tiny – 15 minutes a day – and they’re meant to be the only meetings, so no distractions from outside the team. Those smaller tasks are… smaller, sure, and that’s so you get feedback more often and you know the stuff you’re working on is going in the right direction – you’re not wasting your time. The spotlight is… brighter, sure, and that’s so stuff stopping or slowing you down can be found and addressed sooner – it’s not to micro-manage.

And that’s a decent point – it can seem micro-manage-y, but only if there isn’t an accompanying attitude of self-management.

Along with the processes that are so well advertised should be an ability for folks outside the team to truely trust the team to do what they do best. This is the part of Scrum that isn’t easy, but it’s worth it. After all…

You’re making something cool.

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:

What did I do for the team yesterday?
What will I do for the team today?
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.