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
No comments:
Post a Comment