“I don’t have time for that!” O RLY?

In one retrospective a colleague rebuffed a proposed action item with: “I don’t have time for that!”

Wrong. We all have precisely the same amount of time.

What he really was saying is that the issue was not important enough to him to make time. Which is fine. Time is often a scarce resource and having your priorities straight lets you spend time on the really important things. Just be aware that it’s a choice you’re making and not some flying-spaghetti-monster-given outside factor.

If we want something we make time. If we don’t, we don’t.

Side note: There’s a somewhat related piece over at Scrumphony’s blog on options we’re not always aware of.

Scrum Master Reading List – My Top 5

There is a mountain of agile books out there, all waiting to be read. On the one hand that’s exciting and something to look forward to. On the other hand that can be overwhelming and discouraging.

The following is a demonstration of utmost self-restraint on my part: The 5 or less books that I recommend to you, if you’re new to Scrum and were cast into the role of Scrum master:

  • “Kanban and Scrum – How to make the most of both” by Henrik Kniberg
    A very practical and concise guide to Scrum that will also teach you that Scrum is not the only agile process out there
  • “The Goal” by Eliyahu M. Goldratt
    To “get” systems thinking, theory of constraints and the value of ongoing improvement and small shippable increments
  • “Crucial Conversations” by Kerry Patterson et al
    You’ll need all the talking skills you can get!
    (Okay, I’ll admit it: Here I cheat with the 5-limit. I hope you’ll read the 2 subsequent books by the same authors, once you read this one.)
  • “Facilitator’s Guide to Participatory Decision-Making” by Sam Kaner et al
    Learn how to facilitate effective meetings (and what an effective meeting is)
  • “Agile Retrospectives” by Esther Derby and Diana Larsen
    For me retrospectives are the coolest aspect of Scrum; the one tool that I will try to implement everywhere I’ll go, agile or not, because it’s the key to working better

Have fun reading!

PS: If books take too long, try @scrumology‘s Scrum Addendum newsletter, to receive answers to frequent Scrum questions over a period of 3 months.

Decision Fatigue

Today my twitter stream contained a most interesting article: Do You Suffer From Decision Fatigue? The article is long, but worth the read!

Just in case you’re short on time or too exhausted, here’s a summary:

  • Decisions are exhausting, even small ones
    • Especially trade-offs, which are an advanced form of decisions
  • Unfortunately decision fatigue doesn’t feel the same as being tired. So we often don’t realize we’re fatigued and don’t exercise caution, when we really should. Continue reading “Decision Fatigue”

7 Stages of Emotional Dynamics during Change

Two weeks ago some colleagues and me took part in a seminar on “Removing Impediments / Change Management”. The main point we took away is that change is all about emotions:

  • Each change invokes emotions – positive and negative ones.
  • The positive are accepted, while the negative are unwanted and dismissed as resistance.
  • But you need to be aware of emotional undercurrents and address them. (Emotions are contagious and you don’t want negative emotions to spread.)
  • People’s feelings pass through 7 stages that are analog to those of grieving:
    7_stages_emotion_change
    Continue reading “7 Stages of Emotional Dynamics during Change”

Ideal (scrum) team size

When we introduced scrum we followed the conventional wisdom of having cross-functional teams with 7+/-2 members. While I’m still sold on “cross-functional”, I wouldn’t follow the 7+/-2 advice anymore. I’ve observed 5 +/- 1 as the sweet spot (dev team only; SM and PO are additional members).

The big advantage is that communication and coordination is usually easy and effortless at that size.

The disadvantage is that illnesses and vacations hit small teams harder than large ones. That’s why a clever team strives to have every “area” covered by least 2 team members.

But this recommendation is probably highly dependent on context. It doesn’t matter that 5 people can collaborate more easily than 8, when you need at least 8 developers to cover all skills the team will need to create the product.

But in our context – every team covers 3 areas: front end, middle ware, back end; on top of that some teams cover an additional area such as apps, “back back end”, … – 5 +/- 1 members work great together!

Useful links to start TDD / BDD

Test-driven development has a lot to recommend itself:

  • Testable code is usually well structured
  • Specifying tests deepens the understanding of what the code is meant to achieve
  • It makes sure tests are actually written, not omitted in the end (due to time constraints or “Why test? It works!”)

Unfortunately it’s not as easy as it looks at first sight (“Just add some tests, how hard can it be?”). Rather, writing testable code is a whole new skill set in its own right.

Here’s a selection of links I found useful:

  1. Nice intro on why and how to develop test-driven
  2. Great talk on how to design for testability
    (Also check out Miško Hevery’s other talks)
  3. Scope and setup of tests and why “behavior-driven design” is a more accurate name than TDD
    In this article Dan North also proposes the “Given, when, then”-format. This format is great to clearify behavior, even if you don’t use TDD / BDD.
  4. Field report of a developer on how his testing activities changed towards TDD over the years
  5. Why not have a TDD code retreat to kickstart your TDD abilities?

What would you recommend to someone starting out with TDD?

Wanted: (Agile) Coaching Circle

“Practice makes perfect” they say. I guess, self-reflection and reading can only get you so far. That’s why I’d like to join or found a coaching circle, i.e. a regular meeting (at least monthly) to safely try out new techniques and work through tough situations.

Some ideas for activities:

Interested? Leave a comment or mention/DM me on twitter.

I live in Düsseldorf and my kitchen is comfy :). Cologne or the Ruhrpott would also be okay. If there are not enough interested people in the area, we could try Google+ hangouts. They’re a decent enough substitute of a real life gathering.

Change through regularity

The title is not as contradictory as it may seem: Agile and scrum stress the need to be flexible, to change and adapt. But let’s not forget that there’s also merit in the steady, the regular, the predictable. Humans are creatures of habit and I’ve found that the chances of successfully changing behavior increase if you create a reoccurring time for the behavior. Steady dates create a consistency and rhythm that help to trigger and internalize new behavior patterns.

Better life work through regularity:

  • Each sprint we have several timeboxes, so-called “PO slots” to talk about details of upcoming stories. When we started scrum those slots were at random times. The developers kept missing slots they needed to attend.
    Soon afterwards the POs switched to a schedule of 3 times per sprint (Fri, Tues, Fri at 12:00) and the developers usually plan PO slot attendance during standups. They rarely forget it and if they do, they remind each other.
  • We had trouble fitting bug fixing into our scrum implementation (when the bugs were unrelated to stories in the running sprint). Bugs had no clear priority and sometimes stayed unfixed indefinitely. Then we introduced a 2h-slot per week during which all developers fix bugs and that works pretty well. Continue reading “Change through regularity”

Scrum Master Creed

Two weeks ago I resigned as scrum master and will soon go back to just doing UX. Ironically I’m not resigning because I don’t care about agile anymore but rather that I care too much. .oO(Does that make sense to anyone but me?)

Anyway, I’d like to share with you my vision of “scrum master-dom”, as long as I can still say “I am a scrum master (and this is my manifesto)” ;):

Scrum Master Creed

I am a scrum master. I enable people to concentrate on their work by removing impediments, be they company structure, missing resources, group dynamics or individual behaviour. Continue reading “Scrum Master Creed”

Places for information radiators

Big visible charts are a great way to convey information. The more visible something is, the less likely you are to forget or disregard it. This week we tried a new location, when we needed additional maintainers for a handful of systems: Right next to the rest rooms (the door slightly ajar is the Gents).

“Daemons looking for a maintainer”

Works pretty well, much better than the lone email, that we traditionally sent. Already 5 out of 6 daemons have found a loving home maintainer. Added bonus: By striking out these daemons we indicate the progress for everyone 🙂 Continue reading “Places for information radiators”