Category: daily standup

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?

Don’t Have A Fine Day

Don’t do it. Just don’t. Whatever it takes.

If somebody asks you, “Greetings, citizen! How fares your day?” and you say, “Fine!” …then… think about that.

Fine? Do you really want a fine day? Just… fine? It’s your day, so if you could chose an adjective to be associated with it, would you really want it to be ‘fine’? Come now, fair citizen, surely you wish this not.

This line of thinking comes from ‘Tribes’ by Seth Godin, where he says that if you are having a fine day, then you’re not leading, because leaders are the heretics, out causing trouble, passionately speaking out against the status quo and creating change because the marketplace demands it. To be a leader, I can see this definitely applying.

To be a living human being, I can’t see why this shouldn’t apply.

If you’re having a fine day, then it is not an exciting day. Could you have an exciting day and honestly say it was just, well, y’know, fine? This echoes a definition of happiness from ‘The 4-Hour Workweek’ by Tim Ferriss, where he equates happiness to excitement. If you are doing things that excite you (excites you to your core), then you are living life happily.

Let’s take this a step further and rock the boat a little: If you’re having a fine day, then you are not happy.

Ending on a lighter note, I challenge you to not have a fine day. Ever. Fo’ realz. Don’t float along the currents of everybody else’s life. Wake up every morning and tell yourself to make waves. I make this a part of my morning Scrum.

Stay in trouble, citizen.