Estimation: Assuming is good, we must assume as much as possible

 

Before continuing with more concrete examples of assumptions, I find it important to tell you that when I started in software development, I often encountered this situation:

Project Leader: The client said that feature XXX doesn't seem useful to them. They don't understand why we made it this way when they needed something else. 

Programmer: Well, I assumed that... 

Project Leader: Well, next time don't assume: ask! Programmer: Sorry, it won't happen again.

And a few days later:

Programmer: How should we make feature YYY? 

Client: Well, in such a way that we maximize efficiency and add value to the business... 

Programmer: Yes, but, is the relationship between products and orders one-to-many or many-to-many? Client: (What is this guy talking about?) Sorry, I have another meeting, we'll look at it later. 

Programmer: But but...

And finally:

Project Leader: The client said that feature YYY doesn't seem useful to them. They don't understand why we let them down again, they needed something else. 

Programmer: I did ask, really, but he only explained it very superficially. 

Project Leader: Well, next time, get detailed information. Programmer: Sorry, it won't happen again.

And so, always caught in the same loop, without control, sometimes doing well, sometimes not, depending on how much the programmer's intuition matched the client's reaction to the tested software.

Sadly, what the programmer learns after several such cycles is that assuming is bad. Wrong conclusion. Assuming is the best thing we can do at the start of a software project. Let's assume everything we can possibly assume. But let's be explicit about our assumptions.

Let's change the dialogue, negotiate differently, so it looks like this:

Programmer: How should we make feature ZZZ? 

Client: Well, in such a way that we maximize efficiency and add value to the business... 

Programmer: Here I have (many detailed and explicit assumptions) a prototype of the screen, here is my user story and I've already written some acceptance criteria, please give them your approval so I can start programming. 

Client: Ok, I'll review them later and let you know. 

Programmer: Perfect!

Of course, one of the most common problems we might encounter is that the client finally doesn't have time to review and never gives us approval or does give it, but without really reviewing the assumptions.

Project Leader: The client said that feature ZZZ doesn't seem useful to them. They don't understand why we made it this way if they needed something else. 

Programmer: Well, I delivered a prototype, the user story, and the acceptance criteria, and he gave approval, if you want we can review them to see if they correspond, but the Tester already has evidence that there is correspondence and all the bugs have been fixed. 

Project Leader: ... Well, we'll have to tell the client that if they want it different, they need to request a change.

This is the point we want to reach. Yes, the best we can do, the ideal that the agile movement aspires to, is to build what the client really needs, but often it is not achieved on the first attempt, because the first who doesn't clearly know what they need: is the client. And the technique to get there is assumptions. But explicit, visible, clear assumptions, if they are about screens, with prototypes, if they are batch processes, with examples of congruent input and output data.

The bad thing is not the assumptions, the bad thing is when we assume "in secret", without evidence, without giving visibility.

In the next part of this series, we will continue exploring more vaguely defined assumptions and how we can turn them into refutable, bounded assumptions, which, when violated (by the client), result in more work and paid time (remember, the goal is not to finish the project, software is like a plant, like a living being, the goal is to cultivate it, let it grow, mature, adding value to the client if possible, indefinitely).

We must strive to do the right thing, without forgetting to do it correctly.

Originally published in Javamexico

Estimation: Negotiation and the difference between doing the right thing vs. doing it right

In English, there's a saying: "There is a difference between doing the right thing and doing the thing right."

In software estimation, and the negotiation process necessary for a consultancy to build software for a client, the difference between one and the other is tremendously important.

To "do the right thing," we must clearly understand what the client really needs (regardless of what they ask for), whereas to "do it right," it's not relevant whether what we do will actually be useful to the client or not; what's important is whether what we did is well-built.

An extreme example:

A client comes to you and describes a single-passenger transport vehicle that allows them to travel anywhere. You build them a bicycle, but they were thinking of using the vehicle in Alaska, in the snow—they were looking for a snowmobile.

Ultimately, it doesn't matter how well you built the bicycle (done correctly) because it's not useful to the client since what they needed (doing the right thing) was for you to build them a snowmobile.

During the negotiation process carried out during the construction of software, the difference between "doing the right thing" and "doing it correctly" has an important peculiarity: Who has the information required to achieve one objective or the other changes drastically.

For "doing it correctly," all the knowledge is with the consultancy that builds the software, in the technicians, the developers, the designers, who, if they are good, will make the most usable screens, and will use the best architecture and algorithms, strictly adhering to a process that helps ensure a well-built product.

Conversely, for "doing the right thing," the information is with the client. Only they can, although often not at the beginning of the software development, determine if what is being built for them is ultimately what they need. Yes, and only if the client is willing to go through this process of self-discovery, in which their assumptions will be carefully examined, can they finally conclude whether that nebulous idea in their head is really what they need, or if instead, they should have asked for something else from the beginning.

Of course, the consultancy, with its analysts, developers, architects, testers, etc., must seek to facilitate dialogue with the client and help them quickly enter the cycle of assuming, implementing, validating, and re-assuming until they construct "the right thing," but it's important to remember that ultimately the information comes from the client, not the consultancy, and if the client, due to some problem of their organizational culture, is not willing to invest the time required to clearly define "the right thing," the consultancy will not be able to build it (you can lead a horse to water, but you can't make it drink).

There is a prayer that says "God, grant me the serenity to accept the things I cannot change, the courage to change the things I can change, and the wisdom to know the difference." Well, in this case, we need to be very clear about the difference: Only the client has the power to help us build "the right thing," the consultancy is just a facilitator, it's very important to remember this because when we are constructing the proposal, we must ensure it helps to build "the right thing," but at the same time, our responsibility must not go beyond "doing it correctly."

I have had to deal with multinationals, who give me just a few hours to prepare a proposal for months of development. The amount of effort wasted in such developments is absurd, and yet, it was useless for me to insist that 3 to 6 hours are not enough to estimate a project of 3 or 6 months duration, too much remains unspecified. At first, when I faced this situation, my attitude was "it can't be done," "avoid assuming," "ask the client for the missing information, or if not, do nothing." Sounds very nice from an abstract perspective, but that attitude doesn't pay the bills... so I changed it.

I still tell the client whenever I can that the time they are giving me is not sufficient, and that it is very risky to do a project with so little time to plan, but once the client indicates that my warnings are falling on deaf ears, I immediately change strategy: This client isn't interested in me "building the right thing," what they care about is having something built that "comes as close as possible to that," and I'd better "do it correctly," because in the end, if the approximation isn't close enough to what the client realizes they needed to receive (minutes after receiving it), recriminations and attempts at penalties will follow.

Fortunately, "doing the right thing" is subjective, whereas "doing it correctly" is completely objective. If you needed a snowmobile, and I built you a bicycle, and the very limited assumptions of the proposal are met by the bicycle, there will be no way for you to penalize me, or refuse to pay me, and in the event of a lawsuit, you will lose, because I will be fulfilling the contract.

The Agile Manifesto says "Customer collaboration over contract negotiation," which is another way of saying "prefer doing the right thing over doing it correctly," but the Agile Manifesto clarifies: "while there is value in the items on the right, we value the items on the left more." It's the same with "doing the right thing" vs. "doing it correctly," both are valuable, and certainly the best would be to do both, "the right thing, correctly," but we must have the wisdom to know the difference between what we can change... what is in our hands, and what is a shared effort, and that if the other party outright refuses to cooperate, it will not be possible to achieve.

It is very important to do this with a cool head and an enthusiastic and cheerful attitude. If a client is difficult in the first place, and we also treat them rudely, we will get nowhere; the warmth of kindness has more impact than the coldness of aggressiveness. As much as possible, we should seek common ground, empathize with the client, and move forward together, but we must also have clear boundaries drawn so that if things get out of control, we can cut cleanly, without irreparable losses to the continuity of our business, otherwise, we'd fall into Stockholm syndrome...

Don't miss the upcoming episodes of this exciting series on estimation, where we'll see different examples of real-life situations you might face, and how you can emerge victorious from them...

Update: I came across this article on InfoQ, which I see as very related to the topic I'm discussing here and I loved this example, so I take the opportunity to share it with you:

People buy a hammer to drive a nail to be able to hang a picture - they know they can achieve their goal (hang the picture) with the acquisition of the hammer.

Unfortunately, in the context of software development, things are not so straightforward between what is delivered (the software) and the business objective that is desired to be achieved. Many people do not even try to reach the business objective. This creates a significant risk that the provider only delivers what the client asked for - software that satisfies a vague set of requirements - instead of what the client really needs, which is to achieve their business objective.

Unfortunately, it is the same clients who tell the provider: Do exactly what I asked, stick to the contract, do it correctly, I have already decided that this was the right thing... without realizing the harm they are doing to themselves. As providers, we have the responsibility to ask: Why do you want me to make you a hammer? But if the client ultimately refuses to explain the purpose, we must accept that the client is ultimately responsible for their own well-being, and make their hammer, even if their plan is to hit themselves with it... imagine if knife manufacturers spent their time stressing about "what if someone cuts a finger," or stove manufacturers about "what if someone gets burned," practically all industries would end, since there is no limit to the misuse that can be given to things...

Clients are not children, and while we must clearly warn them of the consequences of their actions, the responsibility for their actions lies with them.

In the next part of this series, I will talk about techniques for dealing with performance requests (or demands) in situations where apparently there is not enough contextual information.

Originally published in Javamexico

Estimation: Is assuming the mother of all estimation errors? Or perhaps it is "to suppose"? Or maybe it is just our own ignorance?

I recently read a tweet that said:

Congratulations to "Assuming" for being the MOTHER OF ALL ESTIMATION ERRORS in software development!!!!

— SoftwareEvangelist (@vanessa_amaya) May 10, 2013

And I wondered: does the author realize... that she is assuming that assuming is the problem?

First, let's review the meaning of the word:

assume: assume. (From Lat. assumere).

1. tr. To take to oneself, to take for oneself.
2. tr. To take charge of something, to be responsible for it, to accept it.
3. tr. To acquire, to take on a greater form.

In software, the meaning we commonly use based on my experience is "To take charge, to be responsible for something, to accept it." What do we take responsibility for? The assumptions we use to build our estimate. Should we instead seek to be irresponsible? In my opinion, the problem is rather the assumptions themselves. If the assumptions do not align with reality, we end up delivering things poorly, for example in the scenario Ezamudio discussed in the previous post of this series, the problem escalated because the technician assumed he had chosen the correct part; in software development, it is more complicated, as there are several intertwined assumptions. But returning to the beginning, is assuming really the mother of all problems? No. Is supposing then the mother of all problems? I don't agree with that either, let's review the meaning of suppose:

suppose. (From Lat. supponere).

1. tr. To take for granted and existing something.
2. tr. To pretend, to give an ideal existence to what really does not have it.
3. tr. To entail, import. The new acquisition he has made implies excessive conservation expenses.
4. tr. To conjecture, to calculate something through the indications one has.
5. intr. To have representation or authority in a republic or in a community.

The meaning we commonly use in software, (at least those of us involved in its construction) is to conjecture, to calculate something through the indications one has, while we consider that the client sees it more as "To take for granted and existing something." Contradictory? Superficially, one might think so, but if examined more deeply, there is no contradiction. Supposing is a necessary something, we get out of bed, and we suppose we are awake, we drink water from the jar and suppose it is not toxic, we go out and drive to work and suppose it will be relatively safe. We do not have absolute certainty, but we also do not torment ourselves, we act taking it for granted, and if in the end the water or food causes us indigestion, we deal with it, if we start having indigestion several days in a row (if it does not kill us) we will change our diet and the water we drink. The same applies to software assumptions.

Supposing is a necessary activity in the scientific method (step 3):

1. Observation: Observing is applying the senses attentively to an object or a phenomenon, to study them as they really present themselves, which may be occasional or causal.
2. Induction: The action and effect of extracting, from certain observations or particular experiences, the particular principle of each one.
3. Hypothesis: Formulation through observation following the norms established by the scientific method. <---- ASSUMPTION!
4. Test the hypothesis by experimentation.
5. Demonstration or refutation (antithesis) of the hypothesis.
6. Thesis or scientific theory (conclusions).

Basically, we Observe, Analyze, Assume, and Test. If it works, we keep the assumption, if not, we repeat until we find the "correct" assumption. Now, this is the most important thing about the scientific method: We never reach the correct, the path to truth is like the limit in infinitesimal calculus, we are getting closer each time, but we never arrive.

The most important lesson of the scientific method is implicit: It's a Sand Mandala. Assumptions are made, only to be replaced by better ones. Thus, in software, assuming our assumptions are true is not a mistake, it's part of the method; the mistake comes when we forget that we are just at step 3, step 4 is still to come, where, without neglecting our responsibility, we test if our assumptions match reality. Therefore, assuming and supposing are not the mother of all problems, the mother is rather the lack of experimentation, and this lack of experimentation stems from treating assumptions incorrectly.

The first rule to follow for assumptions, again a rule from the scientific method, is that the assumption must be refutable (principle of falsifiability), what does this mean? There must be a concrete way, through a particular observation, to declare the assumption (provisionally) true or false. (An rrefutable assumption would be one that requires an exhaustive search of all possibilities to refute it). For example, I've been given RFPs to make systems that say "the system must implement all the relevant business rules for the business process to be automated" and then, nothing, no list of which rules are. Demonstrating whether we are meeting or not meeting that assumption cannot be refuted, the list of rules is potentially infinite (and clients certainly take advantage of that). What can we do?

When I was younger, what I used to do was demand the list of rules, or say that I couldn't do anything and refuse to estimate the time that would be necessary. Needless to say, that attitude only got me into trouble with my bosses, lost business, and dissatisfied clients. Although that's the path indicated in estimation books, it's not the correct path in the real world.

Of course, there are clients who are willing to give you the list of rules, so when you're in this situation, don't fail to ask for the list, but if they can't (or won't) give it to you, don't suffer, accept it, and continue... but cautiously. A few months ago, I watched a nascent consultancy suffer a horrible death and enter zombie mode: they sold a system with open-ended assumptions, according to them, it was going to be finished in 2 weeks; when I met them, they had been working for free for the government for a year, under threat of a lawsuit for breach of contract if they were to "crack" and not finish implementing all the rules that the client might think of. I couldn't help them anymore, what they needed was a good lawyer. How then to avoid falling into that hole?

Some would say: Simply reject the business. Yes, it sounds nice when you have a lot of money, have no responsibilities, and if you don't receive income you're the only one who doesn't eat. But what if your family depends on you? Can you really afford to reject the work? Of course not. Don't reject it then, nor tire yourself explaining why you can't "implement all the relevant business rules for the business process to be automated", the right answer is: define the scope yourself.

Place an assumption in your proposal in the following way: "It is assumed that these business rules will not exceed 10. It is assumed that the list of all business rules to be implemented will be received X days after the project has started. The rules must be defined as algorithmic step-by-step procedures, each consisting of no more than 10 CFP (Cosmic Function Points according to the standard ISO/IEC 14143/1:2003). It is assumed that all the information to be used by the business rules is that which is fed into the system through the user stories defined in the scope section of this proposal. If the list of business rules is not received at that time, or if a greater number of rules are received, the scope change procedure described in this document will be executed, which may have an impact on the project times and costs." There, you've defined the scope.

By doing this, essentially you are answering the question that some clients would surely ask you when you told them that you couldn't "implement all the relevant business rules for the business process to be automated". Some clients would ask: Why not? And you would tell them: Because I don't know how many there are, nor how complex they are, and you're only giving me 3 months to do them. Well, the client would say: How many can you do in 3 months?

And there is where, when I was younger, I would clash most strongly with reality: I simply couldn't answer that question! I could only say "because not", when the right answer is to say "as if". This is not a silver bullet, there will be clients who are not willing to accept a defined scope. In those cases, if the client is not willing to pay for time and materials, then yes, the right answer is thanks, but no thanks, I can't do the project.

In the next part of this series, we will delve into the benefits of assuming, and why the myth has been generated that one should not assume.

 Originally published in Javamexico

Estimation: Why do we do it?

 

There are those who consider that estimating is impossible and a waste of time, a useless endeavor. There are those who believe it can be done, but only under certain conditions, and there are those who think that the secret lies in following a certain method... However, before discussing these points of view, I want to focus on a question often omitted in articles and books on estimation:

Why do we estimate? And I'm not talking about the theoretical reasons typically used in books on the subject, but rather, out there, in the real world. I don't want to generalize, so what I will say next is strictly based on my own experience.

We don't estimate to know how long the project will take; the client usually has already set a deadline that is unlikely to change.

Why do we estimate then? We estimate to see if we can do something within the time and budget that are already established and that sounds to the client like what they asked for (because if one thing is certain, it's that most clients don't really know what they want until they've seen a couple of progress demos).

The agile community tells us: don't estimate, do everything by time and materials, although in reality what it's saying is "don't estimate beyond the next sprint" and "lose any client who is only willing to buy projects at a fixed cost and time." It would be nice if the world were that easy, but the fact is that it's not: most of the clients I've encountered in the consulting world want a budget upfront... Those of us who would like everyone to understand Scrum sometimes find it absurd, a display of their ignorance some say, but let's put ourselves in their shoes: who, when taking their car to the shop, expects to be told: we're going to fix your car iteratively, give us your bank card with an open voucher and then check your balance to see how much it was at the end...

And yet we go to the doctor, and while each visit may have a fixed cost, we don't ask the doctor to give us the cost of the medicines before diagnosing us, nor do we force them to tell us the maximum number of consultations we'll need... Medical treatment is completely iterative... Maybe one day we'll recognize the similarities between curing the most sophisticated biological system we know and creating or composing new systems... In the meantime, let's think... Why are there fixed-cost projects that do work? The level of uncertainty clearly visible to the educated mind at the start of the project should guarantee that this never happens... What's different in those projects? Maybe it's not obvious, but in my experience, it's quite simple: the scope was better defined, either because the client themselves had already done some pre-analysis, or because the consulting team did the same... SACRILEGE! Am I daring to say that the correct way to carry out a project is with Waterfall?

NO! To believe that is to ignore the principle of diminishing returns: those who believe that this indicates Waterfall is the answer are making the mistake of thinking that if some analysis is better than none, then double or quadruple the analysis will bring a benefit directly proportional. Well, welcome to the real world: things don't work like that, if you do a lot of analysis, you also consume a lot of time and while your understanding of the situation becomes more precise, it also becomes progressively outdated... The world doesn't stop changing because you analyze a particular point of it in time and by the time you turn to compare your analysis with the current reality, the world has already changed: the conclusions of your analysis are now obsolete.

Zero analysis? Bad. Exhaustive analysis? Bad... What to do then? Find out how much is "enough" but first understand enough for what? Many books on estimation talk about achieving 75% accuracy, as the ultimate goal of a well-done estimate. In my experience, that perception is wrong. What good does it tell a client: to succeed in what you're asking, I need one million pesos, if the client only has (or claims to have) a third of that? It's no use, the client won't have their product, and we won't have our project. What to do then?

Look for the "as if," the first time I heard that phrase it seemed naive: do a one million project for a third? Impossible! But then it happened that some people asked me: why? And I complicated my life giving a thousand explanations about the complexities that are part of software development (many of which I didn't understand then... and many of which I still don't fully understand now) and... I couldn't convince them, and ended up trapped in horrendous Dead March projects from which I not only received pressure from the client, desperate because the project was nowhere near completion by the deadline, but also from the company I worked for, equally desperate as the project's margin eroded away...

And after finishing that project, we embarked on another just like it... How do we break that cycle? Is  it true, as I recently read on Twitter, that assuming is the mother of all problems in system development. I will talk about that in my next post...

 Originally published in Javamexico