XP at Project Startup
Mark Small
I hsve to write a paper on how XP fits with Project Management
techniques. Having little knowledge of XP I am looking for more
experienced views on XP in areas such as:
1. Controlled & organised start to the Project
2. Involved customers with improved customer communication
3. Effective reviews of progress against a plan
4. Effective communication channels with all stakeholders i.e.
customer, development team, management team etc.
5. Effective & appropriate decision & control points
6. Managing Complexity
If you have any views, experience etc I would be grateful if you would
let me know.
MARK
CIAO
J. David Boyd
Arjan Schokking
Hmm, better look at scrum, or general agile keypoints,
XP is a set of best programming practices, focusing on the
implementation side of an agile process. Scrum and a couple of other
agile methods focus on the organizational aspect. Which is one of the
reasons they are used together so often. XP@Scrum, lol.
If you wanna write something about management and Xp, just state it has
the plannig game and that's about it, and the planning game originally
came from scrum anywayz.
On the upside this could make for a very short paper unless you
highlight the fact that Xp needs something added in to make it a true
project management method.
Where you get the add ins from is another interesting area, some people
will do them because they just make sense, others will get them from
other agile methods, but in the end you come back to the basic agile
rule, do what works for you :).
greetz Arjan
TheDotNetArchitect
be writing the same document soon
Robert C. Martin
wrote:
>Hi there,
>
>I hsve to write a paper on how XP fits with Project Management
>techniques. Having little knowledge of XP I am looking for more
>experienced views on XP in areas such as:
>
>1. Controlled & organised start to the Project
>2. Involved customers with improved customer communication
>3. Effective reviews of progress against a plan
>4. Effective communication channels with all stakeholders i.e.
>customer, development team, management team etc.
>5. Effective & appropriate decision & control points
>6. Managing Complexity
XP starts at the point that a project is authorized. At that point
stakeholders, developers, business analysts, and QA folks meet for a
few days to a week to discuss business needs and requirements. This
is called "exploration". Not much is written down during this period,
even though detailed requirements are discussed. It's not written
down because at this point details are likely to change. What *is*
written down are the names of features. They are written on cards,
and called "stories". They are not actually narratives stories as
some of the literature would have you believe. They are just the
names of features like "Login", "Logout", "Deposit", "Withdraw", etc.
Having assembled a partial deck of stories, they are estimated by the
developers. These estimates use arbitrary points that are relative to
each other, but have no absolute meaning. A complex card might be
given an estimate of 10. A simple card might be given an estimate of
2. The only rule is that a card with a 4 should be half as hard as a
card with an 8. Cards larger than 10 are usually broken down into
smaller stories.
This process of identifying features and estimating them never ends,
It continues throughout the life of the project. The deck is
continually getting new cards added, and old cards deleted or changed.
Finally, the developers make an educated guess at the number of points
they can do in a week. This guess is crude and there is no need for
accuracy. The stakeholders pick cards from the deck that add up to
this number. So if the developers think they can get 80 points done
in a week, the stakeholders pick cards that add up to 80.
The picking of cards is interesting. Stakeholders pick the cards with
the best ROI. They look at each card and compare it's business value
to its cost in points. The 80 points they pick are the 80 points that
carry the largest ROI possible from the deck.
The developers then implement the deck of 80 during the week. On
wednesday at noon those cards that total up to 80 (known as the
iteration plan) should be split into two decks: those that are done,
and those that aren't. The sum of points in the done deck should be
40. (To do this process you must be able to divide by two). Let's
say that there are only 22 points in the "done" deck. Then it's
likely that by Friday the team will get no more than 44 points done.
SO the stakeholders pull out 36 points from the "undone" deck.
Let's say, by some miracle, the team finishes all 44 points on Friday.
Now we know the team can do about 44 points per week. So on Monday
the stakeholders pick another 44 points (which may, or may not include
some of the 36 that were removed from the previous iteration). Now
let's say that by Wednesday the team has 31 points in the "Done" pile.
They might get 62 points done this week. So the stakeholders pull out
another 17 points and put them in the "undone" pile. By friday the
team has 58 points done. The remaining 3 points go back in the pile,
and now we know that the team can get 58 points done in a week. On
monday the stakeholders pull out another 58 points. And so it goes.
What does "Done" mean? A card is not done until it passes its
acceptance tests. These acceptance tests are written by the
stakeholders at the beginning of each iteration. On monday, the
stakeholders (business analysts and QA) select the cards for the
iteration, and then they write the acceptance tests for those cards.
These acceptance tests should be done by Wednesday. If they aren't
then some programmers hop the line and help finish writing them.
The acceptance tests must pass before a story can be said to be done.
Indeed, the acceptance tests are the only criteria for "done-ness".
Thus, the acceptance tests become the detailed requirements document.
The acceptance tests are also automated. They are written in a high
level requirements language (see www.fitnesse.org) so that the
developers or stakeholders can push a button and see the tests pass or
fail. A story is not "done" until it passes it's automated acceptance
tests.
Developers write code by writing tests first: See
http://www.butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd.
All of these practices, and many more, need to be managed. Data must
be collected, collated onto charts and reports, and presented to
management. That is the role of the project manager.
Project managers are just as necessary in XP as they are in any other
discipline. Their role is roughly the same. However, the data that
they collect and the schedule they collect it on, is very different.
-----
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716
"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
Ron Jeffries
wrote:
>If you wanna write something about management and Xp, just state it has
>the plannig game and that's about it, and the planning game originally
>came from scrum anywayz.
>
>On the upside this could make for a very short paper unless you
>highlight the fact that Xp needs something added in to make it a true
>project management method.
Can you think of two or three Scrum things that aren't in XP?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
Phlip
>>On the upside this could make for a very short paper unless you
>>highlight the fact that Xp needs something added in to make it a true
>>project management method.
>
> Can you think of two or three Scrum things that aren't in XP?
Stand-up meetings, the ScrumMaster title/role, and the concept that some
people are involved and others are committed.
--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Ron Jeffries
>Ron Jeffries wrote:
>
>>>On the upside this could make for a very short paper unless you
>>>highlight the fact that Xp needs something added in to make it a true
>>>project management method.
>>
>> Can you think of two or three Scrum things that aren't in XP?
>
>Stand-up meetings, the ScrumMaster title/role, and the concept that some
>people are involved and others are committed.
Standup meetings were in XP in 1996. When did they get removed?
As for the other two ... maybe.
Phlip
>>Stand-up meetings, the ScrumMaster title/role, and the concept that some
>>people are involved and others are committed.
>
> Standup meetings were in XP in 1996. When did they get removed?
KB never wrote them up, and has pointed out that needing to standup is a
sign of poor communication. A team should just get to work in the morning,
and should have a planning game of a few minutes.
From this perspective, Scrum prepares for defeat, just like BDUF or a
bugbase.
Ron Ruble
<snip>
> KB never wrote them up, and has pointed out that needing to standup is a
> sign of poor communication. A team should just get to work in the morning,
> and should have a planning game of a few minutes.
Would it be accurate to say that a need for -daily- standup
meetings (a la Scrum) are a sign of poor communication, but
standup meetings are fine occasionally when driven by an actual
purpose that's better filled by a quick team get-together
than a formal meeting or informal on-on-one communications?
I'm thinking of many cases where new or clarified user
requests prompted us to have a quick meeting to hash
out some quick ideas on what technical changes to make,
what impact they may have on existing code/design.
Usually quick, but it seems these kinds of things are
easier to deal with when the whole staff meets in a
conference room where we can sketch out a few things
on a white board.
I kind of get the impression that a 'daily meeting' is
a security blanket that hide underlying problems.
But a quick 'go over some new things' meeting is a good
tool.
Laurent Bossavit
> Would it be accurate to say that a need for -daily- standup
> meetings (a la Scrum) are a sign of poor communication,
Perhaps in the same way it would be accurate to say that a need for a
daily shower is a sign of poor hygiene ?
Just a thought. Not that I have an opinion. YMMV.
Laurent
Phlip
> Ron,
>
>> Would it be accurate to say that a need for -daily- standup
>> meetings (a la Scrum) are a sign of poor communication,
>
> Perhaps in the same way it would be accurate to say that a need for a
> daily shower is a sign of poor hygiene ?
Uh, the metaphor here is the team can determine for itself if and when it
needs a shower.
Some metaphors shouldn't be persued too far...
Ron Ruble
> Ron,
>
>
>>Would it be accurate to say that a need for -daily- standup
>>meetings (a la Scrum) are a sign of poor communication,
>
> Perhaps in the same way it would be accurate to say that a need for a
> daily shower is a sign of poor hygiene ?
I think Philip's point earlier was that a daily stand-up
meeting is perceived as not being hygienic but rather
prophylactic.
A need for a daily shower is normal.
A need for a daily round of antibiotics indicates a
problem.
Not saying that's the way it is; just trying to clarify
the thinking behind it.
Robert C. Martin
>Ron Jeffries wrote:
>
>>>Stand-up meetings, the ScrumMaster title/role, and the concept that some
>>>people are involved and others are committed.
>>
>> Standup meetings were in XP in 1996. When did they get removed?
>
>KB never wrote them up, and has pointed out that needing to standup is a
>sign of poor communication. A team should just get to work in the morning,
>and should have a planning game of a few minutes.
>
>From this perspective, Scrum prepares for defeat, just like BDUF or a
>bugbase.
The reality of XP and Scrum is that nobody does them exactly by the
book; and that those people who are succeeding best, don't care that
much about the book.
Robert C. Martin
>Laurent Bossavit wrote:
>
>> Ron,
>>
>>> Would it be accurate to say that a need for -daily- standup
>>> meetings (a la Scrum) are a sign of poor communication,
>>
>> Perhaps in the same way it would be accurate to say that a need for a
>> daily shower is a sign of poor hygiene ?
>
>Uh, the metaphor here is the team can determine for itself if and when it
>needs a shower.
Correct. A team that has decided that a daily standup is worthwhile
is not thereby admitting that it has a communication problem. When
standups help, then stand up. When they stop helping, then sit down.