Fail Fast, Fail Often, Fail Cheap

I’m working my way through a thought-provoking book – Know What You Don't Know: How Great Leaders Prevent Problems Before They Happen, by Michael Roberto. The main focus is on how business schools do a terrific job at training MBAs how to solve problems, but do little to help them find those problems in the first place. The book identifies ways to find the small problems that may become bigger if left untouched.

One way to find problems is to encourage mistakes. Huh? Really? YES! Maxine Clark, founder and CEO of Build-a-Bear Workshop, even provides “Red Pencil Awards” to people who make mistakes, and find a better way of doing business through that mistake. Clark attributes her mistake-finding attitude to her first-grade teacher, Mrs. Grace. Clark explains how Mrs. Grace would award a red pencil to those who had made the most mistakes, because she wanted her students to be actively involved in class discussion, trying to answer all questions, no matter how challenging. Clark states, “She didn’t want the fear of being wrong to keep us from taking chances. Her only rule was that we couldn’t be rewarded for making the same mistake twice.”

Awards for identifying – even making – mistakes encourage a learning environment, allowing team members to experiment, try new methods, and step out of one’s comfort zone.

Thomas Watson, the founder of IBM, states “If you want to succeed, double your failure rate.” Finding where you fail and adjusting or modifying to no longer fail ensures that you are actively learning, and therefore growing in your knowledge. There are lots of stories about failure in invention and business – the light bulb, the “post-it” note. Sometimes the initial plan for a product can be seen as a failure when actual use is what takes off. Kleenex tissues were initially designed to remove make-up, and it was a source of initial frustration when the company discovered that folks were using them to blow their noses!

One of my favorite quotes is from the fictional teacher, Ms. Frizzle, in the book series “The Magic School Bus” – “Take chances, make mistakes, get messy!” How else will you learn, succeed at something new, and bring more value to your client?

Now, get out there and fail! Then fail again! Your eventual success will be that much sewetre sweeter!

Be Prepared

Agile teams are supposed to be self-managing, but I have yet to see a team that didn’t have a cadre of managers helping them along. Now, that’s not necessarily a bad thing. There certainly are times when a politically-savvy project manager can ease the path to production for a team, or when a development manager can spend the extra time needed to argue the case for a virtual build box or a coffee maker.

But, the team needs to know how to manage itself as well. How do tasks get doled out? What happens when a team member is consistently late to stand-up? How do architectural decisions get made?

Agile teams can take a page from the Boy Scouts – be prepared. Take a little time to explore some “what ifs” and create an agreements document – essentially a working document identifying what to do in specific situations.

An agreements document is an excellent tool for two reasons:

·         Team-building – the best kind of team-building doesn’t happen on a paint-ball range. It happens in the office, where you actually can start to see the results of your work as you… well, work. Creating agreements on tardiness, the presence of phones in meetings, etc. can help the team recognize the behaviors that are each person’s “nails on the blackboard.”

·         Less need to think during a crisis – if process are identified and documented on what to do when production servers die or when an architectural discussion turns nasty, the need to remember isn’t left to our flaky brains, and the tendency to revert to old ways won’t happen. To paraphrase Einstein, “The application will not evolve past its current state of crisis by using the same thinking that created the situation.”

While there will remain time where the team needs to actively respond to a situation (underestimation of the sprint’s tasks, architectural disagreements, a dev environment dying right before a release), the creation of team agreements will help the group be ready for many issues they face on a day-to-day basis.