Life, Liberty, and the Pursuit of Agility

Cory House ( blog  , twitter) wrote a comment on my Estimate Chess post, and I’d like to double purpose it by turning it into a post.

First – thanks for reading my post, Cory, and for making comments.  I appreciate that very much!!!

Cory’s Comment

I can appreciate the feeling of fruitlessness in some estimates. It’s hard to get right, particularly when requirements are weak. However, I believe a professional developer must be willing to take the risk and do the hard work of estimating when requested. Drawing a hard line of “no estimating” without considering context doesn’t come across professional or accommodating.

Your chess example is entertaining, but it’s also a great example of a place where I feel it’s unfair to expect an estimate. Given, it’s gray exactly how your story would translate to the development world, but it seems to describe a request to estimate a project without even vaguely reasonable requirements. I think we all agree that’s a waste of time.

If given sufficient requirements, we, as professionals, should be able to estimate our work. The world expects no less from engineers in other fields. Multiple contractors recently estimated the cost to finish my basement despite the fact that I had no floor plan, no idea where lights would be, only a vague idea on what word work I’d like, a bathroom of unknown size and quality, etc. If one of them refused to provide an estimate, I’d have gone elsewhere.

I land plenty of dev work on contract because I’ve gotten good at asking the right questions and sniffing out complexity so that I can provide reasonable estimates. Being skilled in estimation sets you apart whether you’re independent or full-time. Steve McConnell wrote an excellent book on the subject. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351   That said, while I disagree with your answer to “What can we do?” as “Nothing.”, I enjoyed reading your blog. It’s fun reading and certainly food for thought.

My Response:

Hello Cory! Thanks for commenting on my post!

Well, as you can guess, I don’t agree with your take on things – but that’s why I have a blog, and you have a blog. We all get to write about things as we see them.

Regarding professionalism: I believe it is professional to find a better way to do all the things we do, and eliminate things that are wasteful. I see estimates and the estimating process as mostly waste, and as a professional I see no need to “take on the hard work of estimating when requested”. More directly: estimating is not hard to do, in my opinion. I’m not clear on why you might think it is. However, I also believe that estimates as used in software development typically (and almost always) result in misinformation that is used to make bad decisions. Which is why I follow an Agile approach to development. The Agile approach, at least as I do it, provides a lot of value and eliminates a lot of waste. And that is very professional. We’ll just have to agree to disagree on our thinking about professionalism and estimates.

I don’t think I made it clear in the post: The Chess analogy is to show that something as simple as Chess becomes complicated quickly. It is a VERY SIMPLE GAME, with very few variables, and yet it becomes too difficult to predict when we add a few simple constraints. And even without those constraints, there is little we can predict. Otherwise we wouldn’t even play the game, right? Remember: Don’t stretch an analogy too far – it will always break. With software projects, anything that is non-trivial is much more complicated than the simple chess example.

Cory: “If given sufficient requirements, we, as professionals, should be able to estimate our work”.

My Response: This is where we really diverge. I see estimates as waste, in the Lean sense of the word, and most other ways. Estimates are not part of what the customer buys. They don’t add value to the product. In a value stream map estimates are on the “non-value” track. They are merely ONE WAY people have attempted to be able to arrange working relationships and get software created. It makes sense, and it partly works – still, there is nothing about them that makes them necessary, or even beneficial to the actual creation of software. We can write software without them. We can do whole projects without them. And if we can find a way to make BETTER SOFTWARE at less cost, and to more quickly get the right software into use without estimates, wouldn’t it be professional and worthwhile to at least consider doing it that way? Hopefully we can agree on that.

Cory: “The world expects no less from engineers in other fields. Multiple contractors recently estimated the cost to finish my basement despite the fact that I had no floor plan, no idea where lights would be, only a vague idea on what word work I’d like, a bathroom of unknown size and quality, etc. If one of them refused to provide an estimate, I’d have gone elsewhere.”

My Response: Here we continue to think differently. There are countless examples in life where estimates work to some degree. We’ll discuss that some other day – most, if not all of them are NOT useful as models for software development. Here is where I’d like to leave it for the moment: If you could have had the work done on your basement for less money and get higher quality, and perhaps get it done even quicker – would you be willing to consider doing that? I know that there would be no way to know it was cheaper if you had no estimates – but conceptually: If you could get all the benefits I describe would you consider learning to do business that way? I hope we can agree that would be better all other things being equal.

We have contracts, and estimates, and predictions, and all the trappings of doing business this way because most people haven’t found a way to do things better – we fail each other, we don’t deliver as expected, we don’t trust each other, so we find ways to do business that gives us a chance to do business. So… we can try to get good at estimates, and it if serves you and your customers, more power to you.

Lastly:

Cory: “That said, while I disagree with your answer to “What can we do?” as “Nothing.”, I enjoyed reading your blog. It’s fun reading and certainly food for thought.”

My Response: I didn’t ask “What can we do?”. I asked “What can we do instead of doing estimates?”, and the answer was simply put as “Nothing”. My point being that we do not need to do anything “instead” – estimates are often simply UNNEEDED. And then I posed the more meaningful question: “How can we develop software without doing estimates?”. The nuances of this are important, and perhaps I was being too cryptic. At the time I wrote this post it seemed few were willing to explore these things. I hope I was wrong, and now I am certainly finding more people willing to entertain and even experiment with finding better ways. And some doing purely “no estimate” projects.

Overall, I have found the Agile way works well. When you have customers who see the benefits and find it works better for them than the old phased, predictive approach – then it is truly sweet.

Thanks for your kind words. I try to be fun, and I’m “all about” food for thought!!!

Cheers!

I’ve done 12+ sessions at Agile and Developer “user groups”, Agile or Dev conferences, college classes, and code camps where the main topic (or a big component) of the session was Estimates in Software Development.

Here are the notes from one such session I facilitated last year at an Open Space event (Agile Open California, North)

Session Title: Estimates – Can’t Live With Them, Can We Live Without Them?

The title was my own.  I’ve been talking about, and holding sessions on this subject for several years, and the previous time I was at this event a couple years earlier I did a session on “5 Whys on Why we Estimate”.  It was a very contentious session, with almost everyone (except me) feeling estimates are important and needed for software development, and the problem is just that we’re no good at it… so we just need to get better at doing estimates.  I don’t agree (as you probably know).

The “we just need to get better at it” argument sounds a lot like what I used to hear in “post-mortem” and “lessons learned” sessions in waterfall/phased project environments. A typical “take-away” from those sessions were things like this: “We missed our deadlines and had a lot of rework because the requirents kept changing, even though we have a change control process in place.  We need to get better at controlling changes to requirements”.  I hope you see that is very likely a bad conclusion.  Essentially, that line of thinking is that “since control isn’t working, we need more control.”

I’ve been suggesting that if we keep failing at getting good at estimates even though we are working hard at becoming better at doing so (and have been doing so for countless years), then maybe we are expecting estimates to do something for us that just can’t be done.   Maybe there are better ways.  [Just to be clear, for me – I feel I have found a much better way and it is Agile Software Developent as presented in the Agile Manifesto (Values and Principles) – the Agile MVP.]

My position: We need to get to the bottom of what it is we want from estimates and predictions, and find a better way to get to what we really want. [HINT: What we reallly want is Sucessful Software Development Efforts (or something like that, perhaps?) .  Or, as long as we are wishing, let’s just wish to win the Mega Lottery and then spend our day’s doing something we really enjoy. Like taking hikes or arguing – whatever you like.]

Participants:

There were initially 17 participants.  Developers, ScrumMasters, Agile Coaches, Product Managers, etc.  Almost everyone had some experience with Agile/Scrum/XP/Lean.  A few people joined in as the session proceeded, and a few others left.

Purpose:

Explore and discuss what we want out of estimates and the problems we’re having with estimates.

[NOTE: Everything will be tainted because Woody Zuill is facilitating this session, and he leans slightly toward the “No Estimates” approach.]

Process:

My approach for this session: Quickly explain my basic thoughts about the failure of estimates and the purpose of the session, do an information gathering exercise.  Ask why we feel we need estimates, have the participants write their thoughts on sticky notes, group them, and then discuss.

Information Gathering: Why do we “need” estimates

• We gathered sticky notes to identify “why we ‘need’ estimates and put them on easel sheets
• We then gathered the notes into groupings.
• There were 2 main groupings: Estimates are for planning, and estimates are for manipulating
• NOTE: Tne notes below were written by the participants.  Some are a bit cryptic. Not to worry, okay?

• Here are the notes and the groupings:

Affinity Group: Estimates are for Planning

• How many resources do we allocate to do the work
• Length of engagement
• Costs
• To Predict Future Velocity
• You need estimates to determine budget
• To determine when we’ll finish
• Target implementation time-frame & duration for resource allocation & cost estimates
• When to commit to customer delivery
• to decide whether or not to do a task
• To Determine when a feature will be available
• To determine when we’ll finish
• To know when it is done
• It drives the business
• So we can prioritize
• Business needs it for planning
• Request funds for work
• To help balance the work
• Helps in managing resources
• Determine if end result is worth the cost
• To give the customer prediction – to meet customer expectations
• CEO needs it.

Affinity Group: “Gaming” or manipulating the system and related stuff / dysfunctions

• NOTE: I am not discussing these things in this post – sometime soon I’ll cover this stuff in detail.
• The keep your job
• To give a reason to yell at someone
• It’s “How we do things”
• Habit
• Need to get a programmer fired (setting her up for failure)
• To cover your own ass as a developer
• To pit people/teams against each other

Now for the discussion

After our gathering and grouping exercise, we began discussing what we felt this showed us.  During the discussion we just “followed the flow” as ideas were expressed.

We observed, as a group, that estimates are mostly for planning and making decisions about what to work on.

In the discussion, we were in alignment that we “need” estimates so we can plan our work, and so we can make decisions about which projects or features to work on.

After all the effort we put into estimating, we still rarely get things done “on schedule” and “within budget”.

Also, we still frequently ask (or our managers ask): “Are we there yet?”.

Why do we have these problems?  We’ve been doing estimates for years – shouldn’t we be great at it by now? Other similar or related things that we’ve seen:

• Progress isn’t visible
• We seem to be get more behind our schedule no matter what we do
• Money is running out and important things are not even close to being done.
• Stuff we thought was done turns out to not be.

Rarely are the estimates accurate enough to really count on for release dates, costs, etc.

How do we typically deal with “over budget” and “not on schedule” issues?

• We end up cutting features
• Pushing out deadlines and so on
• Hire more people
• Blaming each other about whose “fault” it is
• Agreeing to get “better” at gathering requirements and doing estimates “next time”

Still, others are dependent on estimates such as marketing, HR, Ops, our customers… and so on

• Do estimates really provide sufficient information for these folks to get real value?
• Or… are there a lot of decisions made based on faulty estimates???

So, With all these problems, why aren’t we looking for a better approach? What is wrong with our estimating process? Should we try to get better at it, or… ?”

One reason estimates provide little chance for usefulness:

• The Unknowns might invalidate any estimate we make – estimates by nature contain unknowns
• What is 4 x 8 + 7  / 2 * 83 + unknown?
  • The answer UNKNOWN
  • We can guess, or base our UNKNOWN on similar things.  Might work. Might not.
• Many important decisions are based on UNKNOWN, but we act as if we “KNOW” something
• The argument is often made that we just need to “have some relative estimate…”
  • It is likely that even this leads to bad decisions
  • For example, what good is relative decision based on “This UNKNOWN is bigger than that UNKNOWN?”

MY CONCLUSION AS PRESENTED:

So, if the Estimating process is flawed (and it might be), and getting “better at it” hasn’t worked… Do we really need estimates?  Can we innovate a better way?

• What I am suggesting is that we have to evaluate our dependence on estimates
• My own experiences have proven to me that estimates are not always needed.
  • I’ve been working without estimates for over 3 years with good results in corporate, “internal” projects
  • I’ve had several long term ongoing projects that did not use (or need) estimates – One of over 4 years on commercial software
  • I’ve done contract work with NO ESTIMATES. Many have told me “customers won’t do that”, but there are at least some that will.
    • When a customer sees that more “real” work gets done and more of the right thing gets done with less “busy work” they get on board.
    • Finding ways to pay a very low cost to prove something works, or doesn’t work is very attractive to most customers.  To me, this is a fundamental benefit of an Agile approach.
• My experiences are not proof that estimates are not needed.
  • I am not trying to change the world.  I do want MY jobs/contracts/customers to get the benefit of doing things in a better way.
  • I AM trying to invite conversation about this stuff, and encourage us to explore and replace these painful practices in our profession.

This discussion had more to do with posing the questions than answering them

• It is contextual (as usual)
• Lots of organizations feel they need estimates and you must work within the system.  Sorry for that – but I can’t fix that.
• Often, customers will not entertain using a company that does not provide an estimate.
  • They want to know what they’ll get, when they’ll get it, and how much it will cost.
  • It is a risky situation for everyone – and if you are in that world, there are still ways “sell” the benefits of finding a better way.
• I am suggesting is that we need to do some serious thinking about how to change this reality, and innovate ways to eliminate the dependence on estimates

I am proposing that we need to imagine a different world

• Do some “thought” experiments
  • IMAGINE:
    • What if we were to find that estimates have NO value (zero benefit), should we still do them?
      • What would that look like?
    • What if we were to find that estimates are harmful and are counter-productive?
      • What would you do?
    • What if the were to find out that estimates are fatally TOXIC
      • What would we do then?  How fast would we need to address this?

Take some action that will expose the reality about our estimates

• Can we find a way to wean ourselves from estimate dependency?
• A few things that have worked for me
  • Deliver value quickly and frequently (sound familiar?) – that is: put small chunks into real use early and often
    • Making decisions about “what to do” become less important when we can do “some of this” then “some of that” and see what works (or doesn’t work) quickly and cheaply.
    • People stop worrying about “are we there yet” when interesting (useful) things are continuously happening and being put into real use by real users.
      • It’s like bringing along some new toys and activities to hand to your kids on long trips when they start getting antsy.
  • Lead your customer/stakeholders/whatever to an understanding of what is important to deliver NEXT…
    • … we only have so much work that can be done right now – focus on that
    • … put all your effort into that
    • … and put little time on all else
  • You can introduce this a little at a time.
    • Thinking people who are open to this will slowly come around.  Or not.  Just depends.

Remember: I am just encouraging discussion.

What works for me might not make sense to you.  Maybe someday it will.  When that happens, you will have crossed over into the land of no estimates.  Beware.

In this episode I’ll cover an extremely satisfying application of Lean and Agile on a large ‘Legacy’ effort I was part of a while back.

Please understand that I am not at liberty to discuss certain (that is, most) details. I must protect the guilty. I will give just the bare details – only what is necessary. I bet you don’t believe I will be able to give just the bare details, right?

So – this is about using the No Estimate Approach on an End-Of-Life Legacy Support project.

First, a few definitions:

What is “Legacy” code?

I am glad you asked.  There are many definitions of legacy code. Here is the one I use: Legacy code is ANY CODE THAT IS DOING ACTUAL WORK THAT YOU WANT TO KEEP WORKING. (Please note the clever use of “all caps” for emphasis.)  Does that make sense to you? Doesn’t matter – just pretend that is what it means.  Using my definition, most projects become legacy code as soon as you have some functionality in production. That’s when the bits hit the fan, usually, so to speak.  However, even if it isn’t yet in production, it could still be “legacy” if we have stuff working we don’t want to break.

What is Legacy Support?

Regardless of what you think legacy support is, for the purposes of this post I am using it to mean this: “Work done (bug fixes and minor enhancements – that sort of thing, or more serious stuff if needed) to extend and protect the life of code that is in use”.   I’m leaving out more extensive enhancements like “whole, new functionality”.  You can judge for yourself the difference between minor and “more extensive” enhancements.  Doesn’t really matter to me.

What is End-Of-Life?

For the purposes of this post, an End-Of-Life project is a project that is almost retired.  It’s still in use but going to be replaced sometime soon.   In software programming “Soon” means “perhaps sometime, but we have no clue when.”  The basic idea is that people are using it, and it is important enough to keep supporting, but we’ll stop doing big additions and improvements.  Some bugs will just be ignored, but any deemed to be important to fix will be fixed if possible.

Project History and Details

The project that we are discussing is is a large, line-of-business set of applications (‘The System’) that is critical to the users of the software for managing most aspects of their business.  The typical user of The System manages thousands to millions of their own customers – sales, billing, transactions of all sorts, bunches of “real-time” stuff, reporting, etc.  Typical line-of-business stuff.  I was told the code base was about 2 million lines of code [and that’s about enough, in my opinion – any more is just bragging.]

The System has been in production for 15 years or so and has moved through several different code bases.  The current code base is about 4 or 5 years old.  It uses several languages – 4 or 5 perhaps.  Typical stuff.

Enhancements and bug fixes are managed, worked on, and delivered using a waterfall approach, with a 3 month delivery schedule (that takes 6 months due to test and fix cycle, and other typical deadline issues).

Due to design, industry, and technical reasons it is deemed necessary to re-write The System in a new language with a new architecture.

The Path Going Forward

The current version of The System MUST continue to serve the user base, and even more – it has to be clear that we are still responsive to concerns and issues of the user base so they don’t start looking to competitors to solve problems while the “greenfield” version of The System is being developed.  It has to look and feel like “business as usual, only better”.

A “maintenance team” is put together to provide this service.

I’m not sure exactly how many people were working on The System before the End-Of-Life Maintenance, but it was something on the order of 20 to 25 people – maybe more, it was a while back and I didn’t keep track.

The new team was to be 6 people: 2 QA, 2 BA (Business analyst or “Product Owner”), 2 Dev.  I was one of the two Devs, and also the manager, or co-manager (more or less).  I “volunteered” for this assignment on one condition: I would be allowed to manage this effort my way – which means Lean/Agile/XP.

We’ll call this System EOL (for system end-of-life) .

The State of System EOL  on Day One

There are approximately 500 active bugs in the bug tracking system.  Some of these bugs have been pernicious. Some have never been addressed due to level, some have been introduced in the fixing of other bugs, some have been there a long time but just recently discovered – All the typical bug stuff.

500 Acitve Bugs???!

There are 500 active bugs! There are a number of reasons there are so many bugs.  Before we talk about that, I’d like to ask a question.

• Question: What is an appropriate number of known bugs for a project that is in production?
• Answer: Zero.

Got that? I’ll allow for any bugs that have easy work-arounds – you can leave those if you have to.  I’ll also allow for any bugs that were discovered since the last deployment.  But you better fix those NOW and then you’ll have zero bugs once again. Nice.

Remember that: Zero bugs.  Does that seem unreasonable to you? If it does, I’ll ask another question: Why bother reading my blog? Go do something else that seems reasonable to you.  Why waste your time on what I’ve got to say? I am NOT REASONABLE most of the time.  I want a better way to do stuff than whatever we used to think is “reasonable”.  Zero bugs is a “lofty goal” in some workplaces.  In others, it is business as usual. I prefer zero bugs.

So, 500 bugs is not just way too many, it is infinitely too many.  Or whatever 500 divided by zero is.  Anyone know?

One reason there are so many bugs: The old process.

There were several reasons all these bugs existed, but the one that is most pertinent to our discussion today is the process that was in place for assessing and fixing bugs. The way things were being done was about like this:

• Bug report is entered into the tracking system by a user, support person, developer
• The bug is reviewed at a “triage” meeting where its importance determined
• If it is important enough, it is assigned to an “investigator” who will assess it: that is, attempt to reproduce it, determine the likely cause and module that will probably contains the “bad code”,  and estimates the time to fix.
• After the assesment, the bug goes back to a “bug review” meeting to re-assess it’s importance and schedule the work to be done.
• If it is deemed important enought, it is scheduled to be fixed (either sooner or later based on the “cost” of fixing it and importance to the customers).  If it is not important enough, it is closed and it’s status and other details are communicated to the interested parties.
• It is assigned to a developer who works in the area of the “bad code”. Since the developer is a different person than the investigator, the developer starts from square one and “re-thinks” the stuff the investigator already thought about.
• In working on the bug, the developer discovers the problem is NOT in the area of code it was thought to be in, so he adds his comments and assigns it back to the bug review team.
• The bug review team looks at it again, and then re-assigns it to an investigator.
• And so on and so on…
• Once a bug is actually fixed, it goes thorugh QA where it is discovered that it didn’t fix what needed to be fixed.
• Go through whole process again.
• Once a bug is fixed and passes QA, it is deployed in the next deployment, and…
• The users discover that it didn’t fix what needed to be fixed, or the fix was only partial, or that something else is now broken.
• Even worse – some other things have been broken that are not yet discovered that will lead to other bug reports sometime soon.

Okay – you get the point.  I am not making this up.

There were other reasons System EOL was in this state, which included lack of unit tests, code neglect (huge methods, overwhelming complexity, fragility, coupling and cohesion problems), and so on… but we’ll solve one thing at a time.

Chutes and Ladders

Well.  Does that remind you of that game you used to play when you were a kid?  It should.  And it is JUST AS FRUSTRATING, at least conceptually.  Only difference is you get paid to play Bug Fixing Chutes and Ladders.  But overall – it is terrible and horrendous (and other bad words).

What to do???

Since I was allowed to manage System EOL in my own way – Here is what we did.

Value Stream Map

First day I brought in 6 copies of Mary and Tom Poppendiecks “Lean Software Development” book, and we all agreed to read it, and more or less follow their basic concept.  I’d been doing XP for years (more or less) but it’s a hard sell so I opted for the “easy sell”.  If Lean is good enough for Toyota, it’s good enough for me.

First thing we did was a value stream map on the  “Chutes and Ladders” methodolgy that was in use. If you haven’t seen a value stream map or know how to do one, take a look at Mary and Tom Poppendiecks “Lean Software Development” book.  The basic idea is that anything that is not directly adding value can (and should) be eliminated. For example: waiting in queues is a waste – it brings no value to the person interested in having the bug fixed.

I bet you can guess that we found a lot of NON-VALUE-ADDING behaviors.  So, we made a few rules.  For example…

First of all, a few rules:

• No Triage meetings or Bug Review meetings
• No Assesments for “where the code is broken”
• No prioritization or severity determination (a bug is a bug is a bug).  If it’s in the tracking system, fix it.
• No Estimation of effort. We gotta work on all the bugs.
• … and Other things

NOTE: No Estimates, No prioritization, No meetings.  These are wastes (at least in some situations, if not a lot) – bringing no value to the “customer”. Even worse,  waste usually removes value by using up time and “spirit”.  A team doing a lot of meetings, estimates, assessments, meetings, prioritization, meetings, waiting, etc. becomes NUMB. Avoid numbness.

An initial assessment:

We quickly read each bug in the tracking system, looking for duplicates, bugs no one had asked about in a year or more, and bugs where the description could not be understood (and there was no one who could clarify). This was done very quickly and eliminated about one half of the bugs.  NICE. 500 bugs cut down to 250 bugs.  No one can say that is not progress!

This took about a week (as I recall).  During this “first-week” the developers and QA took on bugs to fix, since there were plenty that were clear enough to work on – but spent some of their time helping the BA’s “weed out” the bugs that we removed.

Daily process we adopted:

• Daily morning 1/2 hour meeting.  Sitting. Quickly talk about some interesting things (movies we had seen, a great lunch place we found, etc) , and occasionally some work stuff as well.  Seriously – this was a time for the team to become comfortable with each other and build some common memories and start the day off on a pleasant note.  And everyone outside the team expected we’d do daily meetings and we didn’t want to disappoint them.
• Pick a bug, any bug.
• QA and Dev sit together and reproduce bug. Confer with BA as needed.
• QA and Dev examine code together, and create a characterization test to “clamp down” the code.
• Dev fixes code using TDD whenever possible, conferring with and pairing with QA and BA whenever needed
• QA and Dev test code to verify fix works as expected
• QA and Dev run all existing characterization tests
• Code is checked in and project is built
• QA runs all existing automated UA tests and any needed manual tests.
• Pick next bug – preferable one that is in some way related to last bug – but not critical. Just pick one, and repeat.

Release Schedule:

• About every two weeks a build of whatever was fixed at that point was made avaliable to customers.
• They could take the build if any bugs they were interested in were fixed, or they could ignore it.  It was up to them.

End Result:

Guess how long it took to clean this project of  bugs.  Give up?  3 months!

250 bugs in 3 months – that’s about 4 bugs a day!!! Well, we did have 17 “un-fixable” bugs.  Those were bugs that we weren’t allowed to fix for some business reason.  So still – an average of just under 4 bugs a day.

This is the power of eliminating waste.  All of our time was spent doing meaningful work, REAL WORK on bugs. No reviewing, no estimating, no “pre” investigation that wasn’t part of doing the fix, no passing code to QA that we were not confident would pass all tests, etc. In other words: NO WASTE.  Or at least: We were no longer doing any of the steps that we had identified as waste.

A Few Other Interesting Things:

Well, what we found is that in fixing some bugs, we’d incidently fix other bugs.  That is, some bugs were caused by a single underlying malfunction.  That happens, and it is a sweet bonus when it does.

We had no recidivism. Once delivered to the customers, we did not have a single fix that was “sent back”.  Once fixed it stayed fixed.  I think this can mostly be attributed to the QA and Dev working together, the unit tests put in place, and the “one-at-a-time” approach to “fix and build.” We would fix ONE BUG at a time. Fix,  Build, Unit Tests, Checked in, Built, Tested, confirmed.  Only then would next bug be tackled.

Conclusion

So… this is about no estimates.  Our rule: Eliminate waste.  In this case, estimates were a waste.  They were thought to provide a way to “manage” the work being done, but were in fact reducing the ability of the organization to “manage” getting work done.  I think they are like the dice in chutes and ladders? Probably not. Still, focus on the real work, don’t muddle things by playing chutes and ladders.

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.

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.

[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’ »

One set of problems I have often seen with “the Waterfall” are the Communications Problems, particularly the over-reliance on communication by documents. 

Communication-By-Documentation (CBD) – What’s so bad about that?

It seems so correct and natural to use documents to capture and communicate all the details of what we are working on that it is almost unthinkable to question this practice.  But I am going to try.

The sort of documentation I am discussing here are requirement docs, graphs, ER diagrams, models of all sorts, analysis docs, architectural diagrams, and etc.  (There is a lot of etc., by the way. )  I am not saying that documentation is not needed, or that it is not useful, it is just that we have to be careful to protect our project from the problems that these documents bring with them.   Continue reading ‘Communication Problems with the Waterfall’ »

There are a number of blog posts, books, and articles that discuss the idea of “Technical Debt” in a software project. One good (and short) article on the subject is Technical Debt at Martin Fowlers bliki. (He attributes Ward Cunningham with coining the term in 1992, so this is nothing new). I’ve also heard various presentations at conferences and developer group meetings that covered this idea as well, and I find it useful as a way to think about a harmful practice that is prevalent in software development.

Here is my attempt at a description of Technical Debt:

Technical Debt is the accumulation of bad code and design that degrades the quality of a project in such a way that it is harder to maintain, enhance, and support. (That is, the code has become more rigid, fragile, opaque, and so on – which are design smells as presented by Robert Martin in his Agile Principles, Patterns, and Practices books.) Continue reading ‘Another metaphor for Technical Debt: Deferred Maintenance’ »