To me, This is Agile

I’ve seen a lot of orgs/teams/groups/whatever (I’ll call them orgs for now) doing things that aren’t working, and yet proceeding as if they are working.

I’ve seen a lot of these orgs move on to “better” starting from wherever they are by learning to reflect, tune, adapt, adjust (and some other things).

I’ve seen number orgs revert or “backslide” as well – both slowly over time, as well as almost instantly in some cases.

Whatever the situation, those of us who want things to be “better” need to take action, and that will never stop.  At least I’m pretty certain that will never stop.

I take it as my responsibility to make things better in my profession and in the places I work.  I act on this responsibility by exploring possible “better ways”, implementing “better ways”, and influencing things to the degree I can.  To that purpose, I constantly work on improving my ability to influence things for the better – sometimes I have success, sometimes I don’t.

To me, this is “Agile”:

An approach that works well for me is to always take rapid, never-ending baby steps to “better”. I constantly reflect, tune, and adjust. When things work, great. When they don’t, it’s easy to adjust or take back that baby step and try some other step.  Sometimes I take leaps, but I prefer taking baby steps.

For me, there is often a “Lofty Goal” that represents a vision of a better future.  It will change over time, and any specific “lofty goal” can grow, morph, or fade away over time depending on what I discover as I take more baby steps.

I want to always have the option to make mistakes, and to pay as little as possible for those mistakes.  Sometimes I must pay a lot for our mistakes. Still, I prefer to find ways to keep the price tiny when I can.

Being resolute to work with others to always steer to the next possible “better” seems to work nicely.  I fail in many ways, but it is not the ultimate failure of thinking and acting as if “I can’t make a difference”.

The Values and Principles of the Agile Manifesto are the foundation of my idea of what “Agile” is, and what it is to me.  I have expanded on these ideas for my own work, and I don’t see them as being “static”, but rather a somewhat firm yet dynamic set of guidelines that are easy to apply for evaluating my thinking about the business of software development, and for my exploration of software development practices and techniques.

I know what works for me: I take the Agile Manifesto seriously, and I constantly Reflect, Tune, and Adjust.  I think of this as “Pure Agile”.

Cheers!

Upcoming 2014 Speaking Plans

I have made plans to speak at several upcoming conferences and events.  If you are attending any of these, I’d love to meet up with you and talk about Agile, Mob Programming, #NoEstimates, #BeyondProjects, or just about anything please look me up!

 

Already done…

 

 

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 http://dianalarsenworkshop.eventbrite.com

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 www.agilefluency.com

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 http://dianalarsenworkshop.eventbrite.com

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”

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.

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.

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.

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:

Cheers!

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.