[teampractices] Saw a presentation by Allen Holub

Wed Sep 21 23:29:09 UTC 2016

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
> 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. :-/

On Wed, Sep 21, 2016 at 4:18 PM, Kevin Smith <ksmith at wikimedia.org> wrote:

> 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
>
>
> On Wed, Sep 21, 2016 at 2:49 PM, Joel Aufrecht <jaufrecht at wikimedia.org>
> wrote:
>
>> I skimmed through his #NoEstimates video until I saw burnup charts:
>>
>> https://youtu.be/QVBlnCTu9Ms?t=1616
>>
>> 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
>>
>> On Wed, Sep 21, 2016 at 2:38 PM, Joel Aufrecht <jaufrecht at wikimedia.org>
>> wrote:
>>
>>> 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
>>>
>>> On Wed, Sep 21, 2016 at 1:29 PM, Max Binder <mbinder at wikimedia.org>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> teampractices mailing list
>>>> teampractices at lists.wikimedia.org
>>>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160921/dde45819/attachment.html>