The solution here is not process dogma

The other day I was discussing a process/dev workflow problem with one of my friends. I managed to get a basic understanding of what the problem was (team disagreement about the importance and sequence of sprint reviews, retrospectives, and planning) but we were both too pressed for time to brainstorm for a solution. He had a meeting to attend, and I had a demo to give.

The only advice I gave was, “The solution here is not process dogma. You can’t just fall back on the Scrum rulebook and say ‘we’re supposed to do it this way’, you have to get to the value of why you should do the previous review/retrospective before the next planning.”

The value, of course, is that you should be taking what you learned from the last sprint and using it to inform your actions of your next sprint. It’s Scrum’s larger-scale feedback loop (the small feedback loop is the daily meeting).  Inside or outside of Scrum, feedback loops are important for making software well.

When I was thinking about it later, I realized that process dogma is never the solution. Software development is intellectual work, and to make a persuasive case with skeptical people, you have to do better than “because the book says so.”

2 thoughts on “The solution here is not process dogma

  1. One of the things I’ve learned with Agile is the whole “fail quickly, learn quickly” mantra. It’s like the little kid with the hot stove; we don’t learn as humans without direct experience (or direct observation). I find that it is sometimes easier to use problems, issues, or even failures as the best way to introduce a process concept or change. This makes it easier to link and remember the purpose of that event or activity with the true purpose.

    The next time you are having a process dogma discussion, ask the team why they want to continue doing these things, when they are critical, and have them focus on making sure those steps support the team in a way that allows the “fail quickly, learn quickly” culture. If they can’t agree that they can’t live without a step, or that it must happen in a certain order, then maybe there’s a more subtle waste issue that could be streamlined or discussed. (or even worse, they don’t buy into the process)

    Good post.

  2. Martin Cron says:

    I hadn’t thought of that scenario in terms of “fail-quickly” although that only works if you have a common understanding of what failure is. Interesting idea, though.

    In this case, it wasn’t as much about success/failure but rather different degrees of success. The new designs would be better with more and more open feedback, but the lead dev is a smart guy who pretty much knew what he was doing. You can’t just point out every design flaw/bug as a failure that would have been caught if only we had done sprint meetings in the correct order.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: