Life, Liberty, and the Pursuit of Agility

Estimating Software Development

Anyone who knows me will know that the title of this post is meant as a joke.   For software development, it is my experience that estimating is rarely useful and always easy. 

Well… a little clarification:  estimating is NEVER useful but ALWAYS easy the way I have typically seen it done, which uses the WAG* method of providing some numbers that seem plausible and that will allow the decision makers (stakeholders and managers) to approve the start or continuance of a project with a clear conscience. That is, when things sour later on they can always blame the developers for giving them inaccurate estimates.  And the developers can always blame the “requirements people” for giving them unclear, incorrect, or incomplete requirements.  And the requirements people can always blame the stakeholders for providing bad direction about what was important, and so on.  Regardless of who is part of this process, it is one big happy circle of blame that lets us all do the wrong thing and still keep our jobs (not always happy for everyone, actually, and sometimes not everyone will keep their job).  I have simplified it here, but the basic idea is sound.  As long as everyone is good at deflecting blame, and everyone is willing to continue on saying we’ll do it better ”next-time” and after only a few people have been fired then everything is fine, right?

Let’s estimate a game of chess

Chess is a game that some of you may have seen.  It provides a very limited environment with only 6 different and charming pieces that have very limited ways in which they can be used, and there are only two players.  Simple. The whole game can be contained in an area of about a square foot or even less, and the complete rules can be written on the inside of the box lid.   Just like Candy Land, it is very easy to learn and play. Not so easy to win, perhaps - but that makes it interesting enough to be an engaging game for some.

So, here is a description of a simple “project” and I need your estimate:

Win a game of chess. Losing is not an option. Tying is not an option.  We will only make money if you win.  If you don’t win, the company is at risk, and you will lose your job (and mine).

Also, I have a diagram of a chess game with the exact position of the pieces as required at the end of the game.  To make money, it needs to end up just like the diagram.

Oh, one other thing: we don’t know yet who you will playing, but we’re pretty certain it will be someone who knows how to play the game, and might be pretty good at it.

That’s it!  There are only a few requirements:  That you win, and that the board matches the diagram I’ll give you.  Easy! 

What I need to know is exactly how much this will cost me.  In this situation, cost is the number of moves you’ll need to meet the requirements.  Oh, also, we don’t have the diagram yet, but we’ll have it soon.  Still, you should be able to estimate it because it is basically the normal chess end-of-the-game arrangement with pieces here and there and so on, and you have the opponent in a checkmate.

Should be easy to estimate that, right? 

Well, I hope you agree this is impossibly difficult.  Or actually: just plain impossible.  First of all, there is not enough information to do a good estimate, and even if we had all the information, there are many variables and a lot of stuff we have no control over. How close do you think your end results would come to the requirements?  Would you be willing to stake your job on making a decent estimate on a chess game in this situation?  Well, as long as you could blame someone else and promise to “all do better next time” you’ll probably be okay.  Or you could be a consultant and be paid and off to your next contract before someone actually has to play this game you helped them estimare.

Getting better at estimating is like pulling teeth

I hear it over and over:  Our estimates were not accurate and we had a lot of trouble because of that.  We need to get better at estimating. 

It is similar in a way to saying “My tooth hurt, so we pulled it out.  Now I can’t chew as well as I used to.  We need to get better at pulling teeth”.  What is the real problem?  Shouldn’t we work on that instead?  Hint: Getting better at pulling teeth is not it.

So what would you do to get better at estimating the game of chess, based on the basic scenario we described above?   Could you get better at it?   How good would you have to be before it had real value? Is it worth spending time on getting better at it?  What is the real problem.  Hint: Getting better at estimates is not a solution to anything because having bad estimates it not the real problem.

My suggestion: Stop That! 

I haven’t seen much value in estimates.  Actually, in the software development work I have done, I can’t recall any situation where estimates were of value to the actual job at hand.  Someone wanted them, someone saw value in them, and sadly - important decisions were made based on them.  Do you think those were good decisions?  People often tell me that “even though we know the estimates are inaccurate, they are better than nothing”.  I prefer nothing.  There are better ways.

Almost everyone tells me that estimates are very important, but estimates are actually a blind spot hiding something of actual importance and value.  This almost universal acceptance that estimates are important and useful is harmful.  A predictive approach such as waterfall itself depends on estimates - and estimates are how we make the predictions.  Don’t think “waterfall” and predictions are harmful?  You probably should be reading some other blog.

Estimates are based on guesses about the time needed to do work we don’t yet understand.  Noting about this gives me confidence that the estimates have value.

It seems I always make enemies when I suggest this, but that is not my intention.  I want to do effective work on meaningful stuff - that is my intention.  I don’t want to be spending time on work that has no value, that causes misdirection and waste, and potentially destroys any chance of being effective.  That is painful.  There are MUCH BETTER WAYS to approach software development. 

Do you need estimates?

It could be useful for you and your organization to question your use of estimates and explore new ways to think about your “need” for estimates.  What does a heroin addict “need”?  Does he/she “need” heroin?  What do you think? 

One last thing:  Do not ask me for an estimate on how long it will take to eliminate estimates from your process.  It is too much like a game of chess, only very complicated.

Here is a start at clearing up our thinking.  Let’s do a little thought experiment.

Which would better help if we have decided to eliminate estimates and find a better way in our organization? :

• Get rid of all upper management.
• Get rid of all developers
• Get rid of all upper management and developers
• Something else more realistic

Who is most insistent that estimates are important?  Who do those people answer to?  Are those people actually good at anything?  Are they going to fire you if you say things like this?

So what might be better?

What can we do instead of doing estimates?

Nothing.  Don’t do estimates.  Simple, clean, easy. 

The correct question is: since we think that estimates are important, and you say that they are not, how can we develop software without doing estimates?

The answer is… Well, I suspect no one reads this blog, so that doesn’t really matter.  This is just a clearing house for my thinking and has nothing to do with the reader.  However, I am sure to write some stuff someday about ways to get things done without estimates, and I guess some of my earlier posts cover some of this thinking. If someone is actually interested and asks for me to cover this, I might get to it sooner.  But I am sure you can figure it out without me - this is truly simple stuff.  Read the Agile Manifesto and Agile Principles, and use them to invent better ways.

Another hint: Get good at frequent incremental delivery of useful software.  That might be worth considering.  That takes a LOT of experience and open thinking.

NOTES:

* WAG = Wild Ass Guess.  A Wild Ass is a beast that is indigenous to parts of Africa and Asia.  A Guess is a guess.  Wild asses are about as good at making software estimates as anyone else.

I like to talk

I was given an opportunity to present a session at the Agile San Diego group last night.  I have some pretty clear ideas about how to be productive in developing software (and a fair number of solid successes in turning out useful software), and those who know me are sick of hearing this stuff.  I am always looking for an opportunity to find someone new to bore.  Thanks for stopping by. 

Agile Success seems elusive

Over the past 13 years I’ve been using (or sometimes fighting to be allowed to use) an Agile approach in software development.  For about a year I have been slowly gathering my thoughts into a talk on Agile Success.  I’ve given about 5 talks on this theme now - each very different, and the audience has mostly been folks new to Agile thinking.  

Agile San Diego is a group of highly sophisticated Agilists who are typically expert debaters and highly competent loud arguers -  I like it very much.  So I took this opportunity to solidify my materials and put it to the test.  The results were so-so, IMHO, but it is in the doing of a presentation that I discover the presentation that I must do.

Agile Success - Why Not Me Too?

In its current state, the talk is called “Agile Success - Why Not Me Too?”.  It’s mostly about the “Why Not”: we tend to block ourselves from achieving good result by hanging on to “old and busted” thinking and practices.  Perhaps we do this because the old ways seem so right (but they are oh so wrong) , or perhaps just because we are comfortable with them, or “our customers (or boss, or manager, or marketing) require it”,  or … well  - there are a lot of reasons we keep doing things the same old way - you get the idea, I am sure.

For this instance of the talk, my main goal was to show that we are typically our own worst enemy.  More specifically, it is the things we think are most solid, meaningful, useful, and productive in our process that are the most likely to be hampering our progress and wasting our time and money - and we don’t have the skills or openness or whatever to recognize this.  In other words, those are our blind spots. 

The Maxims

Here are my three main talking points.  I call them Maxims (to differentiate them from the Values and Principles):

Critical Maxim 1:
It is in the doing  of the work that we discover the work that we must do.

Critical Maxim 2:
Embracing change is IMPOSSIBLE if your code is not Easy to Read, Easy to Maintain, Easy to Grow, and Easy to Change.  Everything else is secondary.  Everything.  This applies to “lean start-ups” too!  Code becomes HARD really fast - often within a few hours if we are not paying attention.

Critical Maxim 3:
Question Everything

In my own work, I use the Agile Manifesto and Principles as a guide to evaluate everything.  I use them as a quick sanity test for every practice that I am using or thinking of using.  However, I also recognize that I am the inventor of the process I follow, and therefore use the 3 Maxims to keep from getting off track. 

Using Maxim 3, I also question the value of the Maxims and the Agile Manifesto/Principles themselves.  It is a vicious, never-ending continuous loop of vicious, never-ending continuous loop of… - so I don’t get too serious about it.  Whenever my brain starts bleeding I take a break, let things coagulate, and then get back to it.

Also, the 4 values, 12 principles, and 3 maxims are not written in stone.  It is likely that there are other important missing maxims/values/principles, and there might be errors and partial omissions.  But this is a living thing - adjustments are allowed - cells split, some things become vestigial - and so on.  Complete re-writes are allowed.  Nothing is sacred.  Continuous improvement must include improving the things we improved previously and think can’t be improved.  Throwing some things out and letting other things die off is okay.

The talk took less than an hour, plus about 1/2 hour for discussion.   Not bad for solving all the problems that ever were or ever could be.  Well, no one else saw it that way, but this is my blog and I can make up anything I want.

However, what I was trying to show is that my current thinking (which is based on real, every day cranking out of healthy, usable functionality) is that:

• most development efforts are chock-full of harmful practices that we hold sacred yet are massively wasteful or even counter-productive
• that we are the cause of most of the problems
• and there is a way to make things better.

I won’t cover the rest of it here unless enough people actually ask for more.  That has never happened yet, as I don’t think anyone reads this blog, and most people who attend my talks spend most of the time trying to find a way to respectfully withdraw. 

The most important thing:

For me, acceptance of Maxims #1 & #2 gives a clear way to evaluate 90% of the badness I have encountered in software development.  They are on an equal with the Agile Principles in the way I use them.  Maxim #3 keeps me honest about Maxims #1 & #2.  I have another 3 or 4 slides on Maxim #3 that guides the questioning process.  Perhaps I’ll write about that sometime soon.  It is not the 5 Whys, and I don’t think there is a Japanese word for it either.

There you go. 

Have a nice day.

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 turing 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.

I Like to Hike

I like to hike.  I hike whenever I can.  I prefer the trails and paths and wilderness, but I’ll hike on the roads and streets when I have no other option.  There is not much real wilderness around where I live anymore, but there are a lot of places that are remote enough that they seem wild.  Good enough for me.

I was out hiking today on the Coast to Crest Trail with my wife and our dog.  I’ll call him Rex, but that is not his real name (he’s asked me not to use his real name).  Rex is a great hiker, and at 9 years old he is still anxious to get out on the trail and can out-hike most.

We got about a mile up a pretty steep trail and Rex started favoring his left hind leg.  We’re not sure what happened, and he wouldn’t tell us.  We suspect he was bitten by a red ant since we couldn’t find a thorn or a cut or any other obvious issue - but we did notice a bunch of red ants on the trail.  Whatever it was, we decided to turn back and call off the hike while Rex was still in good enough shape to hike himself out of there.  Rex weighs about 45 pounds, and if he couldn’t make it under his own power I’d have to carry him.  I could probably handle it - but it would be very slow going.  Also, the whining and complaining is something neither my wife nor Rex would care to put up with.

As we headed back down the trail, I was thinking of other hiking I have done, and the risks and possible trouble you can get into out on a hike,  which eventually reminded me of a saying they have at the Grand Canyon:

Hiking the Grand Canyon: Getting to the Bottom – Optional. Getting Back to the Top – Mandatory

I’ve hiked in the Grand Canyon to the Colorado River and back out four times, including a “rim to rim” from the North Rim down to the Phantom Ranch and the River then up to the South Rim.  It is a lot of fun, and even though there are a lot of hikers out on those trails, it’s not hard to get a sense of wildenerss in that spectacular setting.  Some trails are lightly traveled and you can get very remote and lonely if you like.

These Grand Canyon hikes are ”backwards” compared to most I’ve done - typically, we start at the bottom of some mountain and hike up - and once all the hard uphill work is done, we can come back in a relatively easier downhill mode.  At the Grand Canyon, we start at the top and hike down and take pride in our tremendous pace.  When it is time to return, it is all uphill and we start to remember how “pride cometh before a long trudge up”.  That is the way they built the place.

From the top of the Bright Angel Trail on the South Rim you can see many of the fabled milestones and exotic destinations such as the Mile-and-a-half Rest House, the Three Mile Rest House, Indian Gardens, Plateau Point, and the Colorado River itself - you can even see the Phantom Ranch from some viewing areas.

All these interesting and enticing places don’t look all that far away. They seem very close, and they are if you are a crow.  But this is deceptive - the distance for the non-crow hiker is greatly extended due to the long grades and switchbacks necessary to make the trail possible to hike.  Things that look close are many trail miles away.

I’ve seen a lot of casual hikers sprightly scamper down the first two or three miles (or more) thinking it’s an easy hike, only to find it takes a great deal more time and effort to hike back out again once they turn around and head back to the rim.  Especailly if you are wearing flip-flops or other inappropriate footwear.  And worse things can happen.  On one trip I met a man near the river (met is a bit of a lie.  He was lying on his back in the middle of the trail almost unconscious.  It was more like “stumbled upon” than “met”).  He was suffering from euvolemic hyponatremia (look it up).  At least that is what I think he was suffering from.  Anyway - he was suffering.  He should not have been down there.  We helped him with some electrolytes and salty snacks and then helped him slowly make the couple of remaining miles to the Phantom Ranch. He recovered, but had a hard several days.  As a side note he was hiking with his ex-wife.  Now THAT is interesting.

Another trick of the Canyon is that as you hike down, the temperature increases.  At the rim where it might be 65 degrees on the very same day it can be 100+ degrees at the river.  (On one day I was there it was 120f at the river and 70f at the rim.  Dang! ).   What starts out as a pleasant, cool, and easy down-hill hike turns into a stressful, hot, dry, and very lengthy up-hill trudge.  Once you have used up your water, water starts to seem more important to you.  And don’t forget the electrolytes (remember the euvolemic hyponatremia?)

There are about 400 rescues per year in the Canyon (not all are hikers, but a lot are), and they only do rescues for the really critical cases such as heat stroke, serious injuries, and other medical emergencies - a lot of hikers get rescued by other hikers who share their water, food, gear, time , and electrolytes.

The “backwards” nature of the hike (Down then Up, Cool then Hot, Seemingly Short, Actually Long, Easy then Hard) lulls hikers into going too far down the trail.  It all seems so easy and fun at first.  By the time you discover how HARD hiking back out is, you’ve already used up all your food, water, energy, happiness, and other resources.  You’ve spent everything and now comes the real work - hiking up and out of the Canyon in the heat.  And oddly, the distances are even longer hiking up than hiking down.  Funny how that works.

The reason to hike in the Grand Canyon (or anywhere) is slightly different for each hiker: Recreation, fitness, adventure, or whatever - [Note: in the world I live in we rarely hike out of necessity anymore.]  In the Canyon, a lot of people also have a goal to get to one or more of the milestones or well known points of interest, or all the way to the river.  But the real goal for every hiker has to be to get out alive and in reasonably good condition (aches and pains are acceptable, I suppose, but dehydration, heat exhaustion, heat stroke, and alarming leg swelling aren’t so nice) .  Getting out is Mandatory - All other goals are optional.  They have warning signs all over the place at the Canyon about the risk of misjuding your skill, ability, and the difficulty of the environment.  Still, many hikers end up in trouble.

What The Heck Does This Have To Do With Software Development???

You probably hoped I would forget to drag Software Development into this post, but…sorry.  Here goes.

I’ve seen this same basic scenario in Software Development.  The goal, the abilities of the organization, the apparent short distance to enticing and desirable “points of interest”, and the risks are all often misunderstood.  All the available money, time, and effort have often been expended by the time the real work of coding/testing/deploying begins and we realize how difficult everything is and how far we’ve gone down a winding, narrow trail we can no longer get back up.  And even worse, we have nothing useful to show for it except documents, diagrams, designs, and some code that can’t climb out of the test-and-fix cycle.  Whew.  Glad that is over.  Now - your assignment - go back over this post and equate all that stuff about hiking to some software development effort you have worked on.

I’ve seen and heard about a LOT of backwards, risky, hot, long, painful, death march trudges - Lucky for me I have worked on only a few of them.  Just remember - there is a way to work that isn’t backwards.  Let’s do that instead.

This turned into a long post. I think the corollaries are obvious.  Maybe they aren’t.  Maybe I am just full of it.

So, have a good night.  Tomorrow go do something fun - and stop wasting your time reading stuff on the Internet.  Go out hiking instead.  And by the way - hiking the Grand Canyon is FANTASTIC.  I recommend it to anyone still healthy enough to get out and hike - thousands of people hike the Canyon each year without problem.  Bring some electrolytes or at least some salty peanuts and cheese crackers or something.

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

In an interview you can view at InfoQ, Jean Tabaka talks about the difficulties of decision making for Product Owners on an Agile project, and an approach called RAPID Management that provides a model for being an effective Product Owner. 

Here is the link: http://www.infoq.com/interviews/Agile-Jean-Tabaka#

I have read Jean’s book on collaboration as well as articles by her, and find I always find a lot of value in her writings.  This interview is particularly relevant and useful to me this week as I am working on ideas to make planning and decision making more effective for the teams I work with. 

One thing I found particularly helpful is Jean’s comments about the difficulty some people have taking on the role of a decision maker.  Although Agile emphasizes collaborative decision making, most organizations still expect someone (that is, some individual) to take responsibility for the decisions made.  In a Scrum environment, for example, it is the Product Owner who has responsibility for decisions about what gets worked on.  

Although this pressure and stress of decision making is real, as Agilists we have an approach and some practices that help to reduce or even remove this stress.  We understand that decisions need to be made at the “last responsible moment” and that we can steer development using a toolset or practices designed to address and remove the “single wringable neck” problem. 

Practices such as:

• rapid feedback
• on-going collaboration with customers and end users
• working with Sprints (or iterations) that allow us to take on small, human digestible chunks
• regression and unit tests in place that help take the pain out of making changes
• emergent design and continual attention to technical excellence
• and so on

In the Agile world mistakes aren’t as costly as they are in a traditional waterfall project.  Because we are delivering value rapidly and visibly we can learn from our mistakes as they happen and apply what we learn in the next Sprint, instead of 6 months later during some “stabilization” phase when it is impossible to recover.  Most decisions are relatively small allowing us to move forward confidently without fear that we’re making big, costly mistakes.  We can grow our knowledge rapidly and making correct decisions becomes easier as we go. 

This is a big part of what I enjoy and treasure about Agile.  The end result is that we can make decisions with less stress knowing that we have gathered enough knowledge to make good decisions, and that no mistake is a show stopper.

I’m signed up to do 3 talks at the upcoming UCSD SoCal Rock & Roll Code Camp in La Jolla.   The dates are June 28th and 29th at University of California San Diego Extension - you can get the details and maps, schedules, and etc. at the link above.

Agile Development Basics - In this presentation I cover the Agile values and principles, as well as the a little about why we need something like Agile.

A Quick Introduction to Scrum - Here I’ll present the who, what, and how of Scrum.  Scrum is one of the most common methodologies for managing an Agile effort.

Agile Coding Techniques for Legacy Apps - This talk shows various techniques for introducing unit tests and micro tests into an application that has insufficient tests.

I am planning on doing a couple of additional talks on using NMock or Mock Objects, and I’ll post the details here as soon as I get the time to sign up for the presentations.

It is always a great time at all of the Code Camps.  I’ve been to 4 or 5 in the last year, including the Fullerton and San Luis Obispo code camps - I highly recommend you attend if you possibly can!  Every Code Camp I have been able to attend has been a wonderful experience for me.   So far there are about 80 sessions, and there will probably be a few more added over the next week or two.

[This is part of my series on the Communication Problems with Waterfall]

A common flaw of many develpment documents: You can’t test them.

It is a glaring flaw of the typical document generated in software development that there is no way to know if it is correct or complete.   We can do our work diligently and honestly and still end up with a lot of mistakes, missing pieces, extra (unneeded) pieces, and misunderstandings.

It would be nice to be able to “click a button” and prove that we have collected all the requirements, and that they are exactly what the customer needs and/or wants, or even that it is what the customer THINKS they need or want.  We can’t test an ER Diagram to prove that it will result in a database that stores everything we need and nothing more than we need, and allows us to create, retrieve, and use data with all the qualities we expect.  We can’t test object models and sequence diagrams (as far as I know, anyway) to prove our design is useful or good.  Well… you get the idea.  Continue reading ‘You Can’t Test Documents for Correctness or Completeness’ »

Jason and I had a great time presenting at the XPSD last night, and meeting up with the Ruby programmers later on at the Rock Bottom in La Jolla.

As far as I could tell it went over pretty nicely, and everyone really enjoyed watching Jason coding live on his laptop where the ReSharper demo license had just expired.  He didn’t let it stop him, and it was a nice demonstration of how pitiful life can be without a good refactoring tool. 

Here are the slides from the NMock2 intro presentation givn at XPSD.org on April 3rd.

NMock2_Intro.pdf

Don’t get your hopes up too much - they are just my talking points.  I hope you find them useful.

When I do my “Quick Introduction To Scrum” presentation  the most popular feature is a little Sprint task board animation that I put together in PowerPoint.  I got the idea from a slide from the ScrumMaster training that Ken Schwaber provides.  My main goal was to try to give a visual “time-spanning” representation of what a Sprint task board ”looks and feels” like over a two week Sprint that is operating in a more or less healthy manner.    If you aren’t doing Scrum, but rather some other Agile methodology,  just replace “Sprint” with “Iteration”, and “Scrum” with “Agile” and you’ll do fine. 

I’ve converted the animation to Flash and added a little running  commentary to cover a few things about how we

Continue reading ‘The Task Board Animation’ »