Occam’s Razor and Agile Frameworks
Occam’s (or Ockham’s) razor is a principle we attribute to William of Ockham back in the 14th century. The principle states that “Entities should not be multiplied unnecessarily.” The popular interpretation is, the simplest explanation is usually the correct one.
It has inspired numerous expressions including “parsimony of postulates”, the “principle of simplicity”, the “KISS principle” (Keep It Simple, Stupid).
Most of Occam’s principles originate from philosophy. Maybe this is why you will now find many approaches (especially the principle of simplicity) in the basics of design principles.
Given a choice between functionally equivalent designs, the simplest one should be selected. Implicit in Ockham’s razor is the idea that unnecessary elements decrease a design’s efficiency, and increase the probability of unanticipated consequences. [¹]
When comparing technologies that perform the same function, one that is simpler in design will tend to be simpler to construct and repair. Additionally, it will tend to require greater skill to use, whereas a technology that requires less skill to use will tend to be more complex in design and more complex to construct and repair. For example, a straight razor is relatively simple in design and construction, but requires considerable skill to use, whereas an electric razor is relatively complex in design and construction but requires little skill to use. [²]
Agile Frameworks
Now, go back and reread the two referenced passages, substituting design and technology with Agile framework. I also like the straight razor analogy, mostly because I shave using a straight razor. I only had to cut myself once (badly) before I realized I needed real skills to use such a simple tool. Counter to that, it took me several failures in complex organizations, to realize using a complex Agile framework does not translate to simple implementation.
Though I agree Scrum can address complex adaptive problems, I think it does so in a controlled team-level environment. I don’t see it working well on complex organizational-level environments. It’s like shaving a yak with a straight razor.
On the other end of the spectrum, we have SAFe, LeSS, DAD, [enter your acronym here]. These frameworks have emerged, in part I believe, because complex organizations expect complex solutions. We shave the yak, with an electric razor that Dr. Seuss would be proud of.
My Thoughts
First, though larger organizations are often complex, we do not need to make Agile frameworks even more complex. It seems like very few customers care how they get work done. They just care that they deliver their product or service on time and within budget. If you’re looking to add control points to process and governance, look for what will lower risk and increase value throughput. Make processes as simple as possible and allow work to flow through your delivery system. Simplicity (by removing dependencies) is the key. Dependencies break Agile. While you should be careful not to add too many control points to a process, creating unnecessary work for everyone. Additionally, don’t simplify too much either, resulting in chaos. Focus on systematically removing dependencies and look for that happy medium. As a result, you may just need three things.
Just be careful not to cut yourself.
[¹] http://www.visualgui.com
[²] http://www.omick.net
Comments (4)
Mark Levison
Derek – I completely agree with your note. One small point LeSS isn’t like the others. It demands you simplify, it demands descaling, it requires understanding Lean and Systems Thinking. All of those would seem to be in agreement with your comments. So I’m confused by your lumping it in with the others.
Cheers
Mark
Mark,
I really appreciate your feedback. There was hyperbole in my post, by lumping it in with the others. I appreciate you calling me out on it. The question is, would supporters of the other frameworks do the same?
Ram
I agree with Mark. LeSS radically simplifies “more than 1-team” product development AND eliminates a lot of waste (including non-value add roles,) in that process. And you don’t need a red yarn to manage dependencies :)
The red yarn comment made me laugh out loud. Excellent addition. Thank, Ram.