Try, fail, adjust, go back to step one. So it goes on until failure turns into success or you get bored and leave to do other stuff. Such is business. It’s extremely rare that an original idea becomes immediately successful. Most ideas go through an iterative process of trial and error and the end success comes from a sometimes completely different idea than the initial one.
Take the Confected application that we are building. We set out with certain expectations, built and tried it out during this year’s TEDxWarsaw. Some of the expectations were correct, some were utter failures. We collected all the lessons and went back to our workshops to adjust the project. Meanwhile, while we’re talking to other conferences about setting up the application for them, we often stumble upon ideas for the application that are significantly different from the direction we’re pursuing. And our success relies on whether and how we’ll take those offshoots into account, because as they say, climbing a ladder faster won’t help you if it’s placed against the wrong wall.
So when you consider any Agile methodology for software development, irrespective of whether that’s Scrum, Kanban or any other funny name, they’re nothing else than a business approach to engineering. You correctly assume that you’re unlikely to get it right the first time, so you try, fail, and adjust. You collect feedback and put it right into production, often completely changing the original designs.
It’s a way of working that’s quite familiar to business people but often strange to programmers. “But the specs said nothing about this!” Indeed they haven’t, but our knowledge of the world changes (or the world itself does) and refusing to adjust is asking to become evolution’s prey.