ao

What people see in their heads when learning iteration

Drawn in 2020.

As aI was forced to try scrum, lean, and iterative web development in 2012. A senior leader had heard that it was the *right way to work*, and made our team implement it. We weren’t happy; we were really used to waterfall processes, which were “predictable”. We groaned day-to-day, while trying to apply it.

I need to remind myself of that don’t-want-to-change feeling from time to time, because I found myself, later on, teaching teams how to adopt iterative development processes. I ended up appreciating the value of lean development and iteration so much that I sometimes forget what it was like when I saw it as a crazy, unrealistic way of working. When you’re in a role where you’re “optimizing” and redesigning processes, understanding the natural fear of change is always critical.

I made the sketch below because it reminds me of the look in people’s eyes when you first start telling them that you’ll implement a process, where you

a) can’t fully dictate when the total scope of the product will be built, and

b) where you (as the business/ build team) can’t 100% dictate the end state of the product, because the process’s value is about learning from real people’s usage/ experience of the thing. Which means… the features can, and likely will, change.

The point is to be clear on the desired benefit, even if the tactics of getting there evolve over (sprints of) time. (Versus waterfall, where you’re sure of what you’ll build, but your plan is vulnerable as things pop up).

Originally posted on Ghost as Cost of Quality.