Re: [scrumdevelopment] Dependencies
- I agree with Ron Jeffries Rule 1 and always use it in Scrums.
The main reason is that dependencies and their consequences change
depending on task sequencing which is affected by random factors like
technology, system, or resource availability and/or unexpected events. This
makes Gantt charts useless for running projects unless you want to dedicate
a full time person to update the Gantt chart every day.
One of the most important affects of a well running Scrum is that
dependencies are updated daily in the meetings using the combined neural
networks of the brains of all team members. This optimizes the path to the
end of the project and is one of the main reasons for Scrum repeatedly
delivering more and better functionality faster.
A project leader looking at a dependency chart that is more than one hour
old is almost always looking at something that is inaccurate, if not
completely wrong, and will consistently make suboptimal decisions as a result.
There is some room for project management in a Scrum and I do it regularly
to help out the ScrumMaster. As a release gets close to ship date, I print
out our automated backlog which lists each item and the person responsible
for the release in question and talk to each individual about where they
are on delivery. The major impact of this is to (1) assure that other
priorities are not taking peoples attention off the delivery, (2) that no
one person is overloaded and that the project does not require rebalancing,
and (3) determine whether the developers actually delivering the code have
confidence in the delivery date.
At 03:24 AM 9/16/2003, you wrote:
>On Monday, September 15, 2003, at 7:41:55 PM, Mike wrote:
> > I am curious how people reflect dependencies between tasks on SCRUM backlog
> > list. It doesn't seem like the backlog spreadsheets that I've seen in the
> > past had that information.
>If I did Scrum instead of XP I would do just what I do in XP.
>1. I ignore dependencies.
>2. I observe that customers usually ask for the right dependent item first.
>3. I observe that they can usually be influenced to ask for the right one
> if need be.
>4. I observe that dependencies are usually reversible, i.e. if A and B are
> dependent such that A will take 5 days and then B will only take 1, it's
> usually true that if B is done first, it will take 5 days and then A
> only 1.
>5. I build the parts that dependent projects depend on incrementally.
>Because there are all these options, I find that for planning purposes,
>rule 1 works quite well.