Guilherme CalobaProduction Engineer| PETROBRASRio De Janeiro, Rio De Janeiro, Brazil
I have some experience in R&D projects, and for a while we had this mantra of failing cheap and failing fast. Are you familiar with this concept? What do you think about it? We did it in a waterfall environment, and a "fast fail" would take some three to six months, at least. When you are doing agile project management, does the adaptative nature makes it hard to fail, at least when you consider scope?
I've heard it as "fail early, fail often" on new product development programs and done wisely, I have found it a really great way to get a lot of new experience up front instead of learning hard lessons later.
At the core, it is scientific method with an eye on budget and schedule. Do controlled experiments on a simple level to see what works and what doesn't before you scale it up and invest too much on things that won't work. It really is a good fit for Agile as a framework to organize the development and direct the purpose.
In my R&D experience, often you have technologists off in labs developing things that their intended customer can't use or don't want. I personally feel that the more organized Agile framework, with the focus on customer interaction and early deployment for feedback, helps to direct the learning process to focus more on customer needs rather than what is fun to play with in the lab. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
There seems to be the notion with stakeholders that all failure is catastrophic, which it obviously is not. And the concept of fail fast prevents this type of catastrophic failure. It can be seen as testing the waters. Failing fast = small losses, Succeeding fast = small gains, Failing slow = big losses, Succeeding slow = big gains. Saving Changes...
Jacob RechinSenior Operations Coordinator| Golden Gate UniversitySan Francisco, Ca, United States
There are great thoughts in this blog. A few things in common are that failing sooner means less resources spent in the wrong direction for too long. Frequent, sooner-than-later is valuable time and cost saving feedback. I can see though that, when presenting something squarely based on a proven concept, that this mindset might not be entirely appropriate as using iterative approach to nail a proven concept (something others have done successfully in the past) would seem like reinventing the wheel. In this case, I think of the effort would be much faster and cheaper after investing adequate time before hand to learn from and research those who have already done something similar. Saving Changes...
