Spikes And Stories

Scrum tips and agile insights from a Silicon Valley agile coach

A Data-Driven Approach To Team Evolution

by 16 Comments

It’s not often enough that I see teams experimenting.  Well, that’s not entirely true.  Most teams experiment by trying new techniques, by adjusting their process, or simply by trying something different. I’d call these anecdotal experiments, and they’re very valuable. However, it’s not these kinds of experiments that I want to talk about today.  I’m focused on quantifiable experiments.  Consider it a data-driven approach to analyzing team dynamics or individual behaviors.  For me, this was borne from my affinity for the burn down chart.  If used as intended, the burn down is simple, it’s useful, and it inspires a team to ask intelligent, focused questions.  If my experiments do the same, I’ve succeeded.

Before I begin, I have a confession.  I’ve rewritten this blog post several times now.  Each time, it gets away from me so I scrap what I wrote and begin again.  Why?  Simplicity.  I kept losing sight of it.  Because of this, I’ve adjusted my approach.  I intend to write this blog post in some rather broad strokes while my next will contain more context and examples of experiments I’ve run in my teams.

With my first broad stroke, let’s talk about some of the advantages of data-driven experiments:

[Read more…]

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…]

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…]

Tips To Be a Successful Scrum Master

by 30 Comments

If I could go back in time and give my younger scrum master self only 10 tips, it would be this:

  1. Questions over statements. Use questions as a tool to enforce process, make a point, or to gain understanding of another point of view.  It also makes for a less confrontational situation:
    1. Frank, instead of starting a new task, have you thought about helping Mary with that code review?
    2. Since our stand ups are only 15 minutes, should we talk about ways to get us all here on time?
  2. Progress should be defined by the amount of work finished, not the amount of work started. Task switching comes at a cost.  This cost is often overlooked, especially in a world where multi-tasking is the norm.   Teams often feel they’re most efficient when they have a large number of tasks open so they can toggle between them.  They’re mistaken.
  3. Knowledge creation over task completion. Even at the cost of efficiency, it’s better to spread knowledge throughout the team than to focus simply on completing all committed work. Encourage specialists to step outside their comfort zone and learn a skill from one of their team members.
  4. Ask stupid questions. If someone says something, and you don’t understand, ask.  I bet at least two other people in the room have the same question, but don’t want to feel like a dummy.
  5. Know your team. Can you name the spouse, hobbies, strengths, and weaknesses of each of your team members?  If so, great.  If not, learn, but only do so if you’re sincere in your effort to know more about your team members.
  6. Know your team’s dynamic. It’s not enough to know each team member.  Learn how their personalities mesh.  Who feels safe sharing their thoughts?  Who’s more contemplative?  What has occurred in the past to draw the entire team into a fruitful and honest discussion?
  7. The last 10% of any story is chock-full of unicorns and dodo birds. Never let a team convince you that something is 90% done.  It’s either all done or not done at all.
  8. Paint all things in terms of black or white. When your team uses terms like “may” or “might,” ask them to commit to something firm (even if it’s less than their previous “might”).  In a similar vein, ensure all action items have a clear and single owner.  Use questions to get them through the shades of gray.
  9. Good enough never is. Never let a team feel that they have nothing more to learn.  Never let a team become complacent.  Always find ways to gently knock them off balance in the spirt of keeping things fresh and interesting.
  10. It never gets easier. The job requires a great deal of patience.  Many days you’ll question if you’re really doing enough for your teams. That’s normal. You’re in a role where the value you provide a team is often intangible, yet always invaluable.

What would you tell your younger self?  I’d love to hear your tips for new scrum masters.

Update:  A number of you enjoyed these tips so much that I put together another ten in my blog post Scrum Master Tips To Help Your Teams Succeed.  I hope you check them out.

%d bloggers like this: