0:00:05.200,0:00:10.080
So once again it's a pleasure to be 
here Greg, thank you for inviting me,

0:00:10.880,0:00:14.560
it's a great opportunity to be in this event.

0:00:14.560,0:00:20.560
So today I will talk about a report that 
I conducted with some colleagues from

0:00:20.560,0:00:26.960
Federal University of Amazon, and it's about 
padding and negotiation and software estimates.

0:00:27.600,0:00:31.920
So it's well - it's well 
known in software engineering,

0:00:31.920,0:00:41.200
stakeholders take the effort needed to execute 
a task, as well a project, or to to predict the

0:00:41.200,0:00:47.520
value that can be delivered to the customer, so 
they can have the outcome that they are expecting.

0:00:48.320,0:00:53.840
The estimators, they bring this perspective 
about the factors that would affect

0:00:53.840,0:01:00.800
somehow the estimates, looking for improving 
the accuracy when they are discussing how much

0:01:00.800,0:01:05.920
effort and how much time they will need to 
put - they will need to take to develop what

0:01:05.920,0:01:11.200
they - what they need for the next release.
It's important to understand here that

0:01:11.200,0:01:17.440
this estimation process, it happens in social 
settings, and as everything that I do, it

0:01:17.440,0:01:24.400
involves something related to behavior and social 
aspects inside of software engineering process.

0:01:24.400,0:01:28.320
So why is this social?
Because it involves

0:01:28.320,0:01:35.520
not only people working on that but also the 
context where they are, they are immersed in..

0:01:35.520,0:01:42.400
So the literature about estimates is extensive.
So we can find things from

0:01:43.280,0:01:48.720
the 70s until like papers from last 
week talking about software estimates.

0:01:48.720,0:01:55.760
And what we found when looking into the literature 
is that there is a broad range of factors

0:01:55.760,0:02:03.600
affecting estimations, from in fact from early 
estimation, so at the beginning of the project

0:02:03.600,0:02:09.680
they have early estimation - estimates coming 
in, and this is taken into account when they

0:02:09.680,0:02:14.240
are defining the estimates for the next release 
or the next sprint, whatever you - you call it,

0:02:16.320,0:02:25.360
until things related to changes in requirements, 
change in scope, the project flexibility, etc.

0:02:25.360,0:02:30.080
And this goes through a lot of - a lot of stuff 
that happens in the project, like when when

0:02:30.080,0:02:34.640
you're estimating, you're executing, performing 
this - estimation, this estimation process.

0:02:36.320,0:02:43.200
And in this point, we have a bunch of social 
things happening, contextual things happening,

0:02:43.200,0:02:48.240
which includes for example pressure from 
high management, from clients, from the PO.

0:02:48.800,0:02:55.120
It includes the team itself, how is the 
relationship between the team's expertise,

0:02:55.120,0:02:57.360
seniority where these people are coming from,

0:02:57.360,0:03:03.840
so there are multiple kinds of factors 
affecting the way that people estimate software.

0:03:05.840,0:03:15.520
To better understand this phenomenon in a more 
recent fashion, we conducted some observation

0:03:15.520,0:03:21.120
studies and a couple of interviews - a few 
interviews with people from different countries,

0:03:21.120,0:03:25.600
different companies, different teams.
We took like three months observing

0:03:27.200,0:03:32.880
four different teams during their estimate 
sessions, and our goal was to understand

0:03:33.520,0:03:39.600
how software estimates were used to establish 
common commitments regarding the business values.

0:03:39.600,0:03:45.360
So we just wanted to understand like, 
what's - what's tying these two things -

0:03:45.360,0:03:50.640
the estimates and what is being delivered, what 
has been - what the team is being committed to do.

0:03:51.360,0:04:00.000
And it ended up that we found out that estimate 
negotiation and padding were key things

0:04:00.000,0:04:04.000
happening in the process.
So it was quite impressive

0:04:04.000,0:04:09.200
the number of things that we could tie to 
negotiation and padding during this process.

0:04:10.720,0:04:16.880
So what we see is that - what he saw is that the 
teams that we analyzed and the people that we

0:04:16.880,0:04:23.200
talked to after, because we talked to many more 
people from three different companies later on,

0:04:23.200,0:04:30.480
is that all of them follow some kind of 
agile practices, like planning poker-based

0:04:30.480,0:04:39.200
estimates, where people come with estimates 
from the team, so they discuss the task and

0:04:40.480,0:04:46.960
each of the members comes up with an estimation, 
and they discuss to - to come to a consensus.

0:04:47.840,0:04:52.480
Okay, and each of the teams has a different 
kind of resolution strategy when you have,

0:04:52.480,0:04:59.760
like, disagreements in terms of estimates.
But at the end of the day, what what we

0:04:59.760,0:05:04.800
understood is that the PO and team lead 
just want to know the arguments that they

0:05:04.800,0:05:10.720
need to have to discuss it with the - the next 
layer, with higher management or the client.

0:05:10.720,0:05:17.040
So they are seeking to understand how they can 
build commitment bringing the arguments that

0:05:17.040,0:05:24.640
the developers are bringing - are bringing them.
And interestingly some people do not even argue.

0:05:25.200,0:05:29.280
Some people, depending on what 
are the other people that are

0:05:30.480,0:05:36.560
estimating and what the PO has to say, they 
don't even disagree, they just gonna say, okay,

0:05:36.560,0:05:42.880
I can change my my estimates if this is better.
So sometimes what we saw is that there is a

0:05:42.880,0:05:47.280
a kind of power relationship going on.
It's like okay, we need to deliver this

0:05:47.280,0:05:53.600
by next week, so if we don't - if we don't 
change the estimates we'll not be able to do.

0:05:53.600,0:05:57.280
Or sometimes there's a very 
senior person who's like, okay,

0:05:57.280,0:06:03.200
this is quite hard and I know that it's hard 
and some some other people who are more junior,

0:06:03.920,0:06:09.120
they will just accept, so without 
arguing against or in favor of something.

0:06:09.920,0:06:18.560
So the way that estimators defend is quite 
important because this is what is giving

0:06:19.440,0:06:26.320
the - the ammo for the next layers, and we saw 
that, at the end of the estimation process,

0:06:26.320,0:06:30.960
we talked it to the POs and other layers 
to understand, like, what was going on.

0:06:30.960,0:06:35.760
And we saw that there was kind of a 
mismatch, and each layer have their own goals

0:06:37.600,0:06:44.080
with what was going on in the estimation process.
So one thing that we noticed, that they

0:06:44.080,0:06:46.800
played by the book when we were 
talking about project management.

0:06:47.520,0:06:54.800
As you know that risk management is something 
important, and in order to better manage the risk,

0:06:55.680,0:07:01.920
it's common to bet a little bit.
So we have a contingency buffer, sometimes,

0:07:01.920,0:07:06.720
like, as you can see here in the examples, 
when we cannot define the feature very well,

0:07:07.440,0:07:12.560
when there are some hidden aspects that we don't 
know about, it's a different API that we need

0:07:12.560,0:07:18.560
to consume, all right, we don't know which what 
kinds of problems we have to face in this release.

0:07:19.520,0:07:23.200
So this is a common - and this 
is completely understandable.

0:07:24.080,0:07:30.320
However what caught our attention 
is that we are doing more than that.

0:07:32.160,0:07:35.280
For every - everything that 
we talked to and observed,

0:07:35.280,0:07:39.520
we could see that we are doing different 
- different things that result in padding

0:07:40.160,0:07:48.400
and quite often - and what we are doing is 
actually hiding details from the next level.

0:07:48.400,0:07:54.000
So for example we found a couple of 
cases where people just said like, okay,

0:07:54.000,0:07:57.840
we could not finish what we promised in the 
previous release in the previous sprint,

0:07:58.400,0:08:03.920
so we'll just add some more time here to this 
task so we are able to finish something else.

0:08:04.480,0:08:11.920
Or we need to adjust whatever - whatever it 
is in the UI from the previous feature that

0:08:11.920,0:08:16.960
they delivered, so let's just add 
something here so we can do that.

0:08:16.960,0:08:23.040
Now we need to set up a new server, so why not 
adding some time to this - this and these tasks.

0:08:24.000,0:08:30.400
And also things relate to related to technical 
debt, for example, or improving the overall

0:08:30.400,0:08:36.800
quality, maintainability of the process.
So it was quite usual to hear like, okay,

0:08:36.800,0:08:40.320
let's do this because we need to 
refactor a couple of artifacts,

0:08:41.040,0:08:44.080
so let's just add some time 
here add some effort there.

0:08:46.560,0:08:53.600
What - what is behind that, like, 
everybody is hiding from the next level

0:08:53.600,0:09:01.200
just because they need to deliver something that 
is not a direct kind of benefit or business value

0:09:01.200,0:09:07.600
that can be easily shown to the customer.
So what I've learned here is that padding is

0:09:07.600,0:09:14.240
used in the right way in many many cases, but it's 
sometimes used as a social way of hiding things.

0:09:16.000,0:09:24.560
So people just lie informally to make things fit 
because they know that there are other things that

0:09:24.560,0:09:31.200
they can do and everybody who is listening here, 
who is watching to this talk should be like, okay,

0:09:31.200,0:09:36.400
we do that it's common, yeah it's common, 
but it's kind of a bad smell if we think

0:09:36.400,0:09:44.240
about the process - of the software process.
And accuracy is in harm when you think about that

0:09:44.240,0:09:50.400
because we don't know exactly what we are doing, 
and we don't know exactly how our team performs.

0:09:52.400,0:09:56.480
What do we need to do?
We need to sell everything as business value,

0:09:56.480,0:10:04.000
and this needs to come from the bottom.
So we need to expose the reasons as estimators,

0:10:04.000,0:10:08.480
as developers, say, like what are 
we doing, are we refactoring, are

0:10:08.480,0:10:14.800
we improving maintainability, what are we doing?
And in the next level, like PO level, team leader

0:10:14.800,0:10:20.160
level, we need to describe these reasons that 
developers gave us as somehow customer value.

0:10:20.160,0:10:24.640
So in the next release this will be something 
better, we will improve our performance,

0:10:25.200,0:10:32.800
the - the product will have a better performance.
And for the next the last level of management,

0:10:32.800,0:10:37.440
when we're in touch with the client, we need to 
educate them - that there are some things that are

0:10:37.440,0:10:45.680
not exactly new features, that are not exactly 
direct benefits to the product as they see,

0:10:45.680,0:10:50.480
but it's something related to the process 
that will make it better from that moment on.

0:10:53.840,0:10:59.840
I hope you liked that and thank you very 
much again Greg and Mike for inviting me.