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 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 <ksm...@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
> 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
> 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 <jaufre...@wikimedia.org>
>> 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
>> On Wed, Sep 21, 2016 at 2:38 PM, Joel Aufrecht <jaufre...@wikimedia.org>
>>> Interesting. I just finished Steve McConnell's response to
>>> #NoEstimates, 17_Theses_on_Software_Estimation_(Expanded)
>>> 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
>>> 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
>>> 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 <mbin...@wikimedia.org>
>>>> 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:
>>>> 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 mailing list
> teampractices mailing list
teampractices mailing list