[teampractices] Saw a presentation by Allen Holub

Thu Sep 22 16:07:34 UTC 2016

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

On Wed, Sep 21, 2016 at 4:30 PM Max Binder <mbinder at wikimedia.org> wrote:

> 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
>>
>>
> _______________________________________________
> 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/20160922/decc815e/attachment.html>