Smallest Possible Change

I’ve heard this phrase “smallest possible change” many times working in an agile development environment over the past six years. Most of us could nod our head and look at each other approvingly when planning, executing or reviewing technical or design work. Making the smallest possible change, in theory, helps to keep the system or application working and less prone to errors–especially ones that sneak up on you. It keeps tickets in the sprint cycle manageable — practical, sound advice working in small chunks. It also makes reviewing code easier. I have one problem with the “smallest possible change,” and it deals with its use in applications that are too deep or lack solid project management.

The smallest possible change is often the last possible change.

Michael Tribone

We have too many things to accomplish with a small number of people. We kid ourselves when we think that we can go back through something and iterate new, better, or accessible solutions. It’s fiction. We tend to tack on more “workable” solutions to something that needs to be re-evaluated, refactored, or rewritten. We use it to control the overwhelming feeling of having a large project driven by emotion and professional leanings. Most of what we do is for ourselves. The user comes last. We have too much to do.

I’d instead advocate for the best possible change or no change at all. The best possible change from my point-of-view is the one that helps the user first and the front or back-end developer second. Assisting the user means simplifying a task for legibility or completion, converting actions into outcomes whether or not money is involved, or more to the point, putting their needs before ours. We should be efficient with our development process and make tasks easier for ourselves, but what we do in a development cycle is typically at the users’ expense. We need to change the behavior. If the work to be done is more extensive than what we can do in the sprint, then we should remove the smaller tasks to get it done. Or move it to a sprint where it can get the attention that it deserves.

What if the best possible change involves a lot of change for a user and violates the Principle of Least Surprise? Meaning that you’ve changed the workflow or expectations in such a way that the pattern to accomplish something is now very different. Hopefully, one of two things has happened. First, you’ve user tested the significant change and iterated the design to get to a point where the payoff is more significant than the surprise.

Or secondly, you’ve broken up the change into smaller, meaningful changes. The big surprise is revealed in smaller discreet chunks over a certain amount of time to make the transition easier on the user over time. Here’s the rub. You have to outline those smaller meaningful changes in your tickets for each sprint to get the whole thing done. You have to be the advocate for the entire solution all the way through. Removing too many selections from a drop-down menu is a step towards a more significant redesign. Outline the whole thing and be its steward.

Leave a Reply