[teampractices] Saw a presentation by Allen Holub

Discussion:

Max Binder

2016-09-21 20:29:00 UTC

I attended a Meetup last night, via Bay Area Agile Leadership Network.

Don't have Allen's deck, but here is his website with a lot of the same:
http://holub.com/

TL;DR: His presentation was about how estimation is bad (among other
things, he argues that estimating is unethical). I felt it was a fairly
aggro presentation (full disclosure: I'm pro-estimation), but under the
veil of what I observed as an extremist view of Agile was a message
promoting Agile as a state of mind, rather than a
panacea-by-rigid-structure, all too often deployed by "Agile" companies.

He also showed burnup charts (he didn't call them that) very similar to
those on phlogiston.wmflabs.org.

Joel Aufrecht

2016-09-21 21:38:52 UTC

Permalink

Interesting. I just finished Steve McConnell's response to #NoEstimates,
17_Theses_on_Software_Estimation_(Expanded)
<http://www.construx.com/10x_Software_Development/17_Theses_on_Software_Estimation_%28Expanded%29/>
.

The most essential of those theses might be:

*5. Estimates serve numerous legitimate, important business purposes.*
âI think the #NoEstimates response to that is, estimation doesn't work, so
even if estimates would be nice, estimation doesn't actually provide them.

McConnell's response is basically, estimation does work if you know what
you're doing and do it right.

*1. Estimation is often done badly and ineffectively and in an overly

time-consuming way.*
*2. The root cause of poor estimation is usually lack of estimation
skills.*)

And also that Scrum is actually very compatible with estimation, and that
discussions should be pragmatic and not dogmatic:

*14. Scrum provides better support for estimation than waterfall ever did,

and there does not have to be a trade off between agility and
predictability. *
*16. This is not religion. We need to get more technical and more economic
about software discussions. *

â

What did he call his burnup charts (charts that, by the way, support
estimation at a glance)?

*-- Joel Aufrecht*
Team Practices Group
Wikimedia Foundation

I attended a Meetup last night, via Bay Area Agile Leadership Network.
http://holub.com/
TL;DR: His presentation was about how estimation is bad (among other
things, he argues that estimating is unethical). I felt it was a fairly
aggro presentation (full disclosure: I'm pro-estimation), but under the
veil of what I observed as an extremist view of Agile was a message
promoting Agile as a state of mind, rather than a
panacea-by-rigid-structure, all too often deployed by "Agile" companies.
He also showed burnup charts (he didn't call them that) very similar to
those on phlogiston.wmflabs.org.
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices

Joel Aufrecht

2016-09-21 21:49:55 UTC

Permalink

I skimmed through his #NoEstimates video until I saw burnup charts:

His argument seems to be (and I'm not watching the whole 40 minutes so I
could be going out of context) that you can do projections from burnups and
use that instead of estimation. "Now I guess this is estimating but it's
not really estimating, all we are doing is counting."

It sounds like he's opposed to a particular kind of estimation, in favor of
another kind of estimation, and perhaps using a bit of hyperbole as a
marketing tool.

*-- Joel Aufrecht*
Team Practices Group
Wikimedia Foundation

Post by Joel Aufrecht
Interesting. I just finished Steve McConnell's response to #NoEstimates,
17_Theses_on_Software_Estimation_(Expanded)
<http://www.construx.com/10x_Software_Development/17_Theses_on_Software_Estimation_%28Expanded%29/>
.
*5. Estimates serve numerous legitimate, important business purposes.*
âI think the #NoEstimates response to that is, estimation doesn't work, so
even if estimates would be nice, estimation doesn't actually provide them.
McConnell's response is basically, estimation does work if you know what
you're doing and do it right.
*1. Estimation is often done badly and ineffectively and in an overly

time-consuming way.*
*2. The root cause of poor estimation is usually lack of estimation
skills.*)

And also that Scrum is actually very compatible with estimation, and that
*14. Scrum provides better support for estimation than waterfall ever did,

and there does not have to be a trade off between agility and
predictability. *
*16. This is not religion. We need to get more technical and more
economic about software discussions. *

â
What did he call his burnup charts (charts that, by the way, support
estimation at a glance)?
*-- Joel Aufrecht*
Team Practices Group
Wikimedia Foundation

Kevin Smith

2016-09-21 23:18:59 UTC

Permalink

Thanks for sharing, Max and Joel!

tl;dr of my own reactions and beliefs: Holub and McConnell each have some
valid points, and I substantially disagree with both of them on several
points. Estimates are often abused by managers. Task estimation is not
inherently useless. Task estimation is a skill that developers can (and
arguably should) build. Software development is a craft (not engineering,
science, or art). Comprehensive up-front requirements-gathering is
generally impossible (and counter-productive). I value agility over
predictability.

Ok, here's the wall of text for those who want more than just a sound bite.
This seems to have struck some nerves. :)

I am in neither camp--I see value in estimates for some teams, and not for
others

To get Holub's views, I watched the #NoEstimates video on his site. He is
clearly extremist, and seems to be arguing against something that nobody is
actually arguing in favor of. Just because some bosses treat estimates as
commitments doesn't mean all estimates are bad. It's either bad
communication and/or bad management.

Even if estimation is useless for forecasting (which is debatable), it can
be valuable as a tool for developers to really understand what it is that
they're about to work on. Even inaccurate estimates are also helpful to
product owners to be able to prioritize work. "Valuable and easy" has a
better ROI than "valuable and hard".

His jibe that the only thing managers do is enforce a schedule was
frustrating. Good managers *already* support their direct reports, rather
than commanding them.

As Joel pointed out, Holub's discussion of projections based on burnup
charts is odd. But it makes more sense if you understand his main point,
which is: "projections (based on task counts) are good and necessary;
estimates are harmful waste".

He uses burnup charts to "prove" that projections based on story points are
no better than projections based on task counts. But this data came from a
team that did story point estimation, which means they thought through the
stories to a degree, which also probably means the stories are decomposed
to a reasonable level. Without those steps, the tasks would probably vary
in size more, and the graphs probably wouldn't align as well.

As for the McConnell essay...

I used to be a big fan of McConnell, back in the day. But he remains rooted
in the pre-agile ways, despite his embracing some aspects of agile. As one
example, he refers to software development as "engineering", whereas I
firmly believe that it is a craft. It is not engineering, nor science. Nor
is it art. To write excellent software in most domains requires skill and
knowledge, AND creativity and soft skills. Sure, cranking out yet another
e-commerce website might be fairly rote these days. But that's not what
most software developers are doing, and it's certainly not what most want
to be doing. Software development is not an assembly line.

McConnell's customers apparently value predictability over agility. What
that means is that when the project wraps up a year from now, they would
rather have what they thought they wanted when the project started than
what they now realize at the end that they actually want. I believe that is
the reality in a lot of contexts (e.g. corporate work), but certainly not
ours, and I would argue that it is not in most.

McConnell also seems to believe you can gather requirements up front. As he
says: âThe typical software project has requirements that are knowable in
principle, but that are mostly unknown in practice due to insufficient
requirements skills".

I strongly disagree with that, because I believe that for most projects,
you can't possibly predict the actual requirements until you have built
something and started the feedback loop. You won't learn the final
requirement until the day the project ends (at which point there will be a
large pile of requirements which were not built).

I agree with McConnell that task estimation is a skill that most developers
haven't built up, but most could. It's a skill I developed with practice,
and I have helped a couple other developers build it up as well. You'll
never get to the point of perfect accuracy, but "good enough" estimation is
definitely a realistic goal, and can be valuable.

However, I think I disagree with McConnell (and Holub) that *project* level
estimation (or "projection", as Holub prefers) is easy. New requirements
can show up in lumps at various times, in addition to some tasks being
easier or harder than expected. I think that you can accurately predict the
time, scope, cost, or quality of a project. Probably 2 of those for the
same project. Certainly not all 4.

Kevin Smith
Agile Coach, Wikimedia Foundation

Post by Joel Aufrecht
http://youtu.be/QVBlnCTu9Ms
His argument seems to be (and I'm not watching the whole 40 minutes so I
could be going out of context) that you can do projections from burnups and
use that instead of estimation. "Now I guess this is estimating but it's
not really estimating, all we are doing is counting."
It sounds like he's opposed to a particular kind of estimation, in favor
of another kind of estimation, and perhaps using a bit of hyperbole as a
marketing tool.
*-- Joel Aufrecht*
Team Practices Group
Wikimedia Foundation

Post by Joel Aufrecht
Interesting. I just finished Steve McConnell's response to #NoEstimates,
17_Theses_on_Software_Estimation_(Expanded)
<http://www.construx.com/10x_Software_Development/17_Theses_on_Software_Estimation_%28Expanded%29/>
.
*5. Estimates serve numerous legitimate, important business purposes.*
âI think the #NoEstimates response to that is, estimation doesn't work,
so even if estimates would be nice, estimation doesn't actually provide
them.
McConnell's response is basically, estimation does work if you know what
you're doing and do it right.
*1. Estimation is often done badly and ineffectively and in an overly

time-consuming way.*
*2. The root cause of poor estimation is usually lack of estimation
skills.*)

And also that Scrum is actually very compatible with estimation, and that
*14. Scrum provides better support for estimation than waterfall ever

did, and there does not have to be a trade off between agility and
predictability. *
*16. This is not religion. We need to get more technical and more
economic about software discussions. *

â
What did he call his burnup charts (charts that, by the way, support
estimation at a glance)?
*-- Joel Aufrecht*
Team Practices Group
Wikimedia Foundation

_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices

Max Binder

2016-09-21 23:29:09 UTC

Permalink

Kevin:

You summed up a lot of what I felt but couldn't express because I didn't
know where to start. :)

Thanks for the essays. It's ironic that these two leaders in the Agile
space also represent different ends of the spectrum of what happens when
you over-engineer process and lose sight of the people involved, and the
nuance generally helpful when supporting those people.

Joel:

It sounds like he's opposed to a particular kind of estimation, in favor of

Post by Joel Aufrecht
another kind of estimation, and perhaps using a bit of hyperbole as a
marketing tool.

Yes. He was also selling his book last night, so marketing hyperbole sounds
about right. It mostly came off as bullying to me. :-/

Post by Joel Aufrecht
Thanks for sharing, Max and Joel!
tl;dr of my own reactions and beliefs: Holub and McConnell each have some
valid points, and I substantially disagree with both of them on several
points. Estimates are often abused by managers. Task estimation is not
inherently useless. Task estimation is a skill that developers can (and
arguably should) build. Software development is a craft (not engineering,
science, or art). Comprehensive up-front requirements-gathering is
generally impossible (and counter-productive). I value agility over
predictability.
Ok, here's the wall of text for those who want more than just a sound
bite. This seems to have struck some nerves. :)
I am in neither camp--I see value in estimates for some teams, and not for
others
To get Holub's views, I watched the #NoEstimates video on his site. He is
clearly extremist, and seems to be arguing against something that nobody is
actually arguing in favor of. Just because some bosses treat estimates as
commitments doesn't mean all estimates are bad. It's either bad
communication and/or bad management.
Even if estimation is useless for forecasting (which is debatable), it can
be valuable as a tool for developers to really understand what it is that
they're about to work on. Even inaccurate estimates are also helpful to
product owners to be able to prioritize work. "Valuable and easy" has a
better ROI than "valuable and hard".
His jibe that the only thing managers do is enforce a schedule was
frustrating. Good managers *already* support their direct reports, rather
than commanding them.
As Joel pointed out, Holub's discussion of projections based on burnup
charts is odd. But it makes more sense if you understand his main point,
which is: "projections (based on task counts) are good and necessary;
estimates are harmful waste".
He uses burnup charts to "prove" that projections based on story points
are no better than projections based on task counts. But this data came
from a team that did story point estimation, which means they thought
through the stories to a degree, which also probably means the stories are
decomposed to a reasonable level. Without those steps, the tasks would
probably vary in size more, and the graphs probably wouldn't align as well.
As for the McConnell essay...
I used to be a big fan of McConnell, back in the day. But he remains
rooted in the pre-agile ways, despite his embracing some aspects of agile.
As one example, he refers to software development as "engineering", whereas
I firmly believe that it is a craft. It is not engineering, nor science.
Nor is it art. To write excellent software in most domains requires skill
and knowledge, AND creativity and soft skills. Sure, cranking out yet
another e-commerce website might be fairly rote these days. But that's not
what most software developers are doing, and it's certainly not what most
want to be doing. Software development is not an assembly line.
McConnell's customers apparently value predictability over agility. What
that means is that when the project wraps up a year from now, they would
rather have what they thought they wanted when the project started than
what they now realize at the end that they actually want. I believe that is
the reality in a lot of contexts (e.g. corporate work), but certainly not
ours, and I would argue that it is not in most.
McConnell also seems to believe you can gather requirements up front. As
he says: âThe typical software project has requirements that are knowable
in principle, but that are mostly unknown in practice due to insufficient
requirements skills".
I strongly disagree with that, because I believe that for most projects,
you can't possibly predict the actual requirements until you have built
something and started the feedback loop. You won't learn the final
requirement until the day the project ends (at which point there will be a
large pile of requirements which were not built).
I agree with McConnell that task estimation is a skill that most
developers haven't built up, but most could. It's a skill I developed with
practice, and I have helped a couple other developers build it up as well.
You'll never get to the point of perfect accuracy, but "good enough"
estimation is definitely a realistic goal, and can be valuable.
However, I think I disagree with McConnell (and Holub) that *project*
level estimation (or "projection", as Holub prefers) is easy. New
requirements can show up in lumps at various times, in addition to some
tasks being easier or harder than expected. I think that you can accurately
predict the time, scope, cost, or quality of a project. Probably 2 of those
for the same project. Certainly not all 4.
Kevin Smith
Agile Coach, Wikimedia Foundation

Post by Joel Aufrecht
Interesting. I just finished Steve McConnell's response to
#NoEstimates, 17_Theses_on_Software_Estimation_(Expanded)
<http://www.construx.com/10x_Software_Development/17_Theses_on_Software_Estimation_%28Expanded%29/>
.
*5. Estimates serve numerous legitimate, important business purposes.*
âI think the #NoEstimates response to that is, estimation doesn't work,
so even if estimates would be nice, estimation doesn't actually provide
them.
McConnell's response is basically, estimation does work if you know what
you're doing and do it right.
*1. Estimation is often done badly and ineffectively and in an overly

time-consuming way.*
*2. The root cause of poor estimation is usually lack of estimation
skills.*)

And also that Scrum is actually very compatible with estimation, and
*14. Scrum provides better support for estimation than waterfall ever

did, and there does not have to be a trade off between agility and
predictability. *
*16. This is not religion. We need to get more technical and more
economic about software discussions. *

â
What did he call his burnup charts (charts that, by the way, support
estimation at a glance)?
*-- Joel Aufrecht*
Team Practices Group
Wikimedia Foundation

_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices

Arthur Richards

2016-09-22 16:07:34 UTC

Permalink

Quick drive-by response: I am psyched to see this conversation on this list
:)

Post by Max Binder
You summed up a lot of what I felt but couldn't express because I didn't
know where to start. :)
Thanks for the essays. It's ironic that these two leaders in the Agile
space also represent different ends of the spectrum of what happens when
you over-engineer process and lose sight of the people involved, and the
nuance generally helpful when supporting those people.
It sounds like he's opposed to a particular kind of estimation, in favor

Post by Joel Aufrecht
of another kind of estimation, and perhaps using a bit of hyperbole as a
marketing tool.

Yes. He was also selling his book last night, so marketing hyperbole
sounds about right. It mostly came off as bullying to me. :-/

Post by Joel Aufrecht
Thanks for sharing, Max and Joel!
tl;dr of my own reactions and beliefs: Holub and McConnell each have some
valid points, and I substantially disagree with both of them on several
points. Estimates are often abused by managers. Task estimation is not
inherently useless. Task estimation is a skill that developers can (and
arguably should) build. Software development is a craft (not engineering,
science, or art). Comprehensive up-front requirements-gathering is
generally impossible (and counter-productive). I value agility over
predictability.
Ok, here's the wall of text for those who want more than just a sound
bite. This seems to have struck some nerves. :)
I am in neither camp--I see value in estimates for some teams, and not
for others
To get Holub's views, I watched the #NoEstimates video on his site. He is
clearly extremist, and seems to be arguing against something that nobody is
actually arguing in favor of. Just because some bosses treat estimates as
commitments doesn't mean all estimates are bad. It's either bad
communication and/or bad management.
Even if estimation is useless for forecasting (which is debatable), it
can be valuable as a tool for developers to really understand what it is
that they're about to work on. Even inaccurate estimates are also helpful
to product owners to be able to prioritize work. "Valuable and easy" has a
better ROI than "valuable and hard".
His jibe that the only thing managers do is enforce a schedule was
frustrating. Good managers *already* support their direct reports, rather
than commanding them.
As Joel pointed out, Holub's discussion of projections based on burnup
charts is odd. But it makes more sense if you understand his main point,
which is: "projections (based on task counts) are good and necessary;
estimates are harmful waste".
He uses burnup charts to "prove" that projections based on story points
are no better than projections based on task counts. But this data came
from a team that did story point estimation, which means they thought
through the stories to a degree, which also probably means the stories are
decomposed to a reasonable level. Without those steps, the tasks would
probably vary in size more, and the graphs probably wouldn't align as well.
As for the McConnell essay...
I used to be a big fan of McConnell, back in the day. But he remains
rooted in the pre-agile ways, despite his embracing some aspects of agile.
As one example, he refers to software development as "engineering", whereas
I firmly believe that it is a craft. It is not engineering, nor science.
Nor is it art. To write excellent software in most domains requires skill
and knowledge, AND creativity and soft skills. Sure, cranking out yet
another e-commerce website might be fairly rote these days. But that's not
what most software developers are doing, and it's certainly not what most
want to be doing. Software development is not an assembly line.
McConnell's customers apparently value predictability over agility. What
that means is that when the project wraps up a year from now, they would
rather have what they thought they wanted when the project started than
what they now realize at the end that they actually want. I believe that is
the reality in a lot of contexts (e.g. corporate work), but certainly not
ours, and I would argue that it is not in most.
McConnell also seems to believe you can gather requirements up front. As
he says: âThe typical software project has requirements that are knowable
in principle, but that are mostly unknown in practice due to insufficient
requirements skills".
I strongly disagree with that, because I believe that for most projects,
you can't possibly predict the actual requirements until you have built
something and started the feedback loop. You won't learn the final
requirement until the day the project ends (at which point there will be a
large pile of requirements which were not built).
I agree with McConnell that task estimation is a skill that most
developers haven't built up, but most could. It's a skill I developed with
practice, and I have helped a couple other developers build it up as well.
You'll never get to the point of perfect accuracy, but "good enough"
estimation is definitely a realistic goal, and can be valuable.
However, I think I disagree with McConnell (and Holub) that *project*
level estimation (or "projection", as Holub prefers) is easy. New
requirements can show up in lumps at various times, in addition to some
tasks being easier or harder than expected. I think that you can accurately
predict the time, scope, cost, or quality of a project. Probably 2 of those
for the same project. Certainly not all 4.
Kevin Smith
Agile Coach, Wikimedia Foundation

Post by Joel Aufrecht
Interesting. I just finished Steve McConnell's response to
#NoEstimates, 17_Theses_on_Software_Estimation_(Expanded)
<http://www.construx.com/10x_Software_Development/17_Theses_on_Software_Estimation_%28Expanded%29/>
.
*5. Estimates serve numerous legitimate, important business purposes.*
âI think the #NoEstimates response to that is, estimation doesn't work,
so even if estimates would be nice, estimation doesn't actually provide
them.
McConnell's response is basically, estimation does work if you know
what you're doing and do it right.
*1. Estimation is often done badly and ineffectively and in an overly

time-consuming way.*
*2. The root cause of poor estimation is usually lack of estimation
skills.*)

And also that Scrum is actually very compatible with estimation, and
*14. Scrum provides better support for estimation than waterfall ever

did, and there does not have to be a trade off between agility and
predictability. *
*16. This is not religion. We need to get more technical and more
economic about software discussions. *

â
What did he call his burnup charts (charts that, by the way, support
estimation at a glance)?
*-- Joel Aufrecht*
Team Practices Group
Wikimedia Foundation

I attended a Meetup last night, via Bay Area Agile Leadership Network.
http://holub.com/
TL;DR: His presentation was about how estimation is bad (among other
things, he argues that estimating is unethical). I felt it was a fairly
aggro presentation (full disclosure: I'm pro-estimation), but under the
veil of what I observed as an extremist view of Agile was a message
promoting Agile as a state of mind, rather than a
panacea-by-rigid-structure, all too often deployed by "Agile" companies.
He also showed burnup charts (he didn't call them that) very similar
to those on phlogiston.wmflabs.org.
_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices

_______________________________________________
teampractices mailing list
https://lists.wikimedia.org/mailman/listinfo/teampractices