#NoEstimates - Alternative to Estimate-Driven Software Development

Free software development magazine Methods & Tools has published my #NoEstimates article in its Spring 2015 Magazine.

The title of the article is: #NoEstimates - Alternative to Estimate-Driven Software Development.

Comments

If you would like to comment the article, you can do it here in this blog post.

Other posts

If you liked the article, you may want to read my #NoEstimates blog posts.

95 excuses

1. A software developer wasn't happy about the work he was doing. To be precise he wasn't happy about the system he was working in. He knew the concept of a system since he had read books from great minds like William Edwards Deming. Especially the developer remembered how it's 95% about the system and 5% about himself. For that reason he felt that he is forced to continue working in this dummy system where his company as a vendor makes stupid promises for customers in order to get deals. So reluctantly he continued doing his work as before.

2. At the same time the sales person of the same company was feeling miserable. She was going to contract negotiations with a new customer. And she was miserable because she felt that the both companies were doing it really wrong, in a way that doesn't benefit either of them. But the sales person had also read Deming and thus remembered how there's probably not much to do since it's 95% about the system.

3. The person responsible for ICT sourcing from the customer's company was also thinking about the upcoming contract negotiations. He didn't like the idea that he should aim for the lowest possible price instead of focusing on more important things in the vendor selection. But of course he wanted to think about the possible bonus he might get if the deal was well-negotiated. And besides, why to bother trying anything else since it's 95% of the system anyway. That's what Deming was saying in his famous quote.

4. The CIO of the company was worried how the big software project that was about to start would go. He didn't have very good experiences about the previous ones and felt that the company needed a radical change in how software projects were to be managed. But at the same time he kind of knew that he couldn't make much a difference because the company culture was supporting the old way. He was thinking what Deming had said and felt being just a small man in this big system. So while walking to the next meeting he thought that maybe it's just better to continue doing job as before.

5. The company's CTO was sitting in her room and felt disappointed. She wanted to change the company into better but it was so difficult. And when she remembered what Deming had said about 95/5, the change felt even more difficult. She saw so many problems in the system her company was part of, starting from the university education. According to her experience the education system wasn't producing such graduates that the real business world needs.

6. At the same time a professor in the university was angry. She was angry because she had to spend too much time on bureaucracy instead of sharing her precious knowledge for the students. While watching the Deming's quote that she had printed to the wall of her room, she knew that it's just better to keep filling the papers because she couldn't change the system anyway.

7. ...

...

95. ... and because of the 95/5 rule the junior football team coach felt that there's not much he can do.


"No, no, no! This is not what I meant!" Deming couldn't believe his eyes while he was watching this miserable play. "How did this happen?" he was wondering. "Please, let me go back there. There's still so much work for me to do!"

No software development standards

Yesterday I had a day-long discussion about standards on Twitter. It all started with Riina's worrying tweet, following with some jokes:

Obviously behind all that was skepticism towards standardizing certain things. But then we moved from joking to more serious discussion when Ari Tanninen commented that "ISO standard for user-centered design isn't half-bad". He gave a link to a presentation that provides more info about BS EN ISO 9241-210:2010. I was still skeptical. I felt that you shouldn't try to standardize software development.

Good software standards

The discussion moved on. When I criticized standardizing software development, I was mentioned about things like SQL and HTTP - and this:

But my point wasn't that. I see a lot of value in software standards. As a web developer I get big benefits myself when browser vendors follow the HTML and CSS standards. Globally speaking, those benefits are gigantic. So yes, IE6(-8) is a sad story and shows what happens when standards are not followed.

However, I'm not against software standards, I'm questioning the need for software development standards.

Let's make Scrum as an ISO standard?

So what if Scrum would become an ISO standard? Companies doing software development would be forced to use it in case they wanted to get certain contracts. Or companies following the standard would have an advantage in competition because they could say how their software development departments are following the standards, which "prove" that they are doing great work.

Well, I like Scrum and I think that it has brought a lot of good to the software development industry. On the other hand, it's about 18 months since I was last time using it. And this doesn't mean that I'd been in a vacation or unemployed the last 18 months. It means that I've been in contexts where doing software in some other way makes more sense.

You probably already picked one keyword from the text, context. Software development is always very context-dependent, which is one important reason why standardizing it is not so good idea. The same argument works also with the proposed testing standard, ISO 29119. Software testing, as part of software development, is also very context-dependent and creating one standard for it is very questionable.

Unfortunately I'm not able to see the testing standard text but for example the contents of the Test Documentation part just scares me. I have worked with big companies and can imagine some horrible scenarios if they would jump into using such a standard.

Why is software development different?

So why some standards, even software standards, bring major benefits (cost savings, increased market share, even environmental benefits) but I'm against them in software development? I already mentioned context as one important reason. But there is more.

Basically I would say that if the aforementioned benefits can be reached by reducing variation, then a standard makes sense. I mean that's what standards are all about, doing a certain thing in a certain way instead of one hundred different ways.

However, in software development the goal is not to reduce variation, like it is for example in manufacturing. Instead, due to the asymmetric economic payoff-funtion, variability gives us a possibility to exploit opportunities. If on the other hand the development is standardized, we miss those opportunities. (Read Donald Reinertsen's book to understand more.)

So please, be very careful when you try to standardize software development. It can be that you haven't understood the very core nature of it.


PS1. A lot has been written about the proposed testing standard ISO 29119. If you are interested to learn more, read for example Stop 29119 by Iain McCowatt, any of these, or this post written in Finnish by Maaret Pyhäjärvi.

PS2. Standards are not my specialty. If you think I've understood something wrong about them, I'm more than happy to receive your feedback.

Cost of delay and artificial deadlines

This is my second cost of delay post, you may want to read Unquantified cost of delay in prioritization first.

How to recognize an artificial deadline using cost of delay?

Business world is full of deadlines. Sometimes they cause unnecessary stress for the employees and for the organization, sometimes they contain a really important message how something cannot be late. So how to know when a deadline is reasonable and when it is artificial?

My claim is simply the following:

If the form of the cost of delay curve does not change near the deadline, the deadline is artificial.

Examples

Let's take a couple of examples.

In this case the deadline is reasonable. If the company misses it, I will lose a big amount of money.

In this case the deadline is questionable. Yes, in the future the company may lose a big amount of money but why is the deadline so early? If the deadline is met, the ready product/feature/etc is waiting in an inventory for a long time. Another possible problem is that the solution is implemented without using the latest available information. This means that in the worst case the solution can be outdated when the real deadline hits.

In this case the deadline is artificial. You can ask why that particular date was selected? Why not week later or week earlier? It is hard to see the reasoning for this deadline. If there are no bigger cost of delay items waiting to be done, this should be just done as soon as possible. If there are, this task is a wrong one to do.

Also in this case the deadline is artificial. Yes, the company is losing money all the time but why not just focus on fixing the problem as soon as possible?

What to do with an artificial deadline?

If I hear a deadline that seems to be artificial, I always ask how the date was decided? It may well be that I'm missing some important information that I didn't know earlier. In that case the deadline isn't artificial and I just learned something relevant. On the other hand if it appears that the date was "just selected", it gives me an opportunity to have a discussion about the concept of cost of delay.

If you can figure out a situation where the cost of delay curve does not change format but deadline still makes sense, I would be interested to hear.

Unquantified cost of delay in prioritization

Cost of delay (CoD) is an old financial tool for evaluating the cost that is assumed to happen when something is delayed. Its importance in (software) development work probably increased remarkably after Donald G. Reinertsen published The Principles of Product Development Flow (at least from my point of view). In his book Reinertsen explains very thoroughly why CoD is a really important metrics and why it can be a valuable tool to be used in prioritization. His principle E3 says:

The Principle of Quantified Cost of Delay: If you only quantify one thing, quantify the cost of delay (p. 31).

What comes to the prioritization, Reinertsen offers for example this simple advice related to CoD:

I'll just give you two simple heuristics: high cost of delay before low cost of delay, and short jobs before long jobs (p. 70).

So basically it's quite a simple thing. Just calculate the CoD like Reinertsen does and decide. But is it really that simple in practice?

Cost of delay without numbers?

As a development team member I'm making many prioritization decisions every week. Obviously I try to make good decisions together with other team members and stakeholders. In theory CoD is almost all I need but in practice there's a big challenge how to quantify it. Either the numbers aren't available or it is not cost effective to get them. I suppose that Antti is facing the same problem and for that reason doesn't know how to utilize CoD in his work.

Fortunately it is still possible to use CoD in prioritization even though we wouldn't have numbers available. The key is to understand the different types of CoDs.

Example

This is quite a recent example and related to the original tweet. We had to decide whether to implement feature A or feature B first.

The company was about to start a print marketing campaign. The question was: should they include the feature A to the marketing material or not? Obviously if they mention about it, the feature has to be ready when the campaign is out. If they do not mention it, there's no hurry with building the feature but then they miss an opportunity to sell the feature for the potential customers during the campaign.

The feature B on the other hand was more of a "regular" feature. There was no marketing campaign related to it, nor any seasonal specialties.

Without having any numbers available, I was immediately thinking how the CoD curves would look like in each case:

 

Cost of Delay - Feature A

 

Cost of Delay - Feature B

The feature A has a cost of delay that is clearly related to the marketing campaign. The cost here is the lost additional sales that the campaign would probably bring to the company. The feature B has no such attribute. The lost sales (or satisfaction of the current customers or some other value) increases steadily among the time. Based on this we decided to prioritize so that we build feature A before B so that the company would not lose the opportunity window that would be open during the campaign.

Is shape enough, don't absolute numbers matter?

There is a reasonable question flying in the air. Are you sure that the curve for the feature A is above the other curve? In other words, how can you be sure that when combined, the curves don't look like this?

 

Possible cost of delays

My answer is that we cannot know for sure. But we have some hints that we can look at. The implementation of both features has been delayed already for quite a long time. If the CoD curve of the feature B would be very steep, the feature would have been probably implemented a long time ago. We can reasonably assume that since both features have been approximately at the same height in the backlog, their business value is pretty much the same. Now it just happens to be so that feature A fits very well for the marketing campaign that is about to be started. And the campaign starts no matter whether this particular feature is ready or not.

Classes of services

Another person who has popularized CoD in software development is David J. Anderson with his Kanban: Successful Evolutionary Change for Your Technology Business book. (Btw, check who has written the foreword for the book.) Anderson talks about classes of services - expedite, fixed date, standard, and intangible - and relates them to the different kind of CoD curves.

I'm not going to talk about more of them in this post, you could read e.g. Andy Carmichael's excellent blog post Selecting Backlog Items By Cost of Delay. Another post worth to mention is Mike Burrows' Kanban prioritisation and scheduling with classes of service. Nevertheless, I think that understanding those classes helps you in using CoD in your daily work, even without quantifying the cost.

Summary

I would like to emphasize that I'm not trying to understate the importance of quantifying CoD. And I really like how Reinertsen highlights that our decisions should be based on quantifiable economics instead of e.g. gut feelings. However, in real life the available data is very often insufficient and getting better data isn't necessarily cost effective. Still you need to make decisions and you try to do them as well as possible. In those cases it helps if you understand the principles of CoD, even when you decide not to quantify it.

Another point of view is that in agile software development we try to make many small decisions over the time instead of few big ones in the beginning. Then it doesn't matter so much if the decisions made are wrong because we can usually fix them rather quickly. In that kind of world using too much time on getting exact information isn't necessarily justified.

Obviously the bigger the impact of the decision is going to be, the more you should invest in making better analysis of the situation and actually quantify the CoD. And you can always think how you could improve your system so that relevant data could be available for the smaller decisions as well.

Experiences from programming with kids

I was kind of scared beforehand but afterwards I felt just great. Couple of hours ago I was teaching 1st to 6th graders programming and it was so much fun! Let me share with you my experiences so that you can do the same thing somewhere else.

Background

Keinutien ala-aste (elementary school, grades 1-6) in Helsinki decided to organize a special school day on Saturday 27th September, 2014. The theme of the day was the popup school. The idea is that anyone (kids, parents) can teach anything and the kids can decide what sessions to participate in. So I volunteered and decided to teach kids how to program. I wouldn't have done that unless there had been so much fuzz about code schools in Finland during the past year. Without that there probably wouldn't have been ready-made material available either so thanks to Juha Paananen et al. for making the koodikoulu.fi and Turtle Roy available for anyone!

Preparing

Because I wasn't sure what to expect when working with children I wanted to test it. First I tried my ideas with my 6 year old son who goes to the first grade next year. Since that went so well, taking into account his age, I was encouraged. Especially I got convinced how to start each session (I'll tell you more about that later). Next I tried the same things with my 8 year old son and his friend. I felt that I was pretty much ready for the show.

Couple of days before the school day I asked the organisers to check that our coding environment, Turtle Roy works as expected. The local IT teacher found out that it works with Chrome but not with IE. He tested moving and turning but unfortunately not sequences...

Right before the sessions

I was told that there are going to be 4 sessions with 20, 10, 7, and 16 students. Usually in code schools here in Finland each kid has a parent along and they work together in the same computer. In this case there were going to be even twenty kids and only one adult besides me! So I was a bit frightened if it's going to be just one big mess. One thing that I noticed when practicing the code school was that 8 years old kids need lot of support with the keyboard. So how on earth is it going to work if there are 20 children needing the support?! Well, luckily most of the kids were older than 8.

When I went to the computer room, I checked that everything works nicely. Oh shit, I wasn't able to type square brackets meaning that I couldn't write this important piece of code: s [fd 50, lt 90]. The brackets worked elsewhere but not in the command line of Turtle Roy. So we had to figure out a quick workaround, which was to write bracket somewhere else and copy it from there to the command line. (The square bracket issue has been fixed.)

Content of one session

Let me next describe the basic structure of each session. I decided to follow the steps described in the Turtle Roy Github page. Besides that I added one important step to the beginning, right after the introduction.

Introduction

First I introduced myself and told that I'm like a professional football player: some people pay me money for doing something that I feel is my hobby; I'm a programmer. Next I asked who has used some computer program this week. After only some of the kids raised their hands I asked another question: who has used a mobile phone or played any computer games this week? Now when everybody had raised their hands I explained them that the games are programs as well and someone has programmed them. I explained them that programming means that someone tells the computer how to behave and today the kids are going to do exactly that.

I had asked them to form pairs. One reason for this was that it halved the amount of helping we had to give for the kids. Another reason, which I told them, was that programming quite often is pair or team work. So these kids started their career by pair programming. :)

Practicing without (real) computers

Inspired by the experiences from ICT-portti I decided to start without computers first. I told the kids that I'm a computer now and they need to program me using the commands: "move forwards", "turn left", "turn right". Their task was to transfer me from my current location to the other side of the room. I emphasised that I won't understand any other commands. So for example if someone said "jump", "move" or "go left", I replied: "I don't understand the command".

The students got the idea quite nicely and every group managed to get me to the goal. Also in each group I got wrong commands. This helped me when getting to the next stage. Let's start programming with the real computers but remember kids, you have to be very specific when giving commands for the computer!

Moving and turning

We started the Turtle Roy programming with the simplest command that I had written to the whiteboard: fd 50 (move forward). This was trivial for most of the kids but even here some of the youngest needed a bit of help. The next commands were naturally about turning: lt 90, and rt 90.

When everybody got their turtles moving and turning, I encouraged them to try what happens if they write e.g. fd 100 instead of fd 50. This was actually one of my key thoughts: the kids should try and see what happens because that is actually quite an essential part of programming many times. In other words, there are no mistakes or wrong solutions. The only mistake you can make is not to try.

Since by trying (obviously they try what happens with the command fd 1000000) they got quite a mess for their boards, I told them about the fourth command: clear.

I also explained what the number 90 means in the turning commands by drawing it to the whiteboard. Basically, if you want to turn a bit less, try e.g. lt 30. If you want to turn a bit more, try e.g. lt 120.

For the older students who already are learning English I told how the commands come from English. fd means forward, lt is left turn and rt is right turn.

The square challenge

Then I gave the kids a challenge: they should try to draw a square. I helped them by asking how they should command me if I was a computer again. The kids started typing: fd 100, lt 90,...

This was the place when the first ones got really excited when they realised how they can draw something more meaningful.

When the squares were ready, I asked the kids that wouldn't it be nice if they could make a square with only one command? In order to get there I asked if they saw any repeating pattern in the square commands I had written to the whiteboard: fd 50, rt 90, fd 50, rt 90, fd 50, rt 90, fd 50, rt 90. This was a nice step to the next phase.

Sequences

The sequence was the most difficult thing during our session because of the bracket issue. So we had to help the kids a lot so that they were able to write the sequence command: s [fd 50, rt 90]. I felt that some of them had to give extra focus so that they don't get frustrated. But on the other hand when we got the command ready together, they got excited again.

Here I also advised them how to use the arrow keys so that they don't need to rewrite the same command again. So very quickly after the initial troubles the kids were able to draw a square by repeating the sequence command four times.

Repeating

The natural follow-up question for the kids was that wouldn't they like to do the whole square with a single command instead of four commands? After all, computers are really good at repeating things that human beings find boring. So it was time to introduce the repeat command: r 4 (s [fd 50, rt 90]).

I remember how some kids responded with bigger eyes and smile when they run that command. Now they managed to do the whole square with just one command! And more was coming...

Let's play!

My last advices were that now it's time to play. Change the numbers in the latest command using the arrow keys. Don't repeat just 4 times, repeat for example 40 times. Don't turn 90 degrees, turn e.g. 50 degrees. And for some I also said that they can add more commands to the sequence. Anyway, the most important message I wanted to give them was that try things out, play with the turtle, and have fun! It's actually quite amazing what kinds of beautiful flowers, stars, or gearwheels you can get with that simple command when modified.

I also promised that the pair that draws the best picture gets a reward (lollypops). My tip for that was: those who are willing to try out different things are going to be the best ones.

This was again one of those moments that were full of wows and smiles. It was really rewarding for myself to get all the way here and see how the kids had learned so fast.

What not

I was prepared to teach them how to play sounds (e.g. play [c, d, e]), how to make the turtle speak (say "hello world"), or writing (print "hello world") in case there was any time left. But as I had guessed, the 40 minutes went so quickly that we didn't do these in any of the sessions. So neither had we time to see any "real world" code. Maybe that was just a good thing because I had some Java code open in my laptop at that time...

If there would have been another session with the same kids, we would have probably tried to write some functions as well. It would have been really interesting to see if they get it or not.

Afterwards

Like I said in the beginning, I had really good feeling about the sessions afterwards. I had some fears that mostly did not come true. Instead I saw many moments where kids learned fast, where they "just got it", and where they smiled when they succeeded.

The only thing that I was a bit disappointed was that none of the pairs helped the other pairs. I had hoped that I would see more advanced students giving help for the less advanced without asking it. But that didn't happen. I wonder if it has something to do with our school system or was it just how our setup was in the sessions.

One of the best things was when my assistant teacher, the local IT teacher, said that he is going to start using Turtle Roy in his own IT classes with 4th graders. He was convinced that this is a good method and it will be valuable for them. This teacher is btw going to be ahead of his time since programming will be part of the official curriculum in Finnish schools 2016.

Lastly I want to say my special thanks for all the kids who attended my code school. I had really good time there, thanks to you!

About the definition of #NoEstimates

I’m writing this blog post because I see too much confusion in what #NoEstimates actually means. I believe that if we could get rid of the unnecessary waste around this topic, we as a software development community could get much more out of it.

The definition

Although Woody Zuill defined the #NoEstimates already over a year ago, it hasn't been widely used since. Nevertheless, I like his definition:

"#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making decisions in software development. That is, ways to make decisions with 'No Estimates'."

The core of the definition is that #NoEstimates really is just a hashtag. Let me clarify more what this definition means in my opinion.

What it is not

• #NoEstimates is not any method, tool, or process that you can directly apply.
• #NoEstimates is not a “follow these 10 steps and you will be doing it properly”.
• #NoEstimates is not estimates related discussion in every possible context. For example it’s not discussion about estimating who will win the World Cup in Brazil or how long a trip from Helsinki to Brazil would take.

What it is

• #NoEstimates is one approach to the Agile Manifesto first sentence: "We are uncovering better ways of developing software by doing it and helping others do it."
• #NoEstimates is discussion about software development cost estimates, what is wrong or right with them, and especially: what alternatives to estimates there are for making decisions in software development (see Woody's definition).
• #NoEstimates is a wake-up for many developers and hopefully in the future for many more managers and business owners that estimates are not always needed.

Who are the proponents?

#NoEstimates proponents are those who feel that there is a need to seek alternatives to cost estimates in software development decision making.

Who are the opponents?

Since #NoEstimates is about seeking alternatives to estimates, opponents of it are those who either don't believe that better alternatives exist or for some reason are not willing to look for them. If you challenge someone's suggestion for an alternative, that doesn't make you an opponent, you are just taking part of the discussion. Obviously if you decide to stay out of the discussion, that doesn’t make you an opponent.

(I updated the opponents section Jun 4, 2014.)

The essence

The essence of #NoEstimates is in those stories that tell about the alternatives. Like:

• 'No Estimates' in Action: 5 Ways to Rethink Software Projects
• Use #NoEstimates to create options and deliver value reliably
• No Estimate Approach For End-Of-Life Legacy Support
• From schoolbook Scrum to Kanban without estimates
• Some of my blog posts, for example From #estwaste to #NoEstimates and Need to estimate.
• And many many more...

(Please propose a link, I can add it to this list.)

You can breath now

For those who find #NoEstimates frustrating, I’m hoping that you can breath better from now on. This is just a hashtag and it will never give you all the possible answers to your estimates related questions and problems. But if you are open-minded and willing to search for something better, there is a big and smart community available to help you.