Spikes And Stories

Scrum tips and agile insights from a Silicon Valley agile coach

How Military Tactics Made Me a Better Scrum Master

by 14 Comments

Influence.

It’s a powerful tool, and it’s a point of honor that a scrum master has no control, only influence, within a team.  I prefer it that way, and I hope you do too.  I recently reflected on how I conceptualize influence, and I realize that I operate in one of three contexts.  Before I share those contexts, a caveat.  Before my life as a scrum master, I was a Marine.  I served as an intelligence operative and martial arts instructor for 10 of the most formative and adventurous years of my life.  Even now, I still find myself using military language to explain my thoughts.  In my opinion, it makes for a more vivid metaphor.

Frontal assault.  When you know you won’t face much resistance, lay out your idea, explain what you’re looking to do, gain buy in, and execute.  No subtlety is involved, and it’s usually the quickest method to implement an idea.  However, use caution.  Never let bias for your idea convince you that others will love it.  If you conduct a frontal assault and find support is lacking, the losses can be substantial.

Rules of engagement:

[Read more…]

Agile Mindset Over Scrum Mechanics

by 14 Comments

There’s a funny thing with us humans.  Sometimes we get so occupied with the “what” that we overlook the “why.”  Take the stand up.  Tell us what you did yesterday, doing today, and what obstacles are in the way.  But WHY are you there?  This is the difference between understanding the mechanics of scrum and embodying an agile mindset. So here’s my why’s. Yours may vary.

Sprint Planning

This is our last responsible moment.  We’ve put off making a decision as long as possible about what we should do next, and now it’s time to decide.  It’s the entry point for work into our sprint backlog and the opportunity for the team to predict how much work can be completed by sprint end.  We should walk out of this conversation with a vision of what we’re doing over the course of the sprint and a set of goals that unifies us as a team.

It embodies this agile principle: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

[Read more…]

About To Disrupt Your Sprint? Think Again.

by 6 Comments

In my last blog post, I wrote about why it is important to keep the sprint backlog static after leaving sprint planning.  Unfortunately, much of my previous blog involved a great deal of arm waving (or possibly flailing) as I hoped to highlight the problem of disrupting your sprint. What it didn’t offer up was concrete ways each of us can contribute to the solution, and that’s why I’m writing today. I’ve split this blog into sections in an effort to talk to each of an organizations’ roles separately.  I encourage you to read each section, and I hope you take the time to read your part in detail.  Additionally, in the “For Team Members” section, you’ll see a workflow that will take team members through the questions they should ask before pulling new work into the sprint. Although this workflow is specific to my own company, once modified, it could add value to yours.

Decision tree for pulling in sprint work

For Team Members

It should be your last resort to ask for more work to be added to the sprint.  Unfortunately, it’s often your first course of action when you’re idle. Inefficiency has its place on a team, if done smartly, so don’t fear it. Before you ask the Scrum Master or Product Owner to add another story, think through the following:

  1. Teams goals over individual tasks. Albeit inefficient, where can you help another team member complete his/her task? Pair up and work through it together.
  2. Finishing tasks over opening another. “Everything stinks till it’s finished.” -Dr. Seuss. This is especially true in software development. Be inefficient to get that last 10% done in a task before you move on to the next.
  3. Cross-functional teams over silos. Everybody has an area they’re best at, but where can you grow? Be inefficient for the sake of learning a new skill and potentially removing a future bottleneck. Take on a task outside your skill set and ask for the team’s help to learn something new.

Again, I can’t emphasize this enough. Before you ask for something to be added to the sprint, you should spend a good deal of energy into trying to help the team figure out how it can meet its current goals.

[Read more…]

The Importance Of Sprint Commitment

by 10 Comments

Scrum is like my mother-in-law; it points out all my faults. Ken Schwaber, one of the master minds behind scrum, is credited with that quote, and there’s a lot of truth to it. Scrum is an exposure model; it’s intended to highlight weaknesses in an organization and its processes. It’s then up to the organization and its people to find solutions to those problems. Unfortunately, many organization solve these problems by removing the parts of the scrum framework that cause the pain.

It seems like a silly way to solve the problem, doesn’t it? When a stranger comes to my house, I have a cat who runs to the bedroom and hides under the comforter. She feels safe because she thinks if I can’t see the stranger, the stranger can’t see me. Sorry, stupid, we can see the lump in the bed.  You’re not fooling anyone.  So what part of the framework do I see organizations tossing out most often?

Commitment.*

When the team leaves sprint planning, they should have in front of them everything they’ll be accomplishing over the course of the sprint. That commitment is immutable. It should not change. Work should not be added, removed, or even exchanged for other work. Most importantly, this commitment should be made by the team without abetment from individuals outside of the team, and it certainly shouldn’t be dictated to a team by the product owner.

Of course, I write this with confidence but also some measure of skepticism. I recognize the realities of the work we do, and I recognize that sometimes things come up that cannot be put off. My argument is that we’re too quick to loosen up that commitment, and my heart burn is this:

When everything is the exception, why have the rule?

That’s a rhetorical question, but I’ll tackle it anyway. Why have the rule? What’s the intent behind requiring that the commitment remain unchanged between sprint planning and the demo? I’ll give you six reasons:

[Read more…]

%d bloggers like this: