The concept of failing fast seems to be
part of much agile and lean thinking. However the concept is not in
the agile manifesto nor the principles behind it.
Traditionally failing is not seen as something good so that got me
wondering why agile think it is good and if there is both a right way
and a wrong way to fail fast?
In agile we do want to be able to
respond quickly to changes and most agile methods (1) prefer short
iterations and it is also one of the guinding principles that we
should deliver software frequently. The reason we want short
iterations is so we can quickly get feedback, and respond
accordingly.
But failing fast is not just something
related to iterations and feedback – failing fast has also become
somehting to strive for in the daily work and coding. For example in
this article by Jim Shore he tells about failing fast in code
and how that can help you debug faster and build more robust code.
However if I was to tell a team to fail
fast and gave them Jims article as an example, it could still easily
be viewed as one one to solve a particular problem and not an
explanation of why it is generally good to fail fast.
Reading the article something else hit
me when Jim starts to talk of assertions, how and when to put them in
your code, and how to structure the message that you want the
assertion to give. Perhaps it is not the failing fast that is
important, it is the fact the we get good information about a problem
early on – or in other words: we get structured feedback that lets
us act on it.
That harmonises very good with this
article by Braden Kelley that I found while researching why
failing fast is good. The authors advocate that the central question
you should always as yourself when experimenting is: ”What do we
hope to learn from this effort?”. And I think that is the same that
Jims does with his assertions – he only inserts them when he can
learn something significant from them, and uses a lot of time
structruring the information he gets back – i.e. he thinks about
what he hope to learn from inserting the assertion at precisely that
place.
So to me ”fail fast” cannot be seen
as a meme in itself – it has to be put into a context and serve a
purpose before it becomes valuable. Failing is just one outcome of an
experiment and unless you have procedures in place to learn form it
(like the Deming circle: Plan-Do-Check-Act) or it holds no value.
Being a language oriented person I
agree with Braden Kelley that failing is a negative word, and since
what we really want people to do when we say fail fast is learn fast,
why not just say that: ”Learn fast”. To me that much better
catches the thinking behind agile and lean than fail fast.
- I say most because I do not know all agile methods out there. However all the ones I know prefer short iterations.
Ingen kommentarer:
Send en kommentar