RE: [scrumdevelopment] Scrum vs Ad Hoc methods
- I'll back Bryan on this one. When we implement Scrum without the proper
engineering practices being started up, we risk having iterative hacking.
It's true that we get to inspect every thirty days, but the people
inspecting have to know what to inspect. I think we should emphasize the
engineering evaluation as part of being a ScrumMaster. The output of every
Sprint is an increment of potentially shippable product functionality. We
should take on ensuring that it is truly shippable. Whenever it isn't, the
corrective work gets rolled over to the next Sprint, along with some new
product backlog to investigate and implement corrective engineering
A tip off is the Sprint Backlog. The two administrative responsibilities for
a Scrum team are the Daily Scrum and the Sprint Backlog. The Sprint Backlog
is their planning mechanism where the team lays out the Sprint tasks. If the
team never lays out the tasks, then it doesn't need the Sprint Backlog. If
the team never thinks through what it is going to do and just starts
hacking, it certainly doesn't need it. So, to me, the presence of the Sprint
Backlog comforts me that the team has at least put thought into their work.
From: Bryan Zarnett [mailto:bzarnett@...]
Sent: Friday, July 11, 2003 8:42 AM
Subject: Re: [scrumdevelopment] Scrum vs Ad Hoc methods
On Friday, July 11, 2003, at 07:59AM, Robert Henley <rhenley@...>
>It seems to me that our biggest foes (and thus greatest potential market)are not the users of >heavyweight methodologies, but the users of ad hoc
methods. The heavyweight method users at least >appreciate that you need a
I think our biggest foe is not "ad hoc" methodologies but individuals who
believe that their approach is not "ad hoc" (even though it is), and believe
that is the only way for development to proceed.
In a company where I brought in XP (a long time ago in the DOT-COM era), we
had sme nice success coming in under time and budget while keeping a 1 hour
Quake game time, and leading by 5, and not starting till 9 or 9:30. It was
a nice group of people, of various levels of experience -- everyone had good
ethics though and where fun to be with. After our success another
individual commented that it was a fluke and cited his years of experience
where "bugs, delays, etc." where "just how it was"
In many circumstances, the process is not the issue but the foundation of
the developers -- often there is none. There basics and attitude are so poor
that they can not, and do not understand how to do there work properly. If
we say you need to do test-first development; how do we expect them to do
this when they can't write basic code or understand the fundamentals of good
design in a project.
Given the current percentage of good programmers to poor programmers, our
biggest issue is lack of skill which leads to poor practices being
implemented. One Sr. Technical Guru I know on a project does not believe in
documentation or coding conventions, so the projects have none. That is the
practice - he also has never written any code other than some Cobol (not
dishing the Cobol people).
I think lack of proper education is our biggest foe.
Sorry for the rant. I still need my morning coffee.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/