Spikes And Stories

Scrum tips and agile insights from a Silicon Valley agile coach

The Introverted Agile Coach

by 8 Comments

I have a confession to make.  I’m an introvert, and I feel this is at odds with my responsibilities as an agile coach.

Or at least I used to feel that way.  Over time, I’ve found more like me.  In fact, I’ve learned that it’s not as uncommon as I had thought.  Many educators, speakers, and other agile coaches are also introverts.  For me, this is how I often see this trait manifest:

[Read more…]

Scrum Master Tips to Help Your Teams Succeed

by 4 Comments

I previously wrote Tips To Be a Successful Scrum Master.  Over time, more Scrum Master tips have come to mind so today I’d like to extend my list of tips by ten.  Each of these tips are borne out of my mistakes or experiences, and I hope at least one of these tips is something you can take back to your team.  So let’s get started on these new Scrum Master tips.

  1. Never surprise the Product Owner. The Product Owner should be our partner so create a strong relationship with him or her.  After it’s created, reinforce it by ensuring s/he knows everything we know.  By talking to them before a major change or event, we avoid unnecessary resistance.
  2. Scrum is not scripture. It’s not enough to know the Scrum framework.  We should know why each element exists and what happens if we remove an artifact or ceremony.  Be intimately familiar with the nuance of the framework.  Question it.  Explore it.  The team will ask innumerable questions on this front, and it’s never acceptable to say “because ‘scrum’ says so.”
  3. Put yourself out of a job. I’m of the opinion that a Scrum Master should feel valued, not necessary.  Are team members—not you—willing to pull another out of a rabbit hole?  Do they—not you—remind others of a meeting agenda if things get off track?  If you take a week off, are you comfortable the team can perform just as well in your absence?  I hope so.

We should be teaching ourselves out of a job not so we can be fired but be promoted.

[Read more…]

Definitions: Epics, Stories, And Tasks

by 2 Comments

We spend a lot of our days talking about epics, stories, and tasks, and in many cases, we assume others understand these concepts as expertly as we do.  Sometimes they don’t, and today I intend to take Leonardo da Vinci’s advice:

Simplicity is the ultimate sophistication.

Below you’ll find a table that boils epics, stories, and tasks to their most primitive forms, and it comes at a risk.  Some may read this blog post and wish to prescribe these definitions on their teams.  They shouldn’t.  Others might argue details suggesting that one thing should be another. Today is for simplicity; details are for another day.  For example, I write below that tasks should be no more than 8 hours, but what I don’t write about is the nuance:

  • Tasks are for the team to find what works best for them.
  • Tasks that are less than eight hours allow for team members to touch and advance a task every day.
  • Such tasks also make impediments easier to spot when they’re not verbalized.
  • Some teams choose not to decompose stories into tasks.  That’s okay.

My point is that your mileage may vary, and as long as we clearly understand why we do what we do, then that’s what matters most.  So without further ado, here’s how I simply define epics, stories, and tasks.

As extra credit, feel free to also read about spikes and how they apply to agile teams.

[Read more…]

When Can a Scrum Master Say No

by 2 Comments

When can a Scrum Master say no to the team?  That’s a question I struggled with as a young Scrum Master.  On one hand, I was told that I have only influence—not authority—over the team, but on the other, I was told that I was the keeper of the process.  So what do I do when the team tells me the retrospective is a waste of time and suggests doing away with it?  If I could turn back to the clock, here’s what I’d tell my younger self.

When listening to a team, I ask myself a two questions:

  • Does an idea conflict with the intent of a ceremony? As Scrum Masters, we should not only understand the mechanisms of a ceremony.  We should also understand their intents, which I write about here.  When we understand the intent of each ceremony, we empower the team to tweak the mechanics to suit their needs.
  • Is the team trying to toss out an element of the scrum framework?  Examples of this include delaying testing until the next sprint, not delivering working software at the end of the sprint, or doing away with a ceremony altogether.  Use this video as a reminder of the simplicity of the scrum framework.

[Read more…]

%d bloggers like this: