Failure and the Agile solution

business-failureFailure.  Not a great word, and something that genuinely strikes fear in to people’s hearts.  Over the past few of months I have listened to a couple of podcasts that have offered differing views on failure.  This is a topic that has always been at the forefront of my mind, as I always wanted to be someone who was not afraid to fail.  Obviously no-one wants to fail, but if you have the concept ingrained in your psyche that failure is an acceptable part of success, then you are more likely to listen with an open mind and try new things.  But life and work is competitive, and human mentality leaves little room for failure.  I work for a consultancy where the Owners are working every day to win new projects.  Once the projects are won, they must in turn be successfully implemented.  The web application or web site must be completed on time, on budget and meet, if not exceed, the requirements.

So where can failure fit in to the software development process?

Before answering that I will quickly summarize the two podcasts that inspired this article and their differing points of view.

I.A. Podcast – Failure: The Foundation for Success

Jeff Parks interviewing Brad Nunnally

This podcast really emphasizes a need to embrace failure as part of a design and development process.  They cover three key parts to failure recognition:

1) The importance of retrospectives and documenting warning signs to learn from past mistakes.

2) Not to shy away from assigning blame and highlighting the success of others.

3) The importance of embracing failure and keeping an open mind, realizing that everyone makes mistakes

Through a combination of these ideas, Jeff and Brad believe the quality of your work will increase and you will garner more respect and a closer working relationship with your colleagues and customers. Furthermore, the very act of embracing failure will leave you more open-minded.

37 Signals Podcast – Jason Fried’s speech at BIG Omaha 2009

Jason Fried is someone I respect hugely.  He is an entrepreneur who brings a forceful clarity of vision and thought to his work.  His blog articles and podcast episodes are always thought-provoking and centered around forthright, positive action, and the distillation of problems in to simple concepts.  During this podcast he references a previous article he wrote on Signal vs. Noise titled Learning from failure is overrated, which takes a very different view of failure to Jeff Parks and Brad Nunnally.

Jason does not agree with a culture of celebrating failure that he thinks has developed over the last few years.  Critically, Jason’s view on this topic is from an entrepreneurial / business perspective, not a development team perspective, and from this vantage point he see’s embracing failure as absolutely the wrong approach.  If you are embracing failure then you are focusing on the wrong thing.  Jason says that you should focus on your successes predominantly.  If you tried 10 things and 8 failed, you should focus on the 2 successes and try to replicate that, rather than analyze and emphasize the failure.  He is not suggesting you ignore your failings, and obviously lessons should be learnt, but for progress to be made you need to be successful, so that should always be your focus.

So to go back to my earlier question, where does failure fit in to the development process?  Agile would be my answer.  The Agile process encapsulates many of the points highlighted by these two podcasts, and my own beliefs on failure, and enshrines it in a procedural guideline that failure will happen and is just part of the process.  The key tenets of this philosophy in relation to failure are captured in these points.

1) Iterations

The very reason for iterations is that there is an implicit understanding that the first time around not everything will be correct.  The best we can do is strive to complete a requirement as we understand it at this point in time.  At the end of the iteration it will be reviewed and tested as it will be a working piece of functionality.  Feedback will come from the customer and it is either signed off as done, or that changes need to be made, or new stories added to that theme.  There are no failures as such, just a cycle of build and review that will eventually result in the finished product.  This both embraces failure as part of the process but also focuses on the positives and what is right in that first release, and builds from there.

2) Iteration retrospectives

Iteration retrospectives are such an important part of the Agile process and yet one that does seem to overlooked at times.  We were guilty of this in one of our recent projects and I think we repeated mistakes as result.  A retrospective is where the cards need to be laid on the table and a open discussion needs to take place.  Each team member needs to be honest about what they did well and what they struggled with, whether that be a personal issue or one with another team member.  The failings of an Iteration are clear for people to see, but what is most important, is laying out a plan for how to mitigate these problems going forward.  Often you can do this by looking at what has worked well and using those lessons learnt.

See this great article on retrospectives also: http://www.agilegamedevelopment.com/2008/06/when-we-talk-about-agile-we-use-phrase.html

3) Team work

Brad Nunnally in the IA Podcast mentions the flat team structure of Agile projects as a negative when embracing failure because there is no one in a position of overall responsibility to make owning up to failures possible.  I believe this to be an issue with the team in which Brad is working rather than an issue with Agile teams.  Your team in an Agile project is a team of equals.  You should all be pulling in the same direction, and are responsible to yourself and each other to complete your tasks.  There is no wall over which you can throw work.  If work did not get done, whether it was your task or not, it is the teams failing, not the individuals.  Whoever was assigned responsibility for the task will have to be the one that announces the failure, in the daily stand-up or retrospective, but it is the team who bears the responsibility.  Everyone must rally round to dissect why the problem happened and how it can be addressed.  A failure occurs because it was not raised early enough, or it was not addressed when it was raised.  If the problem was never raised by an individual, that can be a case where individual failure has occurred, and is most likely a personal trait that needs to be worked on, such as talking up when you need help, something that can be difficult for some people to do.  Obviously this becomes more difficult if there are disinterested or unmotivated individuals on the team, and if that is the case then we are moving in to the area of HR rather than Agile self-organization.  Overall, working in a self-organizing, flat team of project oriented individuals, should result in a culture of union of purpose where failings are embraced by the team, along with the successes.

So shall I just go out a start screwing things up?

homer-failureWell, yes and no.  I think there is value in both Jeff Parks/Brad Nunnally’s embracing of failure and Jason Fried’s embracing of success.  I think it is important to have a healthy fear of failure, so I do cringe when using the word “embrace”.  That is being a little too familiar and comfortable with that outcome.  Failure should, and always will be, a prickly and uncomfortable topic, and I don’t think that is a bad thing.  We do not want to fail, we want to succeed.  If you are too comfortable with failure, you may start to confuse progress with consistent failings.  Lets not forget, failure does have a consequence, whether that be a monetary loss, or a disgruntled customer.  Positive reinforcement is needed to make sure that what is working is captured and repeated, and demonstrable progress is occurring.  I think this quote from Fred Brooks (author of “The Mythical Man-Month“) in the most recent Wired (August 2010) says it well:

You learn more from failure than success. In failure you’re forced to find out what did not work. But in success you can believe everything you did was great, when in fact some parts may not have worked at all.  Failure forces you to face reality.

I like that last sentence, “Failure forces you to face reality.”  I absolutely agree, but the nature of reality is that we need to succeed or else we may not get another chance at failing!  So I would say, lets embrace our successes but make sure to face our failings head-on, taking positive action to ensure the same mistakes are not repeated.

Failure and the Agile solution

My Favourite Podcasts

RSS feed sign with headphonesI have become a firm fan of podcasts over the last couple of years, and listen to a lot in the area of software and web development. So in the manner of blog posts that list things, here is my list of favourite podcasts (in no particular order).

You will see that many of them are focused on User Experience (UX) or Design rather than being straight BA podcasts.  This is because the BA podcasts I have tried have not been nearly as engaging, interesting, or thought-provoking as the UX/Design ones.  Also there aren’t nearly as many of them.  I find the UX side of web development really fascinating.  The intersection between  psychology and user interaction is such an evolving field, and I find that a lot of the concepts I learn from these podcasts are very applicable to my BA’s work and how I approach a project for a client. Anyway, enough waffle, here’s the list:

UIE Brain Sparks – Jared Spool

  • SpoolCast – My favourite podcast.  Jared Spool is a godfather of web usability and user research and he interviews various UX and Usability professionals.
  • Userability – Jared and Robert Hoekman answer questions from listeners.
  • Revealing Design Treasures from the Amazon.   This is one of the best of the bunch, Jared gives a conference talk on the design secrets of Amazon. Genius, and funny.

I.A. Podcast – Jeff Parks

  • Primarily about Information Architecture (IA), but a wide variety of guests from different backgrounds and different specialties and perspectives.
  • See this episode on Agile and the User Experience.

Boxes and Arrows

  • Again an IA focus, but very design centric also.  The best part of this podcast series is they post all the talks and sessions from the IA Summit that happens every year, and there are some really fascinating speakers.
  • Check out the key-note speaker Dan Roam from the 2010 IA Summit, I really enjoyed this one – http://boxesandarrows.com/view/ia-summit-10-dan.

Boagworld Web Design – Paul Boag & Marcus Lillington

  • I may just like this because it is English and I get to top up my accent, but it is also very relaxed and engaging and I love the split between web news and interviews. It’s also funny.

The Big Web ShowDan Benjamin and Jeffrey Zeldman

  • They have very interesting guests, and it is live streamed.  I think Dan Benjamin is a very natural presenter and has great questions, I listen to his other show also, The Pipeline (see below).  The co-host, Jeffrey Zeldman, is not so natural, however he is a powerful presence in the industry as he started A List Apart and works for Happy Cog and often has poignant things to say, although he doesn’t always say it at the right time, and it can interrupt the flow of the conversation.

The PipelineDan Benjamin

  • An interview show typically with web entrpreneurs who are always really intelligent, well spoken, well read, and basically interesting and succesful people.
  • Try out this show with Jeffrey Veen (who started Adaptive Path as we ll as a myriad of other successful ventures).

37 Signals Podcast – Jason Fried & David Heinemeier Hansson

  • An awesome Chicago company responsible for products such as Basecamp. They are passionate about creating usable products, and have firm opinions on entrepreneurs and start-up web companies who actually have a business model and can make money. Dare to dream 🙂
  • It’s not a podcast but check out the “Bootstrapped, Profitable, & Proud” series starting with the interview with the guys from Campaign Monitor

Think VitaminKeir Whitaker, Ryan Carson, Mike Kus

  • I’ve only listened to a couple of these but I enjoyed them. They do get in to more codey speak occassionally, but they are also great designers.

You Look Nice TodayAdam Lisagor, Scott Simpson, Merlin Mann

  • Just hilarious. Not web, or design, or in fact focused on anything at all. Three friends shooting the shit.
  • Merlin Mann started 43 Folders which is one of the original productivity sites.

TED Talks

  • Just because they’re awesome.

Requirements.net Podcast

  • The only BA focussed podcast that I still occasionally listen to, worth checking out.

Agile Toolkit – Bob Payne

  • This looked really promising when I first found it, but after listening to a few, it always seemed like Bob was interviewing success stories for his Agile coaching, and the discussion was too specific to one company or situation.  It was kind of like listening to a really long in-joke you would never get unless you were there at the time.  However some of the new episodes look interesting so I may try it again.

dConstruct 2009 – Various

  • A conference run every year by the Clearleft web design agency in the UK.  They have posted all the talks from the 2009 conference as podcasts and they are really fascinating.

I hope you enjoy these as much as me. I’d love to hear your comments.

Cheers.

My Favourite Podcasts