Have you ever heard of the principle known as Occam’s Razor (or Ockham’s Razor)? I like to think of it as the law of simplicity — simpler explanations are better — all things being equal. Another way to think about it is that you should always start with what you know in trying to understand a situation, outcome or behavior. Only add complexity when you conclude that your simple approach isn’t good enough.
Every business and every software development team should embrace Occam’s Razor. Start simple. Add complexity as you go. The principle applies both to the software being developed and to the process being used to develop it. Good agile development teams understand this.
Keeping the software system simple at the outset and adding complexity over time makes good sense. It’s easier to envision, build and test a simple system. As the system becomes more complex, the testing effort benefits from all the work that’s already been done.
It helps the stakeholders and end users too. It’s much easier for them to comprehend and evaluate a simple system than a complex one at the outset. Their feedback will be more focused and constructive.
Add Complexity as Needed.
Keeping the development process simple also makes sense. Why over-complicate the process with rules, procedures, documents and other artifacts that may add little or no value? Only add complexity and artifacts to the process when you’ve identified clear needs.
That’s why retrospectives are so important to the continuous improvement of software development. Don’t try to change too much, too quickly. Make frequent small changes to the process and evolve it rapidly.
If you’d like to be more agile, embrace Occam’s Razor. When in doubt, opt for the simpler approach or solution. The team will make faster progress and it will be much easier to apply corrections and/or re-group. Add complexity if needed, but only if needed.
For a more detailed explanation of Occam’s Razor, read this Wikipedia entry.