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 <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 > 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 <jaufre...@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 <jaufre...@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 <mbin...@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@lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/teampractices >>>> >>>> >>> >> >> _______________________________________________ >> teampractices mailing list >> teampractices@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > > _______________________________________________ > teampractices mailing list > teampractices@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/teampractices > >
_______________________________________________ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices