Life, Liberty, and the Pursuit of Agility

Dynamics of Software Development

Jim McCarthy wrote a book called “Dynamics of Software Development”.  If you don’t own it, you should.

I believe it was published in 1995, and I think I read it in 1996. There is little reason for you to do anything else until you get this book and read it.

He has an updated version published in 2006.  The 2006 version includes a CD of Jim’s 23 1/2 Rules of Thumb (For Shipping Great Software On Time.)

You can find this book used for about 1 cent for the 1995 version, and about 2 dollars for the 2006 version.  You have to pay shipping – but still, for 5 or 6 bucks you can get a lot good, old fashioned, unconventional wisdom.  I paid full price for both, and it was well worth it.

If you think the stuff I say is worthwhile, you just might like this book.  If you hate the stuff I say, then this book will give you even more great stuff to hate.

Even without taking into consideration how old this book is (almost 20 years! ) most of his insights are extemely relevent and useful (and downright powerful) if you are doing software development.  A few concepts might need to be updated for changes in technology, and some of it has been surpased by modern Agile thinkging (in my opinion), but overall it’s valuable reading.

Also, he has a set of clips from the  23 1/2 Rules of Thumb (For Shipping Great Software On Time) presentation at his site:  http://www.mccarthyshow.com/the-23-rules-of-thumb/

There you go.  Free advice you can use today.

Agile San Diego Meeting November 1st

It’s been exactly a year since I last  presented at the Agile San Diego Group.

First, a word about the Agile San Diego group:

This group was founded by Carlton Nettleton and June Clarke – over 10 years ago, I believe.  At least I think it was.  Regardless, they currently organize the group and make sure there are meetings just about every month.  It’s a great group, with wonderfully dedicated Agile folks of all experience levels.

I started attending the meetings in late 2006 or early 2007, and did my first presentation to this group in March 2007.

I have been asked to give a talk on my Agile Success, My Agile Maxims, and … gasp … ESTIMATES…

But first, here is a list of the talks I’ve done, just to prove that even though I’ve presented there before, they still ask me back.  That is a good thing, right?

• 2007 – Feb – Agile Thinking in a Legacy Maintenance Effort
• 2008 – Feb – NMock2 Tutorial and Forensic Mocking
• 2009 – June – Code Excellence for the Average Programmer
• 2010 – Did I NOT do a talk this year?  Hm.
• 2011 – Agile Success – why not me too?

Here is the blurb for this years talk ‘Agile Success : The Maxims I Follow’

Many organizations have adopted an Agile approach but have not seen the results they were hoping for.

Agile exists because enough people recognized serious failures in the typical phased (waterfall and other) approaches.  However, in switching to Agile, many have brought along the same old thinking, expectations, and way of doing things that caused those failures.  ‘Agile’ is not a new way to do the old things.  It’s a way to create software that requires abandoning those old ways and thinking.  What was once ‘important’ is now recognized as blocking progress.

In this advanced talk we’ll explore some of the issues that block Agile success.

For example, regardless of how desperately we desire to know the future, we can’t know it until it is in the past.  Getting good (or even less than harmful) at estimating and planning just might be impossible.  Even worse, planning out what we ‘think’ we want is most likely causing our failure to produce something of value. Agile is about discovery, not prediction.

We’ll also discuss the 8 Maxims I follow that have made success possible for the teams I’ve coached and worked with. I don’t have a lot of answers, but I do have a lot of questions.

Please spread the news

I would appreciate it if you could spread the news, and let a few people know about this.

Meeting Location and info:

Link: http://www.agilesandiego.org/monthly-meeting/

We meet at 6:30pm on the first Thursday of every month at The Linkery in North Park.

All meetings are free and open to all.

The Linkery is a restaurant/bar in North Park that has a meeting room for us in the back. Craft beer is available from the bar during the monthly presentation and you are welcome to join us in enjoying some of their top notch food after the meeting.

The Linkery is in a large purple building on the corner of 30th Street and North Park Way, close to the 805. You should easily find free street parking, but there is also a multi-story parking garage across the street that costs $5.

I hope to see you there

I will try to show up early so we can have more arguing time.

Thanks!

The Agile Manifesto – Values and Principles are the foundation.

My Maxims are not meant to distract from or replace them.  My Maxims are just another way to for me to frame my thinking.

I spend a lot of time scrutinizing the things I value to make sure I can minimize my blind spots and unknowns, at least the ones that make the most difference. Seems I am usually my own worst enemy.

I share my Maxims so I can get feedback from you and learn where I can improve.  Please be kind.

Agile Open So Cal 2012 at UC Irvine.

Once again I have been able to participate in the Agile Open So Cal at UC Irvine.  Great fun, great people, great sessions, great etc.   Several people had seen me tweet these “Maxims” or heard me talk about them before, and asked me to present them again.  It takes VERY LITTLE URGING to get me to talk about Agile, Lean, Clean Code, or anything programming.  So, I proposed a session –  and here are the notes:

Title: The 8 Agile Maxims of Software Development

Byline: This time it’s personal.  With Woody, it’s always personal.

Here they be (in no particular order – you can mix and match):

1- It is in the doing of the work that we discover the work that we must do. Doing exposes reality.

I live this daily.  Thinking about stuff is obviously worthwhile – I don’t discount that. But doing is way more important.

2 – “Responding to Change” is impossible unless code is easy to change, easy to maintain, easy to fix, easy to enhance, easy to read, and easy to discard.

The “easy qualities” –  I learned them from the greatest programmer I have ever worked with: Fred Zuill, my little brother. Back in the 90’s he used to do a talk on the Qualities of Software that was pithy, meaningful, and wickedly sardonic.  If you ever get a chance to hear him speak, do it.  If you see him please remind him he owes me $18.

3 – Question Everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.

I’m pretty good at getting comfortable in my ways.  Gotta work at keeping that from blocking improvement.  When I really believe something, I’m likely to be fooling myself.  Lets keep things uncomfortably wonky.

4 – “Working Software” is software that users are actually using. Until it’s in use it is truly useless.

This is my understanding of how “Working Software” should be thought of (as in the Agile Value of “Working Software over Comprehensive Documentation”).

Let’s not fool ourselves: “Potentially Deliverable” is a lot like “The check is in the mail”.

5 – Stress at work diminishes value. Crunch-time is a symptom of harmful and counter-productive attitudes.

Nuff said?  I hope so.

6 – We are the innovators of our process. Learn what works for others, prove it for our self, innovate beyond.

Just a suggestion: Don’t wait until you are an “expert” to innovate.  Just like Jello, there is always room for innovation.  (You remember those ads for Jello, don’t you?  Dang, you young people really missed out on the best days of television. You remember television, don’t you? Dang… I’m getting old, so it seems)

7 – The object isn’t to make great software, it’s to be in that wonderful state which makes great software inevitable – Robert Henri, paraphrased

This is a paraphrase of the well known quote from Robert Henri.  Just replace “great software” with the word “art” and you get the original (and much more meaningful) quote.  I replay this one over and over in my head all the time.  Wish I was the one who had said it! I was introduced to this quote many years ago by Donald Faast, an amazing show-card writer and sign man. I think he is in Colorado now.  If you see him, just say thanks for me if you would.

8 – The more we work at the work we do, the less capable we become -Repenning/Sterman – Make time for improving capability

Dang.  If you haven’t already read the paper “Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement” by Repenning and Sterman then please click on it and read that now: http://bit.ly/Qd3NmR – It’s a pdf file.

9 – I reserve the right to add, remove, change, improve. (This one has been added since the session).

I expanded on these greatly during the session, and invited feedback, observations, and discussion.  Unfortunately I was not able to take notes.  Overall, I feel it was well accepted and if it was not, my memory has already painted it much better than it actually was.  Thank you memory!

Remaining Puzzles, Recommendations, Next Steps:

I pointed out that these Maxims will change and grow, and invited the participants to add, remove, change, improve

Also… A BIG thanks to Drew LeSueur – @drewlesueur – from Integrum Tech

Drew has been very encouraging to me, and on his own he quickly put up a site and posted the Agile Maxims: http://agilemaxims.org/ –   Remember, this whole thing is just me thinking out-loud.

[NOTE: To make sure people are paying attention, I always purposefully put a hidden typo in my posts… see if you can find it.]

I love Document Driven Development

One thing I really miss in Agile is having long, incomplete, boilerplate documents for me to “sign-off”.   I like to write code and deliver working software quickly, but even more I LOVE to read documents and like nothing better than to spend long days before a glowing flat-screen reading incomprehensible nonsense carefully crafted to appear complete and correct while still being essentially content-less.  Doesn’t matter what they are about, as long as they have small type and lots of words.  Of course, nothing is further from the truth.  If I want to read nonsense then I’ll read Edward Lear.  Or my own writings.

So documents are fine, but what about Sign-offs?

Even more, I love to take responsibility for documents that I did not write.  It gives me the feeling that I am a grown-up.  But apparently, I am very unsophisticated regarding sign-offs.  Or I was until recently…

I had one CEO show me the policy for documents at his organization (let’s call it “Anonymous Inc”) where there were 3 sign-off statements for a manager to sign on any document requiring her approval.  Oh joy!!!  It is in the spirit of Extreme Documents, I suppose.  If one signature is good, why not dial it up and try three?  More is always better.  In his defense, he was showing this to me as an example of something he wants to abolish – he understood the absurdity of it.

I approve this document

This typical sign-off is for the manager-type to “approve” the document.  In software development this often indicates that others can rely on this document as being “okay to use for doing whatever it is they do next based on this document”, and that it is Complete and Correct.  This is actually the third signature to apply after the next two required signatures have been taken care of.

I have read this document

At Anonymous Inc, besides approving the document you are also required to sign-off that you have read the document.  You’d think that approving something implies that you read it.  Guess what?  Apparently this isn’t as common as you might think, at least not at Anonymous Inc.  I suppose the “I have read this” signature solves the problem of someone later on saying “I just signed it, but I didn’t read it – if I knew what was in it I would not have signed it”.   I suspect that a lot of documents get “approved” without the approver having actually read it, and VP’s and upper management can always say “I was so busy I had my underling read it – he said is was okay so I signed it.  Let’s fire him, okay?”

I understand this document

Okay – “I approve this document” might make sense in some organizations.  “I have read it” at least keeps some people a bit more honest, I suppose – I’m not sure it would.  But “I understand it” is something I just do not understand.  Still, it is a very fun idea, and Anonymous Inc is all about fun.  Still, just because I say “I understand” doesn’t mean I do.  Any parent knows that.  “I understand” can also mean “shut up already”. But then, what do I know?

Have fun out there, and be careful when you sign-off.

Requirements Gathering

In the traditional phased SDLC approach, a phase for  “Requirements Gathering” is done very early on in the process.  We can argue about all the issues with this some other time – I am just covering one issue here.

My opinion of this “phase” is that it is pretty much worthless: THERE IS NO WAY TO PROVE THAT THE REQUIREMENTS WE’VE GATHERED ARE COMPLETE AND CORRECT UNTIL WE HAVE WORKING CODE.  Working code, in this sense, means code that is actually being used to do real work for the real users. Does that make sense?  If not, you probably don’t want to read on, and probably shouldn’t bother reading anything I have ever written or will someday write.  Plain and simple.

Requirements Hunting and Gathering

One issue is that requirements will rot if not used promptly after collecting them.

Early humans are thought to have used a subsistence strategy where they hunted and gathered (and scavenged and stole) their food for immediate use.  If the food was not eaten shortly after it was obtained, it would rot or otherwise become useless.  The food needed to be put to work within minutes or hours, or at most a few days.  Otherwise, the effort of hunting and gathering would go to waste.

Just like the early hunter and gatherer folks, we have no way to “preserve” the requirements we’ve gathered.  We don’t even know if they are edible.  And yet we store them for a long time, and do a lot of work with them during that time, and base a lot of decisions and work on them (like estimates, budgeting, designs, architectures, ramping-up efforts, coding, testing, marketing, and so on) and all the time the requirements are rotting.

It isn’t until the code becomes true working code that we can get real information about the correctness and completeness.  Until then everything is just assumptions and guesses.  Unfortunately, by the time we learn that the requirements have indeed rotted it is too late.  They have become toxic, wasting our money, time, and effort, and killing the usefulness of the project they are supposed to define.

Early Humans understood this, and therefore rarely wrote software, and never ate mayonnaise that had not been “refrigerated after opening”.  Fortunately for Late Humans (us, that is), someone eventually figured out how to preserve foods so we could buy and eat them days, months, or years and years after they had been plucked, prepared, and packaged.   However, to this day, I have seen no way to preserve requirements.

Requirements MUST be used while fresh

So, my recommendation is: Eat your requirements as soon after you have picked them as possible.  Between the garden and the kitchen they have already started to lose their sweetness.  [Please imagine that there are many other very funny food based metaphors here.  I am not having trouble coming up with them as such, they just don’t seem all that meaningful, and they aren’t as funny as I thought they would be].

How do you do this with software?  You use a very short “discover, define, code/review/re-discover, deliver, discover more, repeat” approach during which we are continually discovering what it is we really need to do:

1. Keep your requirements at a very high and general level until just before use.  Details in the requirements are a smell of the rot.  Pay attention to that.  Understanding the business need is important, details about how that translates into software is not.
2. Pinch off a small but useful bit of one of the high level requirements – preferably something of immediate and high value to the end user, but anything of value will do.
   • Find something that you have a pretty good chance of turning into working code quickly – in a day or two if possible.
   • Prune as you go as needed.
   • Identifying small bits, pruning as you go, and getting something of value quickly are skills you must aquire.  It takes practice, dilligence, and close attention.
   • You don’t have to understand the requirement completely – you will discover the details and what is important as you code it up while partnering with the business experts/users.
   • Prioritizing is useful – you want to take on features in a prioritized manner, but don’t go overboard on this – close enough is close enough.  We’ll talk about this some day.
3. Code it up.  The code-it-up process is not just coding – we must work closely with the business people discovering the details as we go.
   • Code some tiny bit the business expert can see and use (click a button, see a list, choose an option, whatever)
   • Get her feedback, comments, and direction continuously – early on and frequently – every 10 minutes to 2 hours.  Every time you have something meaningful you can show get it in front of the business expert.
   • Sitting side-by-side works well when appropriate, but if that isn’t practical at least be within shouting distance.
   •  If you go longer than 4 hours without getting useful feedback you are wasting your time and need to learn how to work in smaller chunks.
   • You might discover you have completed some small but deliverable bit of funcitonality that is just a part of what you had chosen to work on.  If so, then deliver it, and go on to the next bit.
4. Deliver it.  That is – put the code into actual use with actual users.
   • You’ll discover more things about it as the users use it.
   • This will help expose the next thing to work on.  The real next priority.
   • If they don’t use it once delivered, you’ll have learned something else of value: It wasn’t of value. I’ll cover that some other day – but that is a magical and very valuable bit of knowledge to gain early.
5. Do it again tomorrow (or today, I suppose) with another bite-size chunk of functionality.
   • You are now steering the project toward the best possible result given the abilities and knowledge you and your team have.
   • Important things will become apparent and be added to the working code in a prioritized manner.
   • Useless things will show themselves or be ignored and you’ll waste as little time as possible on them.
   • You’ll get better and better at it.

Following this approach the requirements will not rot because you leave them “on the vine” until you are ready to eat and digest them.  Of course, what comes out after the eating and digesting is not covered in this article:  At some point all analogies break down.

[NOTE: Everything I say in this post and on this blog is based on my experiences, study, and observations.  It is MY OPINION. It is the way things seem to me.  It might be useful to you, might not – I don’t really care.  If you want to argue about it, that is fine.  I am suggesting that there are better ways to do almost everything we do in software development, and that it is worth thinking about it and doing something about it. You might already have better ways to do things, and I want to hear about it.]

I’ve signed up for a few sessions at the SoCal Code Camp at USC in Los Angeles.  The dates of the camp are October 15th & 16th, and I will probably be there both days.  There are about 87 sessions listed so far, so you are sure to find something of interest.

Here are the sessions I am doing:

• Coding Dojo Part 1 – Hands on “mob” programming
• Coding Dojo Part 2 – Hands on “mob” programming
• Code Excellence Part 1 – Demonstration of cleaning, refactoring, and improving working code
• Code Excellence Part 2 – Demonstration of cleaning, refactoring, and improving working code
• Agile Success – An Introduction – An interactive discussion of how to make Agile a success for your project

I hope to see you there… whoever you are.  Let’s talk Agile and write some code.

Losing Interest?  Refill Your Cup Before it is Too Late

A boss of mine once said to me “I wish I had your passion and interest in coding – I lost that a long time ago”.  I think that is kind of sad, especially if you make your living making software.  I don’t think I could spend each work day doing something I was bored with – but of course, a lot of people do that, and I’ve worked with a lot of programmers who have lost interest in programming.  Seems they were once interested, and now they no longer are. 

Perhaps I’m just naturally interested in programming and can’t help myself, or maybe I have a mental disorder – but I seem to be able to stay engaged and still enjoy programming every day. I think part of the reason I keep my interest is that I continuously “refill the cup”.  When I sense I am starting to loose interest (or even long before that) I look for a way to refill the cup. 

One note: I don’t really think it is ever “too late” to regain interest.

I’d like to share a couple of ways that work for me: Intentional Practice/Effortful Study, and Programming as a Social Activity.

Intentional Practice and Effortful Study

My friend Jason Kerney did a talk on Intentional Practice at the San Diego .NET Development Group back in March.  I have a lot of respect for Jason.  He has an infectious passion for programming, clean code, and continuous improvement and I always learn a lot from him.

I had talked with Jason about this idea and like it a lot:  It’s important for us programmers to intentionally practice our craft.  I remembered reading an article on the topic somewhere, and tracked it down at Coding Horor: http://www.codinghorror.com/blog/2008/06/the-ultimate-code-kata.html. In this article from 2008 Jeff Atwood quotes an article by Steve Yegge (from 2005) called Practicing Programming.  You can read this article at http://sites.google.com/site/steveyegge2/practicing-programming. Steve refers to some other articles, and I think if you follow the references in those articles you eventually end up at Kevin Bacon – but you know all about that.  With all this great stuff already written about practicing our coding craft I won’t have to regurgitate that here.

Anyway – Jeff quotes a Scientific American article that uses the term: “Effortful Study”.  I like that, and suggest you read that article too, and then tell me what it is about.

I’ve been meeting up with a few friends at work, at code camps, and remotely during the last few years to intentionally practice programming.  We engage in effortful study to focus on very simple things that lead to code excellence. I have been learning a lot.  Hovever, even more imortant to me is that I feel rejuvinated after these study sessions.   Some of the Katas have been very simple, others have been very complicated.  Sometimes we move quickly to a good solution, sometimes we flounder about and don’t get anywhere.  Regardless, I have a great time interacting with my fellow programmers and find I’ve refilled my cup.  And that is the concept I call:

Programming as a Social Activity Just for the Fun of it

People get together to watch sports, go on bike rides, have dinner, go to movies, play games, get drunk, and lots of other fun stuff JUST FOR THE FUN OF IT.  Programming can be done the same way.  Two people or a whole group of people.  You can do simple Kata exercises, complicated code jam style contests, work on some Open Source project of mutual interest.  Whatever.  A friend of mine (the brilliant and dynamic Llewellyn Falco) used to have “Monday Night Programming” get togethers every week at his house.  What a great idea!  

I don’t know how or why this works for me, but it does – every time I do one of these code dojos or attend a coding gathering, or some similar activity it definately stimulates my interest in the work I love to do: programming. 

It might not work for you, but I love it.  Next time you run into me let’s sit down, open up the laptop, and code something – what do you say?  Come on, it could be fun.

What I did last Thursday and Friday

Last week I was able to spend two days at the AOSoCal 2011 event with 70 other Agile enthusiasts who are all practicing, thinking about, coaching, consulting, and working with Agile Software Development.  I had a great time, learned a lot, made a lot of friends, and can’t wait for the next one.

Like I said several times at the event, I felt surrounded by friends the whole time.  These are the sort of people I would hope can attend my funeral to balance out the other folks who will be there to gloat and trash-talk me.  Do people still say “trash-talk”? 

A little about Agile Open, and Open Space

Each Open Space event has a theme that defines the purpose of the gathering.  Our theme for AOSoCal 2011 was People, Principles and Performance.  That’s pretty wide open.  However, unlike many typical conferences, an Open Space event is invented by the people who show up. The sessions are not scheduled until the morning of the event. 

Everyone gathers in a circle, and the participants propose session topics by writing the topic on a piece of paper and announcing it to the gathering.   Typically, the proposer takes responsibility for the session, choosing a time and space to hold the session, and later facilities the session.  One by one the event schedule it built, and once that is done everyone selects the first session they will attend… and then off we go – the Space has been Opened.  Sessions can be added at any time, and some get combined or morph into something completely different.  Overall it is a very dynamic process.

You can learn more about the process at Open Space World, or at the Agile Open site, or the Agile Open California site, and about the AOSoCal event specifically at the AO Southern California site.

So what is it really like?

From my description it might be hard to get a picture of how this all works – but it does work, and rather nicely.  I encourage you to attend an Agile Open event – they are generally very inexpensive and then you could easily experience it for yourself.  All the people I’ve talked to who have attended these events have been very pleased they were able to join in. 

I have been to a variety of Open Space events and the details vary from one another – but overall I get a lot more of what I want from a conference than I ever get at the more traditional conferences.  One thing I have especially enjoyed is that the sessions are engaging, personal, and interactive – I find this keeps me energized throughout the entire two days.  Most sessions keep things lively using facilitated (or non-facilitated) discussions, hands-on activities, or interactive techniques of some sort.  I love that I get to spend a couple of days continuously interacting with fascinating people who are discovering, learning, experimenting, living, and inventing what Agile Software Development is all about.  How is that for a poorly formed sentence?

In addition, there are endless opportunities to just sit and talk, pair program, or take a walk (or whatever) with other attendees.  Overall, a lot of fun.

So, that is what I did last Thursday and Friday

Cheers!

Written: May 26, 2011

NOTE: This article relates to the domain of software development.  Nothing else.  Also, the idea of failing early, fast, often, and better does not apply in all situations.  Use with caution.  However, it has been very useful for me in software development, and I can recommend that you try it out.  Otherwise, leave me alone, okay?

Failure and Mistakes are a Valuable Part of Software Development

We are going to make mistakes, misteps, and “failures”.  It’s part of the process.  We need to recognize failure as a valuable learning and steering opportunity.  Here are a couple of quotes on mistakes/failures:

“Mistakes themselves are often the best teachers of all.” – James Anthony Froude –

“I have not failed. I’ve just found 10,000 ways that won’t work.”  – Thomas Edison –

That is pretty clear, I think.  If we buy into the idea that failures can bring value, we might want to focus on ways to increase that value – it’s just another application of the concept of “Extreme Programming” – if something brings value, let’s figure out a way get the maximum value for the time and effort spent.  Make sense?

Fail Early

If we believe that we can learn from our failures then let’s start the learning.  The sooner we have a chance to fail, the sooner we get the benefit of the learning that comes with it.

How do we fail early?  Take action and make something small (but useful) right away, and immediately deliver it to the the customer (or user, or whoever) and get real and useful feedback.  Dig in, do something of value, see what works and what doesn’t, learn from it, adjust our course, and march on.

I have seen this quote of Napoleon about his basic military strategy: “On s’engage et puis on voit” which I am told means “I engage and then I see”.  This might not work in all cases but has worked very well for me in software development.  I shorten it to “Engage And See”.   [N.B.: Unlike Napoleon, please attempt in all cases to avoid a disastrous winter campaign in Russia.]

Fail Fast

We want to fail fast so we can learn in a matter of minutes, hours, or days rather than weeks and months (or never).  There are lots of ways to approach this in software development.  One great example which can give us “instant” results is TDD (Test Driven Development/Design).  Before we write any code, we write a failing (and very small) test.  Of course, there is more to it than that – but for my purpose in this article, the key is “VERY SMALL WITH INSTANT FEEDBACK”.  With TDD, the test fails immediately, which is about the shortest feedback loop as we can have.  Once the test is working, any time we work on our code we will run the tests and learn immediately when we have broken something that was previously working.  Instant feedbcak.

This instant feedback is great, but we can’t get instant feedback for everything.  However, what we CAN do is find a way to take very small steps that lead to useful feedback as quickly as possible for everything we do.  For example, the “business people” should work directly with the programmers and round-trip each step/task/feature continuously – let’s work to get this feedback in a few minutes rather than having a meeting every two weeks. You get the idea.  For every aspect of the process we want to minimize the time it takes to discover we have a mistake.

Fail Often

Once we are good at the failing/feedback/learning loop, we can ramp up the learning by failing a lot.  The more things we try, the more failures we might have, the more chances to learn and steer.  We are NOT after failure for failure’s sake.  We ARE after the good things we can learn by trying things that stretch our abilities and understanding.  Another benefit is that we waste less time working on the wrong thing.

I’ve often seen it that a little step towards what the user needs will lead to a change in direction to a better result for the next “chunk” of work.  Sometimes it can lead to a complete about-face where the customer all of a sudden realizes they want to go in a completely different direction, which is also very valuable.  And of course, they most often say “that is great!  it’s exactly what we wanted”.  Well…

Anyways – if one failure is good, lots of failures can be better.

Fail Better

So: early, rapid, and frequent opportunities to fail is good.  All that is left is to find ways to maximize the results of each learning opportunity.  Inspect and adapt.  Here are a couple of ideas:

Finding better ways to communicate feedback is one area worth improving.  For example, sitting side-by-side with the customer to do a hands-on walk-through of a new feature might be (and generally is) more productive than a “shared screen” online session, and is way better than traditional demos.  Being with a real user while they really use the project is the best.   Try it.

Another area we can explore is how to expose hidden requirements.  These are the things that in traditionally managed projects the “requirements gatherers” and customers have trouble capturnig in a document and eventually lead to BIG failure at the end of a long death march style effort. Fun! One approach we can follow is to “take a stab at it”.  If there are things we don’t understand we can often get clarity quickly by coding up what we currently understand and getting it into the hands of a user.  This will often result in something that is close to (but not quite) what is needed – and will allow us to discover the right path.  I am talking about doing real code that does real things for the purpose of showing us where we have a “failure to communicate” – clarity ensues.

Conclusion

Anyways – these are just a few thoughts that will hopefully lead to further thinking and improvement in our ability to make progess through failure.  That could be my new motto: “Progress Through Failure For A Brighter Tomorrow.”  Well, probably not – but… you get the idea.

One Last Quote:

“Agile doesn’t prevent us from making mistakes, it gives us a way to reduce the cost of those mistakes.” – Llewellyn Falco, paraphrased

I’m looking forward to the Silicon Valley Code Camp in Los Altos Hills. There are over 140 sessions planned, with a lot of great topics. If you are anywhere near Silicon valley, I highly recommend you find a way to attend. It’s free, and it goes on all weekend October 3 & 4, 2009.

You can get all the details at the website: Silicon Valley Code Camp

I’ve been to a number of Code Camp events in Southern California.  This will be my first time at the Silicon Valley event, but from the looks of it, it’s going to be a great weekend.

I’m giving two talks with Llewellyn Falco: Code Excellence for the Average Programmer, and Unit Testing the Easy Way.

The Code Excellence talk is a demonstration showing how you can get control of your code using simple techniques that guide the way to maintainable and extensible code, and can lead to a quality code design.  These techniques have been used by us to bring out of control projects into a manageable condition – the rules and practices we follow can be used by anyone, are easy to do, and lead to code that is a pleasure to work on.  We’ve given this talk all over Southern California, and no one has died yet.

Unit Testing The Easy Way: Most people have already discovered that code is easier and faster to write with unit tests. But writing those tests can take a lot of time and effort. Come learn how to write tests quickly and easily, so you can get on to what we really want to be doing: coding.   This is a very lively presentation that is a lot of fun.  Llewellyn has been doing this talk all over the place, including at the Agile 2009 conference in Chicago where it was very well received.  This is my first time helping out on this talk, so it might be a lot of fun to watch me crumble under the pressure.  Don’t miss it.

If these don’t interest you, there will be plenty that will.

So be there, October 3rd & 4th, 2009.