The goal of the session was to figure out ways to enable experimentation within a team and to minimize failure.
It was immediatly established that failure does not exist when experimenting. A hypothesis, like implementing a certain process will improve our team, is put forth and then tested. The hypothesis is then proven to be right or wrong. The implementation of the process is either successful or not, but not being successful is by no way a failure.
So it seems to be necessary to establish a culture of experimentation where people don't see costs, they see investements; lost time because of a faulty process implementation has cost the organization money, but it was in fact an investement if you can learn from your mistakes. An IBM manager, or so the story goes, had spent two years and four million dollars implementing a product that didn't get the expected success. The manager went to his manager and offered to resign. His superior told him not to leave, because IBM had just invested four millions dollars into him!
Instead of using the quote "Fail, fail and fail again," maybe we should use "Try, try, try and try again!" When there is no failure, there is no fear. The important thing, however, is to stimulate your team's curiosity and initiative. The marines drill this into every new recruits. Take initiative!
How to get started? Where to go? Start with the current rules and slowly improve on them. This is always the safe thing to do. Other times, a complete overhaul might be needed to save a company.
How do you measure a success? You can always get feedback from a customer. They could tell you how much money you have saved them or how much more money they are making because of your product. When experimentation results in positive changes with those metrics, you have success. Those metrics can also be used to prove that improvement is possible to the sceptics among our teams.
Finally, a word of advice, let your manager know of your experiments. This establishes trust and your manager will be able to protect you should something go wrong. Whatever happens, don't get your manager in trouble!
--
Thanks to all of you who came to the session, it was very informative.
Comments (1)
Doc List said
at 11:30 am on Nov 2, 2008
In the paragraph in which you discuss hypotheses being "proven to be right or wrong." I'd argue that they're not proven right/wrong, but valid/invalid or functional/nonfunctional. The results are very local, and represent what's important/functional/valuable to that team. Within that context, I like the idea that there's no "failure", only testing and proving.
On the other hand, from an external perspective, individuals, teams, and initiatives can be said to fail - if the goal is to increase productivity, reduce defects, improve time to market, then not meeting the goal may be considered failure. If we get away from the idea that "fail" is bad, and get into the idea you talked about that "fail" is learning, then it's okay to fail.
For instance, learning to walk is based on failure. In fact, walking itself is the process of constant failure - you have to lose your balance to move forward.
You don't have permission to comment on this page.