Scrum and the Minimum Effective Dose

In which I consider Scrum through the lens of "minimum effective dose".

I read a couple articles the other day about the pharmeceutial concept of minimum effective dose and applying that concept to other aspects of life.

Considering treatment of disease with medicine, for any given particular person and situation there’s some dose that will be effective if the medication is going to work at all, that is, will provide the relief or improvement that that drug is able to provide. There are doses beyond that that expose the patient to more of the drug but don’t provide additional relief. Medicine typically seeks to apply the minimum effective dose of medication or other intervention, thereby achieving the relief or improvement that can be achieved while minimizing exposure to potential side effects (and the cost of treatment).

The article goes on to point out that there’s a minimum effective dose of other things in my life.

There’s a minimum effective dose of answering email. Too little responding to email and I will ignore important messages and come off as terse or nonresponsive and failing to engage. Just enough responding to email and I’ve reached a point of acceptable effectiveness, so stop, and apply further efforts and time to achieving a (minimally!) effective dose of something else.

There's a minimum effective dose of writing email. Too little, and the thought goes un-expressed, un-communicated, misinterpretations will happen, terseness will be felt, feelings will be hurt. Just enough and I've effectively communicated something. Too much and the recipient will be overwhelmed and won't read it. (The dose differs by context and recipients -- sometimes it seems that anything longer than a tweet will be too long.)

There’s a minimum effective dose of meetings, and of each meeting. Did that meeting really need to be an hour? Could the improvement sought have been achieved with twenty minutes of meeting?

There's a minimum effective dose for blogging, and for this blog post. How much do I need to write here to achieve the desired improvement? (What's the desired improvement anyway? Getting these thoughts off my mind? Making this post available to share with my colleagues? For future reference? Being discovered by a publisher and afforded opportunities to write professionally?) (And which minimum effective dose am I going for -- the minimum effective dose of my effort, or the blog post that is the minimum effective dose of blog post to then apply to achieve goals? Those are two very different things, since I'd expect I could spend a lot of time editing this to make the blog post tighter end more effective. I'd probably edit out this whole paragraph, for instance. Or at least this parenthetical.)

There’s a minimum effective dose of hours spent at work, of brushing your teeth, of exercise, of … . And the key insight is that the less you overdose, the more resources can be re-allocated to getting to the minimum effective dose of something else.

There’s a minimum effective dose of sleep, which is almost certainly more than I’m getting.

As in so many brilliant concepts, all the words are doing work. The idea isn’t just to minimize the dose without regards to it providing relief for the ailment. Likewise, the idea isn’t just to find an effective dose that might be a significantly greater dose than would have also beeen effective. Rather, the idea is to find the smallest dose that is effective — just enough, but no more. Think of it maybe as The Price is Right except about things that matter. Or remembering Goldilocks and the Three Bears might help.

Scrum is about applying the minimum effective dose of work to solve a problem. A dose that is both minimum (“maximizing the amount of work not done”, as they say) and effective (actually delivers business value by solving a problem).

Scrum does this by carving off the smallest reasonable increment of business problem so solve (basically, as small as it can possibly be while still delivering nonzero real business value), and then solving that problem by first implementing the simplest thing that could possibly work, and then, and this is absolutely essential, refactoring mercilessly (ensuring the dose was not just effective at solving the problem narrowly considered but also isn’t poisoning the larger organism through introducing cruft and making future change more costly.)

Agile in general is about shipping “working software”. I hasten to point out that it’s not about shipping “barely working software”. Not in the sense of fragile, hard-to-use, unmaintainable, barely working cruft. However, nonetheless, the smallest amount of software that will actually “work” (and thus is “working”). “Working” software is thoroughly refactored, high quality software that really “works” for everyone, both the end-users of the software and the people who will support and maintain it and be called upon to enhance it in the future.

Cover photo: from anythreewords on flickr cc-by-nc-sa-2.0.