The Trial and Error Approach Really Works

Much of what happens around us involves trial and error or the process of elimination. For example, if you’ve ever gone to a medical doctor complaining of not feeling right, you’ve seen this in action. Doctors rarely pinpoint a medical condition immediately. They usually start eliminating possibilities by asking questions. They run some tests that eliminate more. They generate a short list of ailments, ask more questions, run more tests, and arrive at a diagnosis.

The same thing happens when you take your car to the repair shop and complain about a noise, rattle or vibration. The mechanic will ask some questions, take a test drive, examine some mechanical components, and check diagnostic codes. Many possible causes are eliminated. With luck, a firm diagnosis will result and your car will be repaired.

The same is true for software development.

Business processes and associated software often follow a trial and error approach too — or at least they should. Complex business problems aren’t solved with a one-hour meeting followed by a few months of software development. Some would have us believe that they can analyze the business problem, write lots of documents, draw many diagrams, and build a comprehensive solution. That approach has a horrific track record yet continues to be championed by insecure and overbearing managers.

Agile software developers recognize that some trial and error is needed to solve tough problems. In fact, the best and fastest way to solve any difficult problem is to try something. Experiment. Learn from your mistakes. Keep improving.

Cross-functional teams build better software.

Any agile approach demands teamwork — collaboration between the business stakeholders and the software developers. If the work environment is positive and supportive, people will work together and take prudent risks. If the work environment is feudal or siloed, failure is more likely.

Maybe the way we build software systems isn’t really a matter of development approach — waterfall vs. agile. Maybe it’s more about people and how they work together — or don’t.

Before you decide to jump on the agile development train, ask yourself if the corporate culture is capable of inter-departmental collaboration. If you implement an agile approach using Scrum, Kanban, XP or Lean principles in the wrong culture, you’ll end with some new principles wrapped in a waterfall mindset. Is that what you want?

photo credit: Alegrya via photo pin cc