Life, Liberty, and the Pursuit of Agility

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.

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

Below are my 8 Agile Maxims.

They are not in any particular order, although my favorite is probably the paraphrase from Rober Henri.

You’ll note that there are now Nine… the ninth one simple is a disclaimer that this is bound to grow, shrink, or otherwise change over time.

• It is in the doing of the work that we discover the work that we must do. Doing exposes reality.
• “Responding to Change” is impossible unless code is easy to change, easy to maintain, easy to fix, and easy to enhance.
• Question Everything – put special focus on our deepest held beliefs. What we trust most hides our biggest problems.
• “Working Software” is software that users are actually using. Until it’s in use it is truly useless.
• Stress at work diminishes value. Crunch-time is a symptom of harmful and counter-productive attitudes.
• We are the innovators of our process. Learn what works for others, prove it for our self, innovate beyond.
• The object isn’t to make great software, it’s to be in that wonderful state which makes great software inevitable – Henri
• The more we work at the work we do, the less capable we become -Repenning/Sterman – Make time for improving capability
• The unspoken Agile Maxim – I reserve the right to add, remove, change, improve.

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.

Estimating Software Development

Anyone who knows me will know that the title of this post is meant as a bit of 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 not living up to their “commitments”).

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 the developers for not “understanding the requirements”, 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? Well, I don’t think it’s fine, of course – but many organizations seem to operate this way.

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 to do a meaningful estimate.  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 estimate.

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** of this sort 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, if there are better ways.  There are better ways.

Almost everyone tells me that estimates** are very important, but estimates are often 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** of this sort are based on guesses about the time needed to do work we don’t yet understand.  Nothing about this gives me confidence that these 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, 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.

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 developers
• Get rid of all upper management.
• 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 they going to fire you for questioning things like estimates? Are they open to scrutinizing the status quo or to examining why we do the things we do?

So what might be better?

What can we do instead of doing estimates?

Nothing.  Don’t do estimates.  Simple, clean, easy.  But that is not the question we should be asking, and that is not what I am suggesting.

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.

** For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many projects where a list of features or functions are described and people are asked to come up with an approximate cost in time (working time or elapsed time) [sometimes it is phrased as “cost”, or “effort”] to do the work that will be required to provide the feature(s)/function(s)/capability(ies) 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 meaningful or useful.

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.