A number of tweets and posts this week point out, correctly, that if you don’t think about what you’re doing, Scrum and Agile won’t work. Apparently people need this reminder.


I’ll be writing about ideas that came by on the Internet this week. I expect that I won’t have fully understood the points the original authors had in mind. I hope that’s OK, I’m writing here not to criticize them nor to disagree. Instead, I’m writing about the thoughts that came up for me when I read what they wrote.

Why vs How

An interesting article by John Allspaw, “The infinite hows” critiques the “Five Whys” approach to working out what went wrong and how to improve. Give it a look: it’s thought-provoking.

However. When we’re looking for root causes, we can’t just go “Why, Daddy?” like some two-year-old. We’re using each level of answer to take we deeper into understanding the situation and, ultimately, improving it. If we do this process stupidly, we always wind up at “because Quantum Physics” or something equally useless.

Allspaw’s idea of asking “How” is interesting, though I would have preferred to see more examples of the “How” process working, ideally compared fairly with “Why”. He does offer links to some videos of a tutorial he presented. I’ve not yet watched those (three hours worth) and probably there are examples there.

I’m interested in seeing “how” his retrospective approach works, because I want to have lots of options in my bag of tricks. As we go through trying to figure out what happened, I want to be practiced in realizing when we’re drilling into why Jack is a jerk, so we can move to exploring how the company’s process, or the facts, led Jack astray. I want to see that we’re heading toward “because Quantum Physics”, so that we can move over toward what to change. My general understanding is that we’re unlikely to be able to change Quantum Physics.

To me, rituals like Five Whys, or Five Hows, or Sprint Planning, or Test-Driven Development, are starting frameworks within which we think. I emphasize: think.

Constraints seem to help keep us on track in our thinking and improving. That’s why I would start a team’s journey toward using “Agile” with fixed-length iterations. The constraint invites us to think about how we can possibly get anything done in two weeks. Once we work that out, we are on the path to continuous improvement … and quite possibly to continuous delivery, which is probably a better place to be than iterative.

Do methods learn?

This brings me to one of two topics raised by my admired colleague Al Shalloway. Al was saying something the other day about Scrum (and other frameworks) not having “double loop learning”, by which I think he means that Scrum (and the other frameworks) don’t have a built in approach to improving the framework itself, rather than just improving how you use the framework.

I want to bring up some issues with this notion.

First of all, Scrum does have an explicit process for improving the Scrum Guide, and those improvements sometimes change fairly substantially how Scrum is done. Now Al asked whether they ever consider changing the “cross-functional team” requirement and my answer to that is that cross-functional teams are so close to “always better” than the alternative that they’d be fools to change it. Nonetheless, Scrum does change over time, in the hands of the creators and their advisors.

Second, in my view, a team using any framework shouldn’t be working on improving the framework: they should be improving the way they do their actual work. And any framework, especially the Agile ones, is a way of calling your attention to how you do your work, so that you can improve it. One of my email signatures says “Scrum is a lens. The work is done under the lens, not by the lens.” It’s true, sometimes you need a better lens. But by and large, the problem with your results isn’t Scrum, it’s how you work within it.

So I think Al is inviting people to change Scrum when they should really change how they work. Sure, Scrum could be improved, and over time it is. I might improve it differently, and I suspect Al would as well. But Scrum belongs to its creators. I think I know a better way to work, and I write about what it is. But Scrum is a decent way to start.

Is this stuff easy, or hard?

Al was also making a point about Scrum adoption being “hard” when it should be and can be “easy”.

I like “easy”. I try to arrange my life to be easy. Most days, it is. I’ve been fortunate enough to have enough money to live on, and enough health and love and so on. So my life, right now, is easy. In the past, it has not been. On a given day, though, it can get hard.

I remember one time I was spewing some BS about how computer programming is the hardest thing ever, because we have to manage so many tiny bits up into big complex systems. Ward Cunningham, who has more wisdom in his little finger than I have in my entire life, said something to the effect that in every discipline people work at the limits.

In that light, even as vaguely as I understood it, everything is hard. It’s hard work janitoring the bookstore. It’s hard work operating the coffee shop. It’s hard work writing the software that sells the coffee. It’s hard work improving the company process so that the coffee-selling software comes out sooner, better, more smoothly.

If we’re lucky, and skilled, we can probably glide fairly smoothly through our lives. Fairly smoothly.

Mostly, I think everything worth doing is hard. If we like it, and we’re good at it, it may seem enjoyable enough to us that we don’t mind that it’s hard. My guess is, it’s still hard.