A few myths to consider about "simple"

 

For every problem there is a solution that is simple, neat, and wrong - Twain

Everything Should Be Made as Simple as Possible, But Not Simpler - Einstein

The concept "simple" has been confused in the Agile space. Fewer parts does not equate to simpler, but it is often stated as if it were. There is also a difference between how simple something is in its design and how simple it is to use. Sometimes a complicated (internal) design provides a simpler (external) behavior. Cameras with autosteady is an example.

This leads to a useful insight - the simplicity of fit for purpose is more important than the simplicity of how it's built.

Another myth - providing more means you're being more prescriptive.

Not if the "more" are options to use. For example flow or iterations. Less prescriptive, possibly more complicated, but not with good design.

Simple to understand is important. But the understanding needs to be about what to do - not about the approach being taken. "Buy low sell high" is simple to understand, but difficult to do.

We must remember there are two bodies of knowledge required when we adopt Agile. The first is understanding the doing of Agile (eg, small increments, quick feedback) and having an Agile workflow. The second is how to do these.