Planning with >1 projects

I'm consulting at a company at which my opinion carries some weight.  At the
same time, I'm learning XP, and trying to gradually nudge them in that
direction.  Looking at their current situation, though, I see that they
generally have several projects in progress at once for multiple work
originators.

How does the planning process usually work when one team may work on multipl
e
projects simultaneously?  ... or is that something that should be changed?

Thanks,

- Steve Jorgensen

P.S.

Please check out my side project's web log at
http://timestream.net/learningxp/

> How does the planning process usually work when one team may work on multiple
> projects simultaneously?  ... or is that something that should be changed?

The customer role, (which can be fulfilled by a single person or multiple
people) has a very important rule: "The customer speaks with one voice".

Working on multiple projects simultaneously tends to be the same challenge
everywhere I go. Each project wants 60-75% of the programmers time and that'
s
just not possible. It results in death marches and when one project gets in
trouble there's always resource conflicts.

XP does the decent thing and admits, up front, that this is a problem. It
clearly states that the people on the business side of the house have to lea
rn
to work together and decide what they think the requirements and the priorit
ies
are. That's why the customer has to "speak with one voice". If they can, the
re's
no issue. If they can't, well, the team tends to be screwed, regardless of t
he
methodologies of philosophies chosen.

Since the customer (the role) knows the state of all the projects, what card
s
will be worked on next by the team, what cards will be added, what cards wil
l be
removed, what resources will be available, and what the current velocity is,
 the
customer is capable of making the correct decisions with the help of the tea
m.
That tends to makes planning the next iteration relatively straightforward.

http://c2.com/cgi/wiki?TheCustomerSpeaksWithOneVoice
http://c2.com/cgi/wiki?OnsiteCustomer

Note: Certain teams may find it useful to become multiple teams with each te
am
working on their own projects and meeting separately daily and together w
ly.
They may share customers. They may share members. They may move members betw
een
teams as needed. Teams that can reorganize on the fly have a great advantage
over teams that can't. I think of it as one of those practices XP doesn't ta
lk
about, but definitely benefits from.

On Sun, 01 Aug 2004 08:37:31 -0500, Ken Boucher <bons@cox.net> wrote:

>Note: Certain teams may find it useful to become multiple teams with each t
eam
>working on their own projects and meeting separately daily and together wee
kly.
>They may share customers. They may share members. They may move members bet
ween
>teams as needed. Teams that can reorganize on the fly have a great advantag
e
>over teams that can't. I think of it as one of those practices XP doesn't t
alk
>about, but definitely benefits from.

Very nice report, Ken. It leaves little to add. I would like to make
one comment on the part quoted above.

I feel that splitting the teams is a bit like dividing up the toys
between the kids: it might stop the fighting, but it's not as
effective as learning to get along.

When resources are split, it's inevitable that one team will be
starving for something while the other has too much. Since skills are
so variable among people, we can easily create two teams, each of
which is starving for one resource and has too much of another.
Imagine accidentally gettng all the GUI  people on one team and all
the database people in the other. Naturally we wouldn't do anything
quite that dumb -- would we? -- but it will probably be happening at a
less obvious level.

As you point out, reorganizing on the fly can help, especially if you
can reorganize right in the middle of the day.

Even then, though, a serious divantage of dividing the resources is
that it deprives the Customer people of the opportunity to learn to
optimize the whole company's resources, and to find synergies in their
needs.

Again, thanks for the report,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Steve,

> Looking at their current situation, though, I see that they
> generally have several projects in progress at once for multiple work
> originators.

By "work originator", do you mean something like (internal) customer ?
The phrase is unfamiliar to me.

Who is "they" ? A single group of people ? Are they identified as a
"team", i.e. a group with a somewhat stable collective identity ?

In practice, how is work allocated to individuals ? How many individuals
does a typical "project" have working on it ?

> How does the planning process usually work when one team may work on multi
ple
> projects simultaneously?  ... or is that something that should be changed?

There are two opposing forces at work in such situations, I've found -
multitasking (one person sharing her time among several categories of
work) tends to reduce performance; individual work (as opposed to
collective) tends to reduce knowledge sharing, code reuse, adherence to
coding standards, etc.

What are the concerns to be addressed by the planning process ?
(See http://bossavit.com/thoughts/archives/000670.html )

Laurent
http://bossavit.com/thoughts/

I'd like to comment on the comment. For clarity I've left the whole original
message below, something I don't often do.

When we've split teams we didn't move them into separate rooms, stop them fr
om
pairing with each other, or otherwise actually divide them except in two way
s:

1) The people on one team don't have to attend the stand-up, iteration meeti
ngs,
etc. for the other team. They can, but usually they would rather write code 
for
the cards they're working on instead of seeing the stack for the project the
y're
not working on.

2) The people on one team are going to work on related cards. Since they're 
on
one project, all of their stories touch each other. It's my experience that 
we
get a better velocity by having people who understand all the related storie
s.
We've got to balance that with sharing the knowledge, but it's really rough
working on two unrelated groups of stories at the same time. I find someone 
is
more likely to end up with less knowledge when they're split between project
s
because they're never focused enough to really learn either of them.

It's fully possible that both teams actually have the same person in the
customer role. When they have two people (or groups of people) in the the
customer roll, these people still all belong to the same (for lack of a bett
er
term) over-team and they're more than capable of speaking with one voice.

At my organization, people on all the teams have a wly get together as on
e
big team. Also the developers and the business owners have their own "big te
am
get together". There's no deliberate isolation going on here. (I sometimes t
hink
that despite anyone's best attempts, accidental isolation happens. Some thin
gs
forget to be communicated.)

So, in the course of a day, I'm probably going to just work on the project I
'm
on. However at any time of the day, I'm available to any of the other projec
ts
as they need me. This has resulted in some of the following positive things:

1) Team X has a w with no cards due to some strange things that I don't f
ully
understand. So they pick up a ws work of cards from another team. They're
productive and happy and that other project gets a nice boost.
2) Team Y needs someone to decipher a pile of old world BDUF created by the
people in the organization that sends them files. Since I have a heavy
background in the department that created that pile of paperwork, I take the
task. Two hours later, team Y is in complete control of the situation.
3) My workspace code for dealing with the client database is behaving very
strangely. 15 Minutes with a person from Team Z and my code is working fine 
and
we've found a great opportunity to remove some code that should probably be
depreciated.
4) Need someone with Envy knowledge? A SOAP expert? A DB2 guru? Someone who
understands Assembler, Cobol, Java, and Smalltalk?, someone good with a
soldering iron? There's one in the room and they're available to anyone. Ins
tead
of having a shortage of resources, a team like this has a surplus of them,
because what they need is always available.

These are normal ways of working together at my location. However we have a
number of unusual advantages.
1) We have a big room, conductive towards such behavior.
http://www.fairlygoodpractices.com/open.htm
2) We have a very supportive organization that lets us get away with such
behavior.
3) We've grown into this size. It would have been much harder to start out t
his
big.
4) We have the right people. We have people who very rarely work together wh
o
share cases of diet mountain dew. We have people who buy new toys and leave 
them
in the meeting rooms for others to play with. We have people who will go to
lunch with each other, go drinking with each other, party at each others hou
ses,
and show up with trucks to move each other to their new homes. In short, we 
have
some really good people.

-----------------------
Ronald E Jeffries wrote:
>
> On Sun, 01 Aug 2004 08:37:31 -0500, Ken Boucher <bons@cox.net> wrote:
> 
>
> Very nice report, Ken. It leaves little to add. I would like to make
> one comment on the part quoted above.
>
> I feel that splitting the teams is a bit like dividing up the toys
> between the kids: it might stop the fighting, but it's not as
> effective as learning to get along.
>
> When resources are split, it's inevitable that one team will be
> starving for something while the other has too much. Since skills are
> so variable among people, we can easily create two teams, each of
> which is starving for one resource and has too much of another.
> Imagine accidentally gettng all the GUI  people on one team and all
> the database people in the other. Naturally we wouldn't do anything
> quite that dumb -- would we? -- but it will probably be happening at a
> less obvious level.
>
> As you point out, reorganizing on the fly can help, especially if you
> can reorganize right in the middle of the day.
>
> Even then, though, a serious divantage of dividing the resources is
> that it deprives the Customer people of the opportunity to learn to
> optimize the whole company's resources, and to find synergies in their
> needs.
>
> Again, thanks for the report,
>
> --
> Ron Jeffries
> www.XProgramming.com
> I'm giving the best advice I have. You get to decide if it's true for you.

On Sun, 01 Aug 2004 04:28:55 GMT, Steve Jorgensen
<nospam@nospam.nospam> wrote:

>I'm consulting at a company at which my opinion carries some weight.  At th
e
>same time, I'm learning XP, and trying to gradually nudge them in that
>direction.  Looking at their current situation, though, I see that they
>generally have several projects in progress at once for multiple work
>originators.
>
>How does the planning process usually work when one team may work on multip
le
>projects simultaneously?  ... or is that something that should be changed?


You have an XP team that can convert V story points per iteration into
working code.  You have N projects each spinning off stories.  The
project managers get together at the beginning of each iteration and
decide how to allocate their stories to the iteration.

If Project1 is very important it may get 50% of the story points in
that iteration (V/2).  Project2 and Project3 might get 25% (V/4) each.
The developers don't care which project they are working on, they are
just implementing stories.  To them, it's all just one big project
with many different facets.

This strategy has been successfully applied at many companies.  The
developers are just a big story engine, and the managers feed the
highest priority stories into that engine.  This allows the business
to rapidly shift project priorities without worrying about
disenfranchising a team.


-----
Robert C. Martin (Uncle Bob)
Object Mentor Inc.
unclebob @ 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