Life, Liberty, and the Pursuit of Agility

NOTE: I have deprecated this version of this post.  I have put the new version at:

New Version of Are Daily Stand-Ups Harming Your Team?

This original post was not as clear as I had hoped, and I don’t mean for anyone to get the wrong idea. Thanks to Ron Jeffries and George Dinwiddie for their converstaions that helped me better organize my thinking and the purpose of this post. 

Here it is.  You weren’t looking for it, but you found it.

Mob Programming!

One little blog post cannot even begin to explore this complex subject.  Here is a start at beginning the first part. Or perhaps, a pre-beginning.

If you really want to figure this out quickly don’t wait for me to figure out how to write about this.  Just come and visit me sometime and I can quickly show you the whole thing.  It really isn’t hard.  Or, even easier, read the Agile Manifesto Values and Principles.  It’s all there.

A Few Paragraphs You Don’t Need To Read

It’s obviously not my job to tell you (teach you, show you,  guide you, coach you, whatever) how to be effective at software development.  My job is to write software, and coach and work on a team that is writing software – and to deploy that working software so people can use it.

I don’t write books, sell certifications, do trainings, or provide workshops for a living. I have nothing to sell you. [I’ve occasionally done introductory sessions about Agile stuff for a company or two.  I love doing that, but it is not my living or my job. ]

The company we work for makes irrigation products. Great company, great team, great product.  I truly love being able to come in to work every day to be with my team and do the work we do.  Point is: I make software for a living.

Estimates are NOT a deliverable

Regardless of how we define “estimate”*, it is not a deliverable in the world of software development.  I’ll write another post about that if you don’t agree .  (That’ll show you!)

The Basic “No Estimates” Approach

Here are the basics – in very simplified form told as a mini “case study”, based on a real situation from a long while back  (not my current job) – but I’ve changed the details so no one will get mad.

Players:

• Boss – you can think of Boss as the “Product Owner”, “Customer”, or “User” or some combination of these.  In any case, Boss is a “person(s)” who knows enough about the purpose of the software (or some part) to make reasonable decisions, and who is responsible and has authority for making those decisions.
• Woody – you can think of Woody as the person who guides the software development process – could be a devleoper on the team, or some other person who understands software development better than I do. We’ll call him Woody.
• Team – everyone else working on this “project”.

History:

• This was a while back, but Woody was already capable at “No Estimates Software Development”.
• This project was a new “internal” application.
• Project accessed existing databases, but also would likely need it’s own database.
• Boss had never worked with No-Estimate Software Development.
• There was a lengthy “requirements document”. It was believed that everything in the requirements doc was necessary. [Note: It was a mess, and if I had any influence I would have abandoned it].
• Team had all necessary skills and knowledge to do this work.

Approach for day one:

• Start with the huge list of way too much stuff that Boss says needs to get done (the original requirements doc, so to speak).
• Ask Boss to select one “small” thing that she felt was very important.
• That “small” thing becomes the “thing we are working on right now”: We’ll call it a “Story”, but on this job we didn’t use words like story.  We called them features.
• Team starts work on the Story.

Approach for day two and each day after that:

• Team works on the thing we are working on right now.  Nothing else.
• Team constantly assesses the work we are doing, and splits the current Story if it is not easy to understand or it is not clear how to start on it.  We check with Boss, but have no issue breaking things down.
• Team asks questions as soon as they come up, and get the answers right away.  Without this, projects drag on through endless muck.
• Team completes the Story we are working on right now (or the part of the Story that we split off)
• Team deploys the Story if it is deployable, and if it is not deployable then Team works with Boss to understand what needs to be added to it to make it deployable, does that, and then deploys.
• Team asks Boss to pick the next thing she thinks is very important.  It can be the other part of the previous story, or any other thing she thinks is important.

Result:

• First deployment happened in a little over a week.
• Project was deemed “done” in about a month and a week.
• As we started delivering usable software, the users and Boss started asking for different things than had been described in the requirements document.  The users and Boss started fine tuning what we had delievered – noting things that they wanted to be done differently.  This is a valuable and wonderful thing.  This is how requirements emerge.
• After about one quarter of the “features” described in the requirements list/document (including the additions the users and Boss had asked for), Boss decided the project was “done enough”.  The users were doing most of what they needed, and the rest wasn’t important enough to do, at least for the time being. There were other more important things to get done on another project.  The users were happy. Boss was happy. Team was happy. Woody was happy.
• Team was iterating (but not time-boxed), and incrementally delivering.

Observations:

• Boss wanted estimates, and also wanted the work done as quickly as possible.  I made the case that we could try to get some critical feature into production ASAP, and then revisit the idea of estimates later. After the first deployment, no requests were made for estimates.
• Estimates are part of the “comprehensive documentation” that we value less than “working software”.  If you don’t see that – please let me know.
• I am sure you saw the big win, right? We discovered the needed features. Most of what was thought to be needed was not actually needed.  Doing the work of writing the code in small pieces and getting it into real use made it possible to steer the work.  This is the “requirements emerge” concept.  I urge you and encourage you to think about it and experiment with it.  It is GOLDEN.
• Even if estimates were not liars, we just simply did not need them.

Well, that might be a little help.  It’s just one very basic example.  But it’s real.

This all just seems like “plain old Agile” to me.  Many people tell me I’m wrong.  What do I know?  I’d rather be wrong about what to call this and be getting a lot of work done than the other way around. Let me live in my delusions.

NOTES:

* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.

Llewellyn Falco and I have done a number of presentations together.  I’ve always loved working with Llewellyn: I’ve learned a lot and had a lot of fun.  This “Practical Refactoring” presentaion is one of my favorites.

We’ve called it Practical Refactoring, 2-Minutes to Better Code, Code Excellence for Every Programmer, Code Excellence for the Average Programmer. I think we’ve presented this about 20 times.  We finally made a video of it, and thanks to Llewellyn’s dedication to editing it and posting it on YouTube – you can all now enjoy watching the fun.

This presentation was done at the Inland Empire .NET Users Group in San Bernardino.  They are an excellent group, and if you live near enough to attend their meetings you won’t be disappointed.

If you write down every 3rd word spoken, and then write it out backwards, you can read the special secret message hidden in the video. Remember, resistance is futile – or at least frowned upon.

I’ve noticed that there seems to be a lot of people who feel they get a lot of value out of doing estimates*.  There also seems to be a growing number of people who suggest that estimates* are wasteful and even harmful to a project.  Whichever works for you, either way, use it. I have only one thing to suggest: Do your best to make sure you are not blinding yourself from finding new and better ways.

[Disclaimer: I am only talking about Estimates* as used in software development as part of planning or otherwise. See notes below]

I take the “not blinding myself” very seriously. Here is my Agile Maxim about that:

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

[ You can see more thrilling and uplifting Agile Maxims here: Agile Maxims ]

You are perhaps thinking “But Woody – you seem to have a very deeply held belief that Estimates* are Useless and Wasteful – you should practice what you preach and Question That!”

Some will say “Woody: You should Practice what you Preach!!!”

You are absolutely right – I should practice what I preach. (By the way – I don’t believe that all estimates* and estimating* is useless and wasteful, just a great deal of how they are typically used in software development).  And of course, I have gotten to where I am in my thinking about estimates* by questioning the value and usefulness of estimates* over a long time – in both the realm of software development as well as other fields I have experience with.  Yet still, EVERY DAY, I re-scrutinize my thinking on the value of estimates* – and whether or not we should use them.  Sometimes more time, sometime less time – but it is rare that I don’t think about the usefulness of estimates* (or of not having estimates*) at some point in the day.  If estimates* bring value, and I am losing out on that value because I am too bone-headed to see it, I want to be set straight. And on the team I work with we constantly experiment and try  new things, old things, different things, same things – whatever we feel we need to do to learn and make things better.

So… here are the sort of things I ask myself or consider every day about estimates*:

• If I found that estimates* are indeed wasteful, what would I do?
• If I found that estimates* were misleading and giving us bad information, what would I do?
• What if estimates* never existed – if they were never invented… is there some other way we could work?
• What if there is a better way to get the right work done using some other process, would I still estimate*?

And it goes the other way:

• What if we were not able to make decisions unless we had estimates*, what would I change about our work?
• What if we needed estimates*, but the estimates* we were doing were not very good, how would I fix that?
• What if estimates* provide a way to see into the future and make GREAT decisions, what would I do?
• and so on…

And so on

This whole questioning process takes little time on a daily basis.  Occasionally, I scrutinize this sort of thing to a much deeper level – sometimes in a focused retrospective, or just thinking for a while, or in talking with other Agile-maniacs, or even by doing (or attending) a session at some user group or Agile Open event. I WANT TO KNOW THE TRUTH!  I want to steer and adjust my thinking.  I have no pride – if I learn a better way, I will evaluate how to incorporate it into what we’re doing – and experiment, reflect, tune, adjust, throw out, bring back, etc.  I am always open to THROW OUT THE OLD if it is no longer useful.

Bottom Line

I don’t care if you use estimates* or not.  If it brings value to you, do them. If you want my opinion: I suggest you find a way to make sure they help and don’t simply use them because “that is how we do things”.

To quote the poet:

Whatever gets you through the night, it’s alright, it’s alright.

NOTES:

* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.