One little blog post cannot even begin to explore this complex subject. Here is a start at beginning the first part. Or perhaps, a pre-beginning.
If you really want to figure this out quickly don’t wait for me to figure out how to write about this. Just come and visit me sometime and I can quickly show you the whole thing. It really isn’t hard. Or, even easier, read the Agile Manifesto Values and Principles. It’s all there.
A Few Paragraphs You Don’t Need To Read
It’s obviously not my job to tell you (teach you, show you, guide you, coach you, whatever) how to be effective at software development. My job is to write software, and coach and work on a team that is writing software – and to deploy that working software so people can use it.
I don’t write books, sell certifications, do trainings, or provide workshops for a living. I have nothing to sell you. [I’ve occasionally done introductory sessions about Agile stuff for a company or two. I love doing that, but it is not my living or my job. ]
The company we work for makes irrigation products. Great company, great team, great product. I truly love being able to come in to work every day to be with my team and do the work we do. Point is: I make software for a living.
Estimates are NOT a deliverable
Regardless of how we define “estimate”*, it is not a deliverable in the world of software development. I’ll write another post about that if you don’t agree . (That’ll show you!)
The Basic “No Estimates” Approach
Here are the basics – in very simplified form told as a mini “case study”, based on a real situation from a long while back (not my current job) – but I’ve changed the details so no one will get mad.
- Boss – you can think of Boss as the “Product Owner”, “Customer”, or “User” or some combination of these. In any case, Boss is a “person(s)” who knows enough about the purpose of the software (or some part) to make reasonable decisions, and who is responsible and has authority for making those decisions.
- Woody – you can think of Woody as the person who guides the software development process – could be a devleoper on the team, or some other person who understands software development better than I do. We’ll call him Woody.
- Team – everyone else working on this “project”.
- This was a while back, but Woody was already capable at “No Estimates Software Development”.
- This project was a new “internal” application.
- Project accessed existing databases, but also would likely need it’s own database.
- Boss had never worked with No-Estimate Software Development.
- There was a lengthy “requirements document”. It was believed that everything in the requirements doc was necessary. [Note: It was a mess, and if I had any influence I would have abandoned it].
- Team had all necessary skills and knowledge to do this work.
Approach for day one:
- Start with the huge list of way too much stuff that Boss says needs to get done (the original requirements doc, so to speak).
Ask Boss to select one “small” thing that he felt was very important.
That “small” thing becomes the “thing we are working on right now”: We’ll call it a “Story”, but on this job we didn’t use words like story. We called them features.
Team starts work on the Story.
Approach for day two and each day after that:
Team works on the thing we are working on right now. Nothing else.
Team constantly assesses the work we are doing, and splits the current Story if it is too big to easily understand or make progess with. We check with Boss, but have no issue breaking things down.
Team asks questions as soon as they come up, and get the answers right away. Without this, projects drag on through endless muck.
Team completes the story we are working on right now (or part of story that we split off)
Team deploys the Story if it is deployable, and if it is not deployable then Team works with Boss to understand what needs to be added to it to make it deployable, does that, and then deploys.
Team asks Boss to pick the next thing she thinks is very important. It can be the other part of the previous story, or any other thing she thinks is important.
First deployment happened in a little over a week.
Project was deemed “done” in about a month and a week.
As we started delivering usable software, the users and Boss started asking for different things than had been described in the requirements document. The users and Boss started fine tuning what we had delievered – noting things that they wanted to be done differently. This is a valuable and wonderful thing. This is how requirements emerge.
After about one quarter of the “features” described in the requirements list/document (including the additions the users and Boss had asked for), Boss decided the project was “done enough”. The users were doing most of what they needed, and the rest wasn’t important enough to do, at least for the time being – there were other more important things to get done on another project. The users were happy. Boss was happy. Team was happy. Woody was happy.
Team was iterating (but not time-boxed), and incrementally delivering.
Boss wanted estimates, and also wanted the work done as quickly as possible. I made the case that we could try to get some critical feature into production ASAP, and then revisit the idea of estimates later. After the first deployment, no requests were made for estimates.
Estimates are part of the “comprehensive documentation” that we value less than “working software”. If you don’t see that – please let me know.
I am sure you saw the big win, right? We discovered the needed features. Most of what was thought to be needed was not actually needed. Doing the work of writing the code in small pieces and getting it into real use made it possible to steer the work. This is the “requirements emerge concept”. I urge you and encourage you to think about it and experiment with it. It is GOLDEN.
Even if estimates were not liars, we just simply did not need them.
Well, that might be a little help. It’s just one very basic example. But it’s real.
This all just seems like “plain old Agile” to me. Many people tell me I’m wrong. What do I know? I’d rather be wrong about what to call this and be getting a lot of work done than the other way around. Let me live in my delusions.
* 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.