Agile Retrospectives Workshop With Diana Larsen

Advanced Practices for Leading Agile Retrospectives: New Techniques and Activities

with Diana Larsen

When: Thursday, March 6, 2014 from 9:00 AM to 4:00 PM (PST)

Where: Marina Village, San Diego, CA

Visit the Eventbrite page for this event at

Spend an entire day with Diana Larsen exploring, learning, and practicing Advanced Practices for Leading Agile Retrospectives.  Agile Retrospectives improve any project or process — building on a team’s immediate past experience of success and failure. Smart teams and organizations hold Retrospective meetings iteratively, throughout the work cycle and at important release milestones.

In this workshop, Diana Larsen will introduce advanced uses of the Flexible Framework for Retrospectives and show how to incorporate the Five Rules for Team Learning in your Retrospective designs. Participants will share new team activities to enlarge your repertoire and gain practice in designing and facilitating effective Agile Retrospectives.

The Day:

  1. Introductions – including practice with new activities to “Set the Stage”
  2. Agile Retrospective Purpose & Group Learning, Thinking, and Collaborating on Improvement Actions
  3. Applying Five Rules for Learning in Retrospectives
  4. Explore and practice new activities to “”Gather Data”, Generate Insights”, “Decide What to Do”, and “Close the Retrospective”
  5. Retrospectives as Adaptive Action for “Responding to Change”
  6. Designing Agile Retrospectives for Continuous Learning and Improvement
  7. Next Steps

Our Facilitator, Diana Larson: 

Diana is a founding partner of FutureWorks Consulting. She is considered an international authority in the areas of Agile software development, team leadership, and Agile transitions.  She co-authored “Agile Retrospectives: Making Good Teams Great”; “Liftoff: Launching Agile Teams and Projects”; “Quickstart Guide to Five Rules for Accelerated Learning”; and most recently the Path Through Agile Fluency model, described in the article, “Your Path Through Agile Fluency: A Brief Guide to Success with Agile” at

Tickets Available on Eventbrite: 

We are keeping the price for this event as low as we possibly can.  You can attend for only $99 for a “Bring your own lunch” ticket, or $114 and we’ll provide a Box Lunch.  Also, we have set up a “5 for the price of 4” discount if you have a group from your company who would like to attend. 

Visit the Eventbrite page for this event at

NoEstimates at Oredev 2013

By Woody Zuill

I was invited to present my ideas about “No Estimates” at Oredev 2013 in Malmo, Sweden.  It was an exciting and wonderful experience for me (to say the least), and perhaps someday soon I’ll post more about it.

Until then, here is a link to a video of the session I presented there about #NoEstimates:

NoEstimates at Oredev 2013

Please let me know what you think, if you would.

The NoEstimates Hashtag

In Twitter, we use the convention of “hashtags” to connect a tweet with a theme or topic so that it is easy (or at least a bit easier) to search and find tweets for topics we want to follow.

Several people have blamed me for coining the “#NoEstimates” hashtag.  It might be true – I’m not sure.  It is possible that I was the first to use this hashtag for Software Development – a search of Twitter history on it shows that, as far as I can tell.

[UPDATE: I found the following post from Aslak Hellesøy – @aslak_hellesoy dated Feb 10, 2010 that used this hashtag

@obie at #speakerconf: “Velocity is important for budgeting”. Disagree. Measuring cycle time is a richer metric. #kanban #noestimates.]

SO… What is the Topic of the #NoEstimates Hashtag?

Here it is, as defined by me.  Others probably have their own idea:

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development.  That is, ways to make decisions with “No Estimates”. 

I’ll probably modify this a bit over time – I put this together quickly as a starting point.

Also, A Word About Estimates

Estimates are typically and pervasively used in the decision-making process throughout software development organizations and efforts – both in “phased/waterfall” and “Agile” methodologies.  They are ubiquitous – it is rare to find a project/organization/effort where it isn’t simply accepted that “we must have estimates – it is the only way”.

Additionally, for a long time I’ve been noticing that almost every training, book, conference session, article, or blog on “Agile” software development has a very heavy focus on estimating.  I’m fine with important things taking a lot of our attention – they are important, after all. Are estimates that important?

I’ve also noticed over the years that many organizations have a number of dysfunctions in how estimates are handled, and the overall decision making process that depends on estimates.  Have you noticed any dysfunctions?

So… I started doing “5 why sessions” or similar exercises at conferences and user groups, and other investigations into the reasons for this, and the dysfunctions that people have been experiencing.  I also started discussing alternative ways to manage software development efforts without using estimates. I’ve been working without estimates for years for many decisions that are typically “estimate-driven”  in software development management, and some people are interested in how to do this.

It’s important to ask ourselves questions such as: Do we really need estimates? Are they really that important?  Are there options? Are there other ways to do things? Are there BETTER ways to do thing?

If we are willing to simply play the “devil’s advocate”, and imagine (or at least temporarily pretend) that perhaps there are better ways to make decisions, it can lead to more open thinking and clarity as to why we “believe the things we believe”.  Why not question the things we hold so dearly?

There ya go!  Have Fun!



My Customers Need Estimates, What Do I do?

It seems a lot of people have an argument against the “No Estimates” idea that goes something like this:

“Our Customers Need Estimates*”

There are many variations on this, but they typically come down to the same thing: We need customers, customers need estimates, therefore, we do estimates. The following are a few generic examples of this idea:

  • No customer will agree to hire us to write custom software for them unless we give them an “estimate”.
  • The reality of business is that we must give estimates to our customers so we can get work.
  • We must be good at estimates because our competitors are giving estimates.
  • The customer want’s to know if we can do their work at a price they can afford
  • The customer needs to know if they can make a profit based on the amount their software will cost, so they need an estimate.

How Can I Get These Customers Without Estimates?

This is a very easy question to answer: You probably can’t get these customers without estimates.  They want estimates – it’s part of the way they think. You probably MUST DO ESTIMATES for these customers.  That is, you don’t tell these customers “We don’t do estimates” if you want to work with them.

If you have chosen to work with the sort of customer that requires an estimate (or price) then give them what they want: an estimate (or price).  Your main job is to figure out a way to be able to make money taking on work for this sort of customer.  I understand that. You understand that. What more do you need to know?

A few points you might want to consider:

  • Are you willing to give an estimate/price for free?
  • Who pays for the estimates for jobs you don’t get?
  • How much extra do you need to “pad” the work for the “unknows”? Why should your customer pay for that?
  • Are you going to give a range?: “It will cost you no less than this but no more than that”.  Will you guarantee that?
  • If it costs you more to make the software than you estimated, are you willing to take the loss? Why??? If not, how will you deal with that? Re-negotiate the contract?
  • How do you know enough about the work to be able to give a resonably accurate price/estimate?
  • If a competitor shows them a better way, will they ever come back to you again?
  • That’s just a start – I’m sure we can come up with a lot of other things to consider.

If you choose to work following the “we must do estimates” model you are in good company (or at least in very numerous company), as there seems to be many who feel this is a reasonable way (or the only way they’ve found, perhaps?) to do business.

The Agile Way

I recently heard Jeff Sutherland do a talk where he mentioned the “80/20” rule – that “80 percent of the value is in 20 percent of the features” of a software project.  He quoted someone (I don’t remember who) as having suggested “we should just fund the 20% and not do the rest”.  I agree.  I’ll take it a bit further: I believe that the rule is more like “95/5” – that is: 95% of the value is in about 5% of the features, and that the people paying for the project will quickly end the project once that 5% is in use. Perhaps our goal is to pay as little as we can to discover and create that 5%.  So… how to do that?

Some choose the Agile way.  In this model, we recognize that “requirements emerge”.  If we can get good at allowing the more important and useful requirements to naturally emerge it pays off very nicely.

What does this have to do with estimates?  If I have to tell you, then you probably should be reading someone else’s blog.  But here it is: A customer who needs to “know how much it will cost” before they will decide to hire you to do the project might not be the sort who is willing to let requirements emerge.   It’s just not their way of thinking.  You might be able to “change them”, but probably not.

Not All Customers Require an Estimate (or price)

What it comes down to is this: You get to choose who you do business with.  If you choose to serve customers who need an estimate/price, then do estimates/prices, and figure out how to make that work for you.  If you choose to serve customers who are willing to let requirements emerge, then get good at the Agile way, and go for those customers.  It’s your choice.

Some of my other posts on estimates and “no estimates”


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

Agile2013 Lightning Talk: NoEstimates

NOTE: This was a lightning talk proposal for Agile 2013 in Nashville.  My main purpose in this post was to have a chance to give a lightning talk on “No Estimates” at that conference.  An additional purpose is to encourage people to be thinking about the sort of estimates we use in software development, why we think they are useful, why we depend on them so heavily, and some of the reasons we might want to re-think our dependence on estimates.

Fortunately for me, I was chosen to present this lightning talk, which challenged me to put together a focused slide deck and talk on the subject, which then grew into the talk which I gave at Oredev 2013.

Going forward, my is goal to expose the sort of thinking and questioning I have been doing over the last 10+ years so that others who have been asking can use these questions as a starting point in their own exploration of estimate-driven software development.

I am not offering to answer these questions for you.  Only you can do that.

I want to emphasize this: If you want to discuss these ideas with me, I am always happy to talk with almost anyone – either via Skype, or at a conference or developer meetup.  If you demand that I answer these questions for you, then you have misunderstood the purpose of this question list.  Again: I am not offering to answer these questions for you. I am offering these questions as a starting point for your own journey of exploration and learning.  I encourage you to use them.

Now: the original post:

I’m proposing an “idea” to present for the Agile2013 Lightning Talk stage under the Process At Scale theme.

Title: No Estimates

Talk summary: Ask a lot of questions, answer a few.

Please vote for it here: Agile2013 Lightning Talk On No Estimates

Here are the things I have been asking myself about Estimates:

  • What are estimates, anyways?
  • Are estimates useless? wasteful? harmful?
  • Who needs them? Who is asking for them?
  • Why do we think we need them?
  • Can we have successful projects without estimates?
  • When will this be done? How much will it cost?
  • How can we decide if we should do a project without knowing the cost?
  • Is NoEstimates better than MoEstimates?
  • How expensive are useful estimates?
  • How useful are inexpensive estimates?
  • If it takes you “no time” to do estimates, are they of any value?
  • If estimates are waste, would you still do them?
  • Is the reason you do estimates because “someone requires I do estimates”?
  • Why do they require you to do estimates – is it because someone “higher” is asking them for estimates?
  • When someone asks for an estimate, what do you do?
  • When estimates don’t work well for us, should we just get “better at doing estimates”?
  • If estimates are useful and easy to do, why do we still have so many problems with estimates?
  • How would you plan a project if you were NOT allowed to do estimates?
  • Can you imagine any reason why estimates might be harmful?
  • Can you imagine some better way?
  • How important are predictions?
  • Can you “sell” programming without estimates?
  • What about estimating the “value” of a feature?
  • Are there things where estimates make sense?
  • What is “No Estimates” anyway?
  • If estimates are good for some things, does that mean they are good for everything?
  • Does “No Estimates” mean we don’t use estimates at all?
  • What are “Whole Team Estimates” and does it help at all?
  • If you are estimating about work you don’t yet understand to be done by someone you haven’t yet hired, is that meaningful?
  • How much are you willing to invest in estimates to get useful information from them?
  • Does it matter how good estimates are: are “wild guesses” good enough?
  • Are the decisions you are making that are based on estimates good decisions?

We’ll ask some of these questions. Perhaps explore a few ideas. Maybe answer a few.

Stuff like that.

Why do we need estimates?

[NOTE: This post is about software development. You might need estimates in some other field or domain and this article is not related specifically to any other domain, and especially not the one you want to complain about.]

I’d like to do a little investigation about why we need estimates.

The following list contains some of the things people say when I ask “What do you use estimates* for in software development”:

  • To decide if we can do a project affordably enough to make a profit.
  • To decide what work we think we can do during “a Sprint”. (A decision about amount)
  • To decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
  • To decide which is more valuable to us: this story or that story.
  • To decide what project we should do: Project A or Project B.
  • To decide how many developers/people to hire and how fast to “ramp up”.
  • To decide how much money we’ll need to staff a team for a year.
  • To give a price, or an approximate cost so a customer can decide to hire us to do their project.
  • So we can determine the team’s velocity.
  • So marketing can do whatever it is they do that requires they know 6 months in advance exactly what will be in our product.
  • Someone told me to make an estimate, I don’t use them for anything.

That’s enough for a start. So let’s start.

Let’s notice the most obvious common word in that grouping. To me, it is the word “decide”. Granted, the last few items don’t use the word “decide”, but we have to start somewhere. Besides, why would have I contrived that list and highlighted the word “decide” if it wasn’t fundamental to my main point? [At least I’m honest in stating that I have an agenda.  Hint: NO ESTIMATES]

It is significant to me that much of why we do estimates is that we need to make decisions: To decide something.

In other words, it looks to me that what we need are decisions, not estimates. Estimates are often used to help us make decisions. Estimates are not the only way, and for many of the decisions we need to make they are likely not the best way, in my opinion. We can,  and maybe we should explore other ways to make those same decisions. [Who are we kidding, I really think we need to find better ways to make those decisions].

So to restate: We don’t need estimates, we need to make decisions.

Most of us will probably agree that decisions are important and we need to make them, and that we want to make “good” decisions. Great decisions are even better. Yet in many cases, mediocre decisions are sufficient [stay with me here…]

Interestingly, as long as we pay attention, learn from our mistakes, and are willing to make “course corrections” frequently, even bad decisions are often sufficient. In other words, even if we make bad decisions, we can adjust and steer our work (and therefore our results) by making decisions as we go along.  That is an important point. Dwell on it.

Perhaps it would be advantageous to find ways to work where the quality of our decisions are not as important as our ability to learn and to adjust our course while paying as little as possible for the learning, adjusting, and “mistakes”.

To me, this is a “Lean approach” to making software. To me, this is the “Agile way”. Some people used to call this a “light-weight methodology” for developing software to indicate the process was “barely sufficient” rather than “cripplingly  comprehensive and depressingly dysfunctional”. I like “light-weight”, but someone picked the name “Agile” for this idea. I like that word even better. Regardless of the name, it’s an approach where we pay attention to what is going on and constantly adjust things based on what we learn.

One other thing about decisions

Sometimes decisions happen by default: If I forgot to bring my lunch, my options are to go hungry or eat cafeteria food today. If I forgot to bring money, then the “decision” was made for me – I go hungry. I prefer to not go hungry, but in some cases a default decision is sufficient. Make decisions on important things, resort to default decisions on less important things. Besides, I need to lose some weight anyway.

One other other thing about decisions

One little note: Of the items in the “What do you use estimates for in software development” list above, there is only one where estimates seem to make sense to me: To decide how much money we’ll need to staff a team for a year.  I’ll write about that someday if anyone is interested.  But I am confident you can figure it out yourself.  Also, there are only a couple of items in that list that seem like important decisions to me. But what do I know?

One other other other thing

As far as the “team velocity” question goes – you don’t need an estimate for that. To determine the velocity of a team simply drop them from a height of about 2000 feet and you can measure their speed just before they hit the ground.  I’ve never tried that, but I’ve worked some places where it felt like that.

In Conclusion… We need to make decisions, we don’t need estimates.  Did I say that already?

So the title of this post was “Why do we need estimates?”. The answer is, we need them only if we can’t find a better way to make decisions.

There is a lot of stuff we need to decide, which requires that we make decisions. Make many small decisions while you learn, steer, adjust, and correct.

Some other posts I’ve written on the topic of estimating:

Perhaps you are now saying: So what? I don’t know of a better way, so I am going to use estimates. Besides, what’s so bad about estimates?  Well… I’ve written a little about that (although I’ve really just started – there is a LOT of potentially bad stuff about estimates we should all be aware of), and about a few alternatives to using estimates. Over time, I’ll keep adding more information, and share more about how to make decisions without estimates. In the mean-time, I know that many others are also finding ways to make great decisions without estimates, and some of them are writing about it as well.  Google that.  You can probably figure this stuff out better on your own, anyway.


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

My First Job Spoiled Me

This is  a little story about how I learned the right way to manage people

My First Job: Age 13 or 14

Woody WateringWhen I was a kid, if I wanted something (like a slot-car, or a pellet gun), I could wait for my birthday or Christmas and hope my folks could afford to buy it for me, but beyond that it was pretty much up to me.  So I pulled weeds, sold garden seeds door-to-door, sold Christmas and greeting cards door-to-door, sold grapes on the roadside, delivered newspapers as a back up for friends who had paper-routes.  Typical kid stuff for that day.

But those little jobs never brought in much money for the amount of work, so I decided to get a “real” job.

There was a plant nursery about a mile from my home, and they occasionally hired teens to water plants, move stuff, mix soil, plant seedlings into nursery cans, and similar nursery work.  So, to make a long story a bit shorter: I asked for a job, and the owner of the nursery, Mr. Smith (his real name), hired me.  He knew my folks.

Lesson One: Treat everyone nicely

The day I started, the Mr. Smith introduced me to Bill (also his real name).

Mr. Smith: “It’s great to have you join us here.  Bill is going to show you how to water the plants today – it’s not difficult, but there are a few important things you’ll need to know. You won’t have any trouble with it.”

Lesson Two: Continuous Improvement

Mr. Smith: “However, another part of the job is for you to think about what you are doing, and look for better ways to do things.  Keep track of your hours, and next Saturday when I pay you for the week I want you to tell me one way to do things better.  Look for problems, and think about how we could deal with them.  Okay?”

Me: “I’ll do that”

Mr. Smith: “Great! Bill will take you out and show you what you’ll be doing”.

Lesson Three: Give people a sense of the importance of what they do.

Bill: “Hey Woody, I’m glad Mr. Smith hired you. We’ve been too busy to take care of everything and we’ve got a very important job for you. Let me show you.”

We walked out into the nursery, and Bill grabbed a hose with a watering wand attached to the end and handed it to me.

Bill: “You are going to water the plants. It might seem simple, and in some ways it is.  But these plants depend on us for their lives – they can’t get water without us.  We water most of these plants every two days.  Each plant is in a can just large enough to provide the room it needs for it’s roots.  When you water a plant, give it just enough water to wet the roots completely, but no more – we don’t want to waste water.  However, if you give it any less, the plant may possibly dry out too much by the next time we water, and that stresses and weakens the plant.  Got it?”

Lesson Four: Most People Are Smart Enough To Figure Things Out.  Let Them Do That.

Me: “Sounds good.  How do I know what’s enough water?”

Bill: “Well, it’s a bit tricky.  You have to check some of the plants after you’ve watered a row.  Go back and see that a little water is dripping out the holes in the bottom.  That shows you the whole root-ball has gotten some water.  Keep your eyes open.  If some of the plants start wilting a bit – you know you have to adjust your technique.  You’ll figure it out”.

Me: “How do I tell if a plant is wilting?”

Bill: “Each species is a bit different, some need more water, some need less.  It’s just something you get used to over time.  You’ll figure it out.”

And so I did.  I watered the plants.  Hundreds and hundreds of plants. I dragged the hoses around, and I carefully watered each plant.  I also went back to check some of the plants when I got to the end of a row to make sure I was doing things right. I watched for wilting plants.  I was careful to not waste water.  IT WAS GREAT.  I was outdoors all day, I was doing an important job and it gave Mr. Smith and Bill more time to work with customers, pot up plants, make deliveries and so on.

Lesson Five: Make Everyone Welcome, Not Just Feel Welcome, But Truly Welcome

After about 2 hours on the first day, Bill came over to me and said it was time for a break.  A break? This was great!  I get to work, I’m making money, AND I get to take a break.  This was heaven. [Remember, I was just a kid and had no idea what work was actually like – I was just excited to be working]

Bill: “Hey Woody, let’s take a break.  We take about 15 minutes every few hours to get in the shade and have a soda.  Let me show you the soda machine.”

Soda machine?  I had no money with me.  I had no money, period.

We walked over around the back of the nursery to one of those old fashioned refrigerated coin-operated soda bottle vending machines with bottles of soda you pulled from a slot after opening the big, heavy, metal lid.  They had rigged it so you didn’t need coins.  Just pick out the drink you want.  SWEET! And they had Vernors Ginger Ale.  I was living high on the hog!

We sat and talked about plants, and the weather, and how wet you get watering plants. Bill was sincerely welcoming me.  He treated me kindly that day, and every day I worked with him. We were all there to work together, each of us depended on each other, and it was expected we would be polite and respectful in all things. I felt like I was part of the family already.  And that never stopped.

Lesson Six: Trust People

At the end of the week, I went to Mr. Smith to get paid.  I handed him my notebook where I had written my hours for each day.

Mr. Smith: “Well, how was your first week?”

Me: “I loved it”

Mr. Smith: “Thanks for keeping track of your hours. Please add them up, and multiply by $1.25 per hour, and then go get your money out of the cash box under the front counter.  Write down the total on a slip of paper and put it in the bottom of the cash box  – I need it to do the taxes.”

I am not kidding.  Maybe it was a different time back then, but I have a feeling it was much more than that.

Lesson Seven: Give Meaningful Feedback

Well, I got my money and went back to Mr. Smith.

Mr. Smith: “So, how did it go this week?  You getting a feel for the work?”

Me: “It went pretty great.  I really like working with Bill.  I like being outside all day.  I like the pay.  I like everything.  I think I figured things out, and I made sure every plant got plenty of water without wasting any.”

Mr. Smith: “I’m glad to hear that.  We’re glad to have you here – it’s really helping us out. There is one thing we need to work on. I noticed you are very diligent, and you didn’t allow any of the plants to dry out, or even get stressed.  That is exactly what we need.”

Me: (I couldn’t say anything I was so proud, but I was BEAMING!)

Mr. Smith: “But… Bill and I can each water the plants in about half the time it takes you. I’d like to see if you can do it in about half the time too.”

Lesson Eight: Let The Worker Figure Out How To Do The Job Better

Me (a bit saddened, but only a bit): “I thought I was doing a good job. I don’t want to kill any of the plants.  How do I deal with that?”

Mr. Smith: “Well, the trick is to give each plant the exact amount of water it needs.  No more, no less.  We can’t measure the amount, because each plant is a bit different even for the same species: slightly different age, slightly different soil mix, a little more sun here, a little more shade there… that sort of thing”.

Me: “So how can I tell?”

Mr. Smith: “You’ll figure it out.  Next week, I expect you to be able to water the whole nursery in half the time.  It took me time to learn – it will probably take you time too.”

Me: “I’ll do my best”

Mr. Smith: “I have a feeling that your best is going to be better than my best.  Let’s see how you do. So, remember I asked you to keep your eyes open for problems?  Did you find any?””.

Lesson Nine: Continuous Improvement Continued:

Me: “I remembered to look for problems, and I noticed that there was a leak in several of the hoses. It was wasting water and making the paths muddy.”

Mr. Smith: “What should we do?”

Me: “Well, I showed it to Bill, and he showed me how to fix the leaks.  We did it yesterday”.

Mr. Smith: “That’s great.  Let’s go get a soda.”

Lesson Ten: Reflect, tune, adjust

The next day, I tried to figure out how I could work faster and still water all the plants. One problem was that I still didn’t know how much “just enough” water was.  I knew when the plants had too much water – it ran out of the can, and into the gravel – but without letting the plants get under watered, how would I know what too-little looked like?

My solution was to set aside one plant out of each 100 or so, a “test” for me to experiment with.  I set them next to the edge along the row, and gave those plants about half the amount of water I had been giving all the other plants – 1/2 because I was taking twice as long as Mr. Smith needed. That seemed like a good starting point. At the end of the day, I checked those I had set aside along each row (about 200 plants or so overall) to look for wilting, dry soil, stuff like that.  I lucked out.  Each was fine.

The next day, I checked the “test” plants, and most of them were doing just fine… so, I had my solution: I had been overly concerned about too little water, and it was taking too much time.  Now I had “dialed in” the right amount.

So… the rest of that week, I used the new “correct” amount of water.  I made sure to stay alert and keep my eyes open for wilting and drying – and it went well.  Every now and then I’d spot one that was starting to stress, and I’d give those plants a bit more water with a watering can I carried for the purpose.  Overall, it went very well.

Lesson Eleven: Continuous Improvement Revisited, And Listen To What The Worker Says, And… More Lessons

At the end of the week, I went in to Mr. Smith to get my pay, and report on improvements I wanted to suggest.

Mr. Smith: “Hey Woody.  I was watching you this week.  You really did a great job – all the plants look healthy with just a few dry ones here and there, and you got your time right where we need it to be.  Thanks!”

Me: “Thanks for noticing, Mr. Smith.  I was really glad I was able to figure it out.  I was worried I wouldn’t be able to”.

Mr. Smith: “Well, I had no doubt.  You care about the job you do.  You pay attention, and learn from what you see.  So.  What did you figure out we can improve on this week?”

Me: “I’ve been dragging that hose all over the place.  There are only two faucets, one in the front and one in the back.  I have to drag the hose back and forth, and up and down each row.  I think it is taking a lot of time and effort just to do that, and it is wearing out the hoses.”

Mr. Smith: “How will you fix that?”

Me: “You want me to fix it? We’ll need to dig some ditches and lay some pipes, and put a faucet at the end of each row, and get a hose for each row.  That’s a lot of work. I’ve never done that before.”

Mr. Smith: “Can you figure that out?”

Me: “I guess so. But it will cost a lot of money to do that.”

Lesson Twelve: Engage And See

Mr. Smith: “How much time do you think it will save?”

Me: “I think I’ll save a lot of time – maybe an hour or two each day”

Mr. Smith: “How can you prove that to me?”

Me (after thinking a while): “Well, I could put in one new faucet for one row, and keep track of how much time that saves me.  Then multiply that for each row.  Will that work?”

Mr. Smith: “It might. Give it a try”.

Lessons Thirteen Through Infinity

That is just the start of the things I learned about the workplace and the way things should be.

So, What Happened Here?

I could go on like this for a long time.  This was my first two weeks working at the best job I’ve ever had. Kind people, trusting people. They were trustworthy, and expected me to be trustworthy.  They worked hard and expected me to work hard.  Even more, they worked smart, and expected me to work smart.  I was 13 (or 14, I don’t quite remember).  I was just a kid.  They treated me as an equal, and expected out of me as much as they expected out of themselves.

Worst thing: This spoiled me for all other jobs.  I worked there after school and on weekends all through high school, and after high school I continued on and off for a few years.  I learned a lot – about plants, and more importantly, about work, how to treat people, how to “manage”, and how to “lead”.  And how good it could (and should) be.

I haven’t been able to live up to my memory of Mr. Lawrence Smith, and I have fallen short of what I think he expected of me and my life, and in how I treat others.  I miss him still, all these many years later (he died long ago.)  God Bless You, Mr. Smith – you were, and are to me, one of the best.

If You Found Estimates Bring No Value – What Would You Do?

I think this is a simple question:

In your software development efforts, would you eliminate estimates* if you found they bring no value? Put another way, if it costs (time, money, effort, whatever) to do estimates, and you get no return for that expense AT ALL, would you still do those estimates?

Few Are Willing To Answer This Question Outright

I’ve asked this question to about 50 people (face-to-face, in conference sessions, in “Skype” conversations, and in other forums) and here are some of the typical things I hear in response (note that these “answers” don’t answer the question at all):

  • I still like estimates, even if they bring no value, because they help me think about my work
  • We NEED estimates to make decisions
  • I just use them to determine velocity
  • My boss still requires them, even if I think they are waste
  • We need estimates to be able to bid jobs – our customers require them
  • It depends on the context

I rarely hear the answer I originally thought I would hear:

  • Dang right I’d eliminate them! Anything that is a cost that brings no value is WASTE and I would rather spend my money some better way. I won’t keep any process, practice, procedure, policy, or plan with no pay-off. (And quit spitting, will ya?)

I hear a more reasonable answer when I ask the question like this:

Same question (more or less) without the word “estimates”: If waste is anything that has a cost but has no value, would you eliminate waste from your process were you to find it?

Most of the time the answer I hear to this is “You bet I would”.

It seems to me, for the time being anyway, that there is some sort of problem people have when I insert “estimates” into the conversation.

The question is hypothetical

Why are few willing to actually answer the question, and instead “dodge it”?  I don’t know.  I might be asking it wrong.

I pose hypothetical questions to myself all the time.  One of my favorite “thinking tools” is to take the opposite side of some belief I have. For example: I love pair programming.  It feels right, helps me work faster and stay on track, accelerates my learning, gives me confidence in my code, things like that.  So, I will challenge myself and ask: What if I’m wrong? What if pair programming is a wasteful practice? How could I prove that? What would I do if I did  prove it?

Exploration of questions like these help me grow my ability to do continuous improvement. At least it feels that way to me.

I’m Dedicated To Making Things Better

I am always on the alert for waste. It comes in many forms, yet it is often hidden, or disguised as something of value. It’s fun, interesting, exciting even, to find and eliminate waste.  And, it is just plain good business.  A penny saved is ten cents earned.  If you don’t understand how that works, I’ll explain it some other time.

I find it helpful to remember the old Einstein saying about insanity, which I paraphrase here: We keep doing this, it doesn’t seem to work, we need to do better next time, we try to do better, things never get better. Perhaps “getting better at this” is failing, and “this” is not the right thing to do at all.

Once I’ve opened my eyes to the possibilities, I usually find big improvements are going to start happening.  The old thinking and old practices that have been blocking me from “better” are gone, and I can allow myself to imagine the possibilities, and to start innovating.

All I ask

So here is what I ask: Think of it like debate class.

The proposition: “Estimates are waste and we must eliminate estimates in software development”.

Take the affirmative position supporting the proposition, and prepare your arguments.  Suggest ways you could prove that estimates are a waste. Propose how you could replace estimates in your process.  Imagine you could convince your customer to hire your company without a bidding process – perhaps something more like choosing a doctor than buying a car.  Stuff like that.

We won’t really debate – this is just an exercise.  Are you willing to stretch your thinking a bit?  It shouldn’t take long. And you can quit any time and watch TV instead.

Some other posts I’ve written on the topic of estimating:



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

Deadlines Are Our Friend, Sometimes

Lately I’ve seen/heard a lot of discussion about deadlines – and it seems that they are often misunderstood.  Fortunately, I am often misunderstood, and I misunderstand most things… so it seems perfect I should write a blog post about this.

I Worked As A Flyboy At A Newspaper In My Teens – [you can skip this part]

You might have heard of newspapers.  They used to have these things where you could read news that was printed on paper – thus “newspaper”.

In my teens (in the late 1960’s) I had a night job as a “Flyboy” and printer’s assistant for a small newspaper printer who had their own web press (a web press is a huge machine where you put in 1-ton rolls of paper at one end and output printed and folded newspapers at the other end).

What’s a flyboy? It is a boy who stands at the “output” end of the press and picks up an arm-full of newspapers as they come off the press, quickly “jogs” them into a neat stack, and bundles and ties them on a bundler/tier.  “Fly” because the papers “fly off the press”, “Boy” because no reasonable adult would take this job unless they had no other choice.

A Few Things About This Job  – [you can skip this part]

  • It’s LOUD: you will soon loose your hearing.
  • It’s DANGEROUS: the various parts of the machines (cutter, folder, bundler/tier, etc) are all capable of removing parts of your body, mostly fingers or hands.
  • It’s DIRTY: the ink is still drying as you handle the papers. You get completely covered in toxic pigments that you have to scrub off with a scrub-brush at the end of a shift, and you’re breathing paper dust and toxic fumes the whole time.
  • It’s a NIGHT JOB: Or, very often it’s a night job because the papers go out in the morning.
  • It’s HARD: It takes a great deal of constant physical exertion so you are guaranteed to be worn out at the end of the shift.
  • In other words, at the end of the day you are tired, dirty, injured, and nearly deaf – much like computer programming.
  • You don’t want me to tell you the bad things about this job.
  • This has nothing to do with the point of this story.

Besides being a flyboy and a printer’s assistant, I also would do typesetting for some of the less important content, and operate smaller presses to print advertising flyers that get “stuffed” into the papers at some point, and help run the cameras and to do various layout, stripping, and other tasks.  Most of this stuff is now considered a “dying trade”. And good riddance, I suppose, but I loved it – it seems I always loved books, printing, machines, noise, lettering, typesetting, doing stuff, craft, high skills, hand work, hard work, and late night radio.  Especially the shipping reports from England that come on at 2:00 am PST.

Point is:

The point is I don’t know a lot about the whole process except what I learned when I worked in this environment for about a year, and I think I remember just enough to make my point (hopefully).

Getting the newspaper ready for printing each day requires a lot of specific things get done ON TIME

All of the following list of work must get done on a very tight schedule every day:

  • Before you can print you must make the printing plates.
  • Before you make the plates you must do the layout, camera work (separations, halftones, etc), and stripping
  • Before you do the layout, camera work, and stripping you must do the typesetting.
  • Before you can typeset you must have edited copy
  • Before you can edit copy you have to decide that a story merits getting into the newspaper
  • Before you can decide which stories merit getting into the newspaper someone must write those stories (or at least the headline and some copy) and take photos
  • Before you can write stories and take photos the reporters and photographers have to go to the scene of the story and gather news, do interviews, etc.
  • Before you can write a story you have to decide what to write the story about – a “news events”.
  • Often the “news events” happen throughout the day and we don’t know what they might be until they happen. Man Bites Dog. Nuclear Annihilation Avoided – Again, Major Caught In Drug Scandal – Again, and so on.
  • And so on and so on.

There are a LOT of deadlines in there – and they ALL HAVE MEANING.  As a matter of fact, I’ve left out a lot of details just to keep this post small enough to fit on the Internet.  Also, a number of these things happen “in parallel” – a story can be “gathered”, written about, and edited while other stories are at different stages of “completion” and still all get into the same daily paper.

So I am going to talk about the classic “Printers Deadline”.

There is a HARD DEADLINE in Newspaper Printing

At least where I worked, we had a hard deadline.  To get the paper out to the “marketplace”, the trucks must leave sufficiently early before traffic starts so the papers can be where they need to be when people want to buy them.  That’s the business. So – the hard deadline is: The press must start early enough to start putting newspapers into trucks so they can leave on time.  It is a complex dance with a lot of variables.

To do this, each step along the way has a specific deadline: It’s the time all items for this step MUST BE DONE with enough time to do all the following steps and still be on the press when printing starts.

The bottom line: if a story isn’t ready and “on the press” when the press starts printing, it is NOT going to be in the newspaper (there are ways around this, but that’s the general idea).  That is a hard deadline.  A lot of things can be easily changed right up until that minute.  After that, it is costly in both time and money to make changes.

Sometimes someone will yell “Stop the Presses”, like you see in the movies – but that is rare.  There are occasional “Dewey Defeats Truman” mess-ups.

My point: Real Deadlines Exist

Real deadlines exist. When they do exist, we need a system or method in place to deal with them so we have a reasonable chance for success.  In the newspaper business they have the deadline thing figured out.  The deadline is obvious. Some people say this is where the term “deadline” was invented.  By the way, the newspaper industry has bigger problems than deadlines nowadays, or maybe it’s a different kind of “deadline”, and we can talk about that some other day.

How Newspapers Deal With So Many Deadlines

There are a number of things the newspaper publishers have found work nicely to allow for these serious deadlines.

  • Create news features (stories) daily – work in daily iterations – each day, the current “most important” content is created
  • Deploy daily – a whole year worth of news is delivered in small, useful, daily chunks
  • Decisions are made at the last responsible moment – if a more important story comes in at the “last minute”, a less important story can be removed.
  • If insufficient material is generated for a story for it to be interesting or useful, they can quit working on it at any time.
  • Whatever is done by the daily deadline is what gets delivered.
  • There is no “Yearly” deadline – it’s more like a continuous delivery system.
  • They discover processes that allow them to work quickly – e.g.: you can buy some stories from a third party (such as… the AP)
  • They can “spice things up” as needed to boost sales.  That is not really important to the point of this article.
  • They ca add lines and cut lines from a story to fill the space as needed.
  • If a really important story comes in, several people can work on it at the same time.
  • Stories that can be worked on, are worked on.  Stories not ready to be worked on aren’t.
  • Fillers and other non-news “content” can be done and ready to add as needed without effecting the output of more meaningful content.  For example, a whole weeks worth of comics can be ready each Monday.
  • Reporters and photographers can be multi-purpose (they can wear more than one hat).  They can interview someone, take a picture, write a story.  Some can even do the typesetting in smaller houses.
  • They only need enough good (or really, “bad”) news material to keep people happy.

News items have different schedules and different deadlines based on the nature of the content – a garden page item might take weeks to write, photograph, illustrate, layout, etc – and a hard news item often has at most about a day and sometimes as little as an hour to go from “this just in” to “press-ready”.  Almost any feature can be edited to reduce its size, increase its size, or rearranged to fit the space on a page.

Sometimes they “stop the presses” and re-set one of the plates to change or add content.  Also sometimes a “special edition” is needed to disseminate late breaking but important news.  Sometimes a flysheet can be printed on another press to add content at the last minute.  Lots of options.

In other words – there are many practices they’ve innovated over the years to be able meet those deadlines and do the job of delivering a sufficiently interesting and sell-able product.

Sometimes Deadlines Are Needed, and We Need Ways To Handle That

Well – this blog is about software development, not the newspaper business.  However, I think there are a few similarities.  What do you think?  You probably see other similarities, and a few differences between the newspaper business and computer programming.  Still, the newspaper model might have some use.

Do you have deadlines??? Learn how to deal with it.


A Thing I Can Estimate

This is a post about a trivial thing that I can estimate, and there is a non-trivial point I want to make at the end.  So you can just skip-to-the-end if that is the sort of person you are.

I can estimate how long it will take me to drive to work.

I drive to work 5 days a week.   I need to get to my workplace, but I also want to pick up my daily oatmeal and drink for breakfast at a fast-food drive-thru.  Simple stuff.

Why do I need an estimate?

I need an estimate so I can be sure to leave home early enough to get to work on time.

I like to get to work 15 minutes early, and I’d like to make sure that I am never late except in exceptional cases.  So if I can estimate a time that will get me there about 15 minutes early, but never later than 5 minutes early that would work for me.  I don’t mind if I am 20 minutes early, but I don’t really want to be 25 minutes early.  So, I’m looking for a time range that gets me to work between 7:40 and 7:55, with the ideal spot being 7:45.

I want to be on time to work, with sufficient time to not worry about being late, and still not waste too much time just sitting there tweeting about estimates.

I drive pretty much the same route every day with about 10 minor alternatives available. I can take advantage of these alternatives (turn right here, or turn right a block up, stop at this fast-food or at that fast-food, etc) to make allowances for congestion at traffic lights, schools (school days are busy, holidays are not), drive-thru lines, and stuff like that – so I make a lot of little decisions on the way. For example: I’ll turn right at a light if there are a lot of cars backed up and take a chance that the next street isn’t backed up.  That allows me adjust to get a better chance at a good drive time.

I can estimate how long this will take, and use that estimate most of the time.

Yesterday it took 40 minutes, the day before 43 minutes, the day before that 36 minutes (school holiday).  Over the last year, I’ve found that it takes about 40 minutes to drive to work on a typical day.

If I leave at 7:05, I will almost always get to work in my target time-frame.

All well and good.  And that works great for me for typical days.

I can take advantage of daily changes

I “re-estimate” daily to adjust for school holidays, weather, etc. and vary the time I leave for work to compensate.

To clarify: I re-estimate every day to adjust for daily differences.  I can “re-estimate” quickly.  The cost is about 10 seconds of my time.

On a school holiday, I can sleep in 5 minutes. If it is raining, I must leave 10 minutes early.  If it is snowing, something is really wrong because it never snows here.

Why Does This Work?

You already know:

  • I have a lot of data – way more than is needed.
  • I know all the variables (weather/holiday/etc)
  • I know the work-arounds (alternative routes)
  • It’s essentially the same thing every day
  • There are almost no unknowns
  • There is almost nothing new to learn
  • I can trust the guy who is providing the numbers.  It’s me.

That is, it is trivial.

By the way –  I can’t control the variables to predict an exact time, so a range is sufficient.

Having the estimate is useful as it helps me optimize my sleep time and still reach work on time.

This is the Non Trivial Part: How Similar Is This To Computer Programming?

So, if it is useful to have an estimate, and we can make a meaningful estimate – then we have a good application of estimates.  That is the case with my “drive to work” example.

In my humble opinion, this is not similar to computer programming. We have the first part: We feel estimates would be useful, but we don’t have the second part – the estimates are not meaningful unless you are doing very trivial work.

With software development we don’t have much data, we don’t know the variables, we don’t know the work-arounds, each project is very different, there are lots of unknowns, there is much to learn, and I can’t trust anyone for “good numbers”, not even ME.  By the time we know enough about what we are doing to make useful estimates they are useless because we are DONE.

When we find our software development work is “easy to estimate” it is likely that it is trivial in nature.  That is, if it matches the nature of my “drive to work” example then I would question if that work is actually software development. In software development, when I find I am doing the same thing over and over, know all the variables, have few unknowns, have little to learn – then that’s the time I investigate ways to automate it and stop “programming” it.

Have fun.

And remember: This is ALL JUST MY OPINION.  Don’t do anything I say.  Don’t mention to anyone else that this makes sense to you, they will just say you are crazy.


Some other posts I’ve written on the topic of estimating: