RE: Engineering Practices in Scrum - from RE: Type N Scrum
I think you have hit on a key point, and one to it will be interesting to see the responses.
I would concur that any practice needs form underneath, whether it be engineering or otherwise. At the heart of it, without form there is no function. There is no repeatability. Repeatability for example becomes not a certainty but as Doug Henning said so many years ago... "..an ILLUSION...."
This is a dynamic that has been bothering for some time about agile methods.
I do believe they work - in fact, I sold technology 20 years ago that promoted concepts remarkably familiar to what I now see in the agile stuff today, including Scrum. But I wonder why they work as they do.
I revel in the notion that others, here, are potentially equally interested in the same problem. Why does this stuff work at all? There is certainly the human factor to consider - and that is, to me, what is most intriguing about agile methods, whether Scrum, XP or call it what it you will. The agile methodology is really about celebrating what a team can accomplish and empowering them to do so.
But a team without direction is a team in chaos. Likewise, a methodology without form is a series of loosely-related concepts as opposed to a methodology. There are reasons that the structured stuff worked for so long, although most folks doing structured design (and you know who you are) were in many cases not able to describe why the methodologies actually worked as they did, and that was okay. What they _knew_, and knew very well thank you very much, was the practical application of the methodology of the time.
The practitioners did not fail, the limits of the methodology did. The only issue was that many did not realize when to jump off the bandwagon since they had no critical metrics by which to measure success. What they did have (and I include myself here, dating myself as well) was artifact indicators: projects running over-budget, unsatisfied customers, products coming out square when they were designed to be round, and the like. Change was needed.
As should by now be apparent, I am a fan of practices and process. I'm also a fan of reductionism. Ergo, I'm a fan of the agile approach; a marriage of the two, done well. My only concern for practitioners is that Scrum, XP and other agile methods are no safer from running off the methodological rails than earlier methodologies. What these current methodologies do offer however, is the remarkable opportunity to get it wrong, and even do so again and it's still okay. That's revolutionary, worth preserving and worth understanding!
But in all of that, there needs to be a serious study of _why_ these practices work and _why_ they don't work on occasion. This group is making a great effort at doing precisely that. I believe structured thinking would be in order. I suggest that we bring even more of that type of expertise and discipline to this forum as we all attempt to understand agile methods.
John Streiff, Technical Product Manager
Secure Software, Inc
Date: Tue, 28 Mar 2006 09:20:28 -0500
From: "Pascal Roy" <pascal_roy_1967@...>
Subject: Engineering Practices in Scrum - from RE: Type N Scrum
Question to the community: Do you feel that using Scrum without any of the
agile engineering practices can yield good results?
I think the reason Scrum is more popular than XP (I have no knowledge that
this is actually true, but it does feel like it) is that it involves much
less changes for the entire development organization. This is thus probably
much easier to implement Scrum than say, XP. In fact, because the core of
Scrum is mostly about agile management as I understand it, it can be put in
place from the top down (which typically doesn't work really well in XP).
After all, as long as the developers aren't impacted too much in their
technical practices, they should not care that much. Planning in most
companies is not their responsibility anyway (they often don't even do their
own estimates). In my personal experience (YMMV), resistance in XP is
typically not related to the planning practices which developers seem to
like, it's when we touch their day to day engineering activities (TDD,
refactoring, simple design, pair programming...). That's where the proverbial
shit hits the fence if you permit the language...
The question I raise (and I shamelessly timed this message with one of
Ron's that more or less discusses this issue) is whether or not you can do
iterative development effectively without some of the technical engineering
practices. For exemple, at the end of the sprint, you might be able to say
the tasks of the sprint are done by having the customer run the acceptance
tests manually. But how, would you know you hadn't broken the rest of the
software which would render your burn down chart completely useless. If 20
new features work, but 20 others now fail, you're not really going forward.
Maybe it's a just a little thing, but it could be a costly design error
requiring lots of time to fix. How would you know where you are at that
moment?. I would also bet velocity would become completely useless in an
environment without unit tests that would act as a solid base on which
developers could count when they invariably need to refactor the design
(iterative development remember). From experience, without those tests, the
farther we are down the line, the more complex the software, the more
chances we screw something without knowing, the longer it takes to add any
new functionality, the lower the velocity. Planning with declining velocity
isn't too interesting to most people. Well, technically you could calculate
the rate of decline and plan with that. Depressing isn't? I'm not saying you
can't absolutely do Scrum without the engineering practices, but I just
don't see that the iterative planning nature of Scrum can actually work
efficiently without having the right data from the team. That meaningful
data comes from the engineering practices.
I'm not here to advocate XP over Scrum. In fact, I don't care that much
(anymore) how to call whatever we do as long as it works. Frankly, I just
don't think you can do iterative effectively without a minimum of
engineering practices... If this is true, than teaching Scrum without the
backing of the engineering practices it needs to get meaningful feedback is
doing a disservice to the community.
I don't pretend I have the answer here. I'm just really curious what the
community thinks of this.
Pascal Roy, ing./P.Eng., PMP
Elapse Technologies Inc.