Discussion:
Practice: Shrinking Teams
Kent Beck
2005-03-23 07:05:14 UTC
Permalink
As a team grows in capability, keep its workload constant but gradually
reduce its size. This frees people to form more teams. When the team has too
few members, merge it with another too-small team. This is a practice from
the Toyota Production System. I haven't actually used it, but it makes so
much sense to me that I include it here. The other strategies I've seen for
scaling up to larger workloads, like creating bigger and bigger teams, work
so poorly that alternatives are worth considering.
Since I don't have experience with this practice, I'll explain by analogy.
Say five people work together in a manufacturing cell. Rather than load them
all equally, make sure that as many people as possible are fully engaged.
The fifth person, then, might be working only 30% of the time. This is good.
The team members, as they do their work, also think about how to improve
their work process. They try ideas until they eliminate enough wasted effort
that the fifth person is no longer needed. Trying to keep everyone looking
busy obscures the fact that the team has extra resources available.
Try the same in software development. Figure out how many stories the
customer needs. Strive to improve development until some of the team members
are idle; then you're ready to shrink the team and continue.
Erik Meade
2005-03-23 07:58:07 UTC
Permalink
Post by Kent Beck
As a team grows in capability, keep its workload constant but gradually
reduce its size. This frees people to form more teams. When the team has too
few members, merge it with another too-small team. This is a practice from
the Toyota Production System. I haven't actually used it, but it makes so
much sense to me that I include it here. The other strategies I've seen for
scaling up to larger workloads, like creating bigger and bigger teams, work
so poorly that alternatives are worth considering.
Since I don't have experience with this practice, I'll explain by analogy.
Say five people work together in a manufacturing cell. Rather than load them
all equally, make sure that as many people as possible are fully engaged.
The fifth person, then, might be working only 30% of the time. This is good.
The team members, as they do their work, also think about how to improve
their work process. They try ideas until they eliminate enough wasted effort
that the fifth person is no longer needed. Trying to keep everyone looking
busy obscures the fact that the team has extra resources available.
Try the same in software development. Figure out how many stories the
customer needs. Strive to improve development until some of the team members
are idle; then you're ready to shrink the team and continue.
I haven't seen this explicitly done with software development, but have seen
a few teams that managed to automate away enough work to free up time to do
other things within the team or increase velocity.

It also seems a handy way to not increase teams size, especially if you are
approaching one of the big communication requirement increase sizes. (12 and
150 if I recall correctly).

In other cases I wonder if social loafing, fear of being replaceable, threats,
etc. prevent teams from embracing this practice.

The first time I read this practice I thought of the project management
proverb: "At the heart of every large project is a small project trying to
get out."

This is also a point I try to drive out in my "Extreme Teams" game.

Erik Meade
Doug Swartz
2005-03-23 12:15:49 UTC
Permalink
Post by Kent Beck
As a team grows in capability, keep its workload constant but gradually
reduce its size. This frees people to form more teams. When the team has too
few members, merge it with another too-small team. This is a practice from
the Toyota Production System. I haven't actually used it, but it makes so
much sense to me that I include it here. The other strategies I've seen for
scaling up to larger workloads, like creating bigger and bigger teams, work
so poorly that alternatives are worth considering.
I didn't know it was a pattern, but we stumbled into this
practice.

We generally have a team per product. The team supports
production, and implements enhancements for its customers.
After a couple of years, we had two or three products which
had stabilized to the point that the number of enhancements
didn't require more than two or three people on the team.
Unfortunately, with a primary and back-up on-call person, a
team with only two members would be on-call 24 hours a day
forever. Even with very few problems, it is annoying to be
on-call all the time.

In 2003, we created a team by merging two very small teams.
This team is now one of our largest (8 people), and supports 6
different products plus some infrastructure components
(security, file transfer management, etc.) used by all the
teams/products. The two rotating on-call people support all
the team's products. It's been very good for reducing our
truck number and allows for short term fluctuations where one
of the products supported by the team needs development.
--
Doug Swartz
daswartz-***@public.gmane.org
noetic8
2005-03-25 01:01:39 UTC
Permalink
To all,

There's a presentation from SxSW 2005 called "How to make big things happen with small teams" at http://tinyurl.com/5sbtz . I thought it was interesting and matched my own experiences well.

Regards,

Steve
Carlos
2005-03-25 12:38:34 UTC
Permalink
Post by Kent Beck
As a team grows in capability, keep its workload constant but
gradually
Post by Kent Beck
reduce its size. This frees people to form more teams. When the
team has too
Post by Kent Beck
few members, merge it with another too-small team. This is a
practice from
Post by Kent Beck
the Toyota Production System. I haven't actually used it, but it
makes so
Post by Kent Beck
much sense to me that I include it here. The other strategies I've
seen for
Post by Kent Beck
scaling up to larger workloads, like creating bigger and bigger
teams, work
Post by Kent Beck
so poorly that alternatives are worth considering.
Since I don't have experience with this practice, I'll explain by
analogy.
Post by Kent Beck
Say five people work together in a manufacturing cell. Rather than
load them
Post by Kent Beck
all equally, make sure that as many people as possible are fully
engaged.
Post by Kent Beck
The fifth person, then, might be working only 30% of the time. This
is good.
Post by Kent Beck
The team members, as they do their work, also think about how to
improve
Post by Kent Beck
their work process. They try ideas until they eliminate enough
wasted effort
Post by Kent Beck
that the fifth person is no longer needed. Trying to keep everyone
looking
Post by Kent Beck
busy obscures the fact that the team has extra resources available.
Try the same in software development. Figure out how many stories
the
Post by Kent Beck
customer needs. Strive to improve development until some of the
team members
Post by Kent Beck
are idle; then you're ready to shrink the team and continue.
Kent,

I've been thinking about the unemployment issue...
We know that XP minds the human/social aspect of software development.

I sincerally understand the goal of eliminating waste and even think
that an idle team merber can add waste.

But if we don't need forming more teams what would we do with the
idle team member? Fire him?

Regards,
Carlos.
Adrian Howard
2005-03-26 11:05:19 UTC
Permalink
On 25 Mar 2005, at 12:38, Carlos wrote:
[snip]
Post by Carlos
Kent,
I've been thinking about the unemployment issue...
We know that XP minds the human/social aspect of software development.
I sincerally understand the goal of eliminating waste and even think
that an idle team merber can add waste.
But if we don't need forming more teams what would we do with the
idle team member? Fire him?
<advocate class="devil's">
If you're really 100% certain that you're never going to have a larger
project, or need more work later project why wouldn't you fire them?
Does any company aim to keep people around who don't do any work?
</advocate>

And if you do work for a company who doesn't plan to get more work in
and grow then it's probably time to ChangeYourOrganization :-)

Training would seem the obvious answer to me. Get them to go learn
something new.

I find it hard to imagine a situation where spare people couldn't be
used productively unless the situation is totally borked. They're not
spare because they're bad. They're spare because /everybody/ has
learned to be better. Firing your most productive employees seems
counterproductive to me.

Cheers,

Adrian
Colin Putney
2005-03-26 15:57:06 UTC
Permalink
Post by Adrian Howard
<advocate class="devil's">
If you're really 100% certain that you're never going to have a larger
project, or need more work later project why wouldn't you fire them?
Does any company aim to keep people around who don't do any work?
</advocate>
Well, let's consider the context. The company is dedicated to finding
and eliminating waste. The workers actually have enough slack to think
about process improvement; they're not 100% dedicated to trying to get
the work done. As a result, they've made enough improvement to get
their work done with n-1 people, where it used to require n. (Note that
this is different from merely reducing costs by 1/n. They're still
getting the work done, and presumably still have enough slack to think
about improving further.)

If I were working on that team, I wouldn't worry about being the
"extra" guy. Any company that could get to this point would (a) be
successful in the market place and thus have opportunities to do new
things, and (b) realize that firing me would be incredibly wasteful.

Consider the cost of hiring someone else, having him learn the problem
domain, get to know the existing codebase, earn the trust of his
teammates, internalize the company processes etc. It'll be 6 months to
a year for that guy to be as efficient as I am. Even if the company
pays me to go windsurfing for a few months, it'll be more cost
effective to keep me around.

I find it difficult to imagine a company that works hard to increase
its efficiency but has no use for the resulting increase in capacity.

Colin
Adrian Howard
2005-03-27 16:13:13 UTC
Permalink
On 26 Mar 2005, at 15:57, Colin Putney wrote:
[snip]
Post by Colin Putney
I find it difficult to imagine a company that works hard to increase
its efficiency but has no use for the resulting increase in capacity.
[snip]

I agree completely.

Adrian
Clarke Ching lists
2005-03-27 16:38:12 UTC
Permalink
Hi Adrian, Colin and others,

I haven't been following this discussion closely so I'm not sure if you were
talking specifically about software companies.

It is quite common for manufacturing companies to have excess capacity (i.e.
they couldn't SELL more product even if they produced it, without changing
their marketing/sales/pricing policies). Some of them deliberately maintain
excess capacity within their plants because it gives them agility and
flexibility in meeting their due dates, and lower lead times - thus keeping
their customers happy.

I'd be interested to hear if there is anyone out there in the software
world, that doesn't have a large backlog of work to do. This would imply
that for those organisations software development is a bottleneck. I can't
think of any.

Clarke Ching
www.clarkeching.com



_____

From: Adrian Howard [mailto:adrianh-/***@public.gmane.org]
Sent: 27 March 2005 17:13
To: xpbookdiscussiongroup-***@public.gmane.org
Subject: Re: [xpe2e] Re: Practice: Shrinking Teams


On 26 Mar 2005, at 15:57, Colin Putney wrote:
[snip]
Post by Colin Putney
I find it difficult to imagine a company that works hard to increase
its efficiency but has no use for the resulting increase in capacity.
[snip]

I agree completely.

Adrian
Colin Putney
2005-03-27 22:23:32 UTC
Permalink
Post by Clarke Ching lists
I'd be interested to hear if there is anyone out there in the software
world, that doesn't have a large backlog of work to do.  This would
imply that for those organisations software development is a
bottleneck.  I can't think of any.
I'm confused. If an organization has a large backlog of software
projects to do, wouldn't that mean than software *is* a bottleneck for
that organization?

In any case, I was speaking about software, although not necessarily
about software companies. I've never encountered an organization that
employed people to write software that didn't have a huge backlog of
things for them to do. I'm told it happens, but in my experience
software development is always a bottleneck.

Colin
Clarke Ching lists
2005-03-28 10:31:59 UTC
Permalink
Post by Colin Putney
Post by Clarke Ching lists
I'd be interested to hear if there is anyone out there in the software
world, that doesn't have a large backlog of work to do. This would
imply that for those organisations software development is a
bottleneck. I can't think of any.
I'm confused. If an organization has a large backlog of software
projects to do, wouldn't that mean than software *is* a bottleneck for
that organization?
Thanks Colin. You have right to be confused. I missed a "not". Sorry.
Post by Colin Putney
... I've never encountered an organization that
employed people to write software that didn't have a huge backlog of
things for them to do. I'm told it happens, but in my experience
software development is always a bottleneck.
That has been my experience too. I've mostly worked for big companies such
as banks where IT is ingrained in their products and processes and IT is on
the critical path for almost all projects.
Zhon Johansen
2005-04-04 15:40:25 UTC
Permalink
Hi Clarke an Colin,
Post by Clarke Ching lists
Post by Colin Putney
... I've never encountered an organization that
employed people to write software that didn't have a huge backlog of
things for them to do. I'm told it happens, but in my experience
software development is always a bottleneck.
That has been my experience too. I've mostly worked for big companies such
as banks where IT is ingrained in their products and processes and IT is on
the critical path for almost all projects.
I too can't think of any software companies that don't have a huge
backlog for software development. Yet, is this truly the bottleneck for
the organization?

Take for example a Software company (I'll call SAFE--Software Actualize
For the Enterprise customer) creating multi-million dollar products for
large enterprise companies. SAFE will often find their customers
require a six month lead time to gather money, signatures, and hardware
to test and roll a SAFE product out. SAFE also has a large software
portfolio with lots of missing features requiring years of backlog for
any development team.

Is the SAFE development team the bottleneck to making money?

Consider other parts of the organization, SAFE's marketing team requires
seven months lead time to prepare for a release. SAFE sales requires 18
months of working with the customer to make a sale. Before SAFE product
management can dollar prioritize the software portfolio they need some
time to... SAFE Manufacturing needs.....

Do we really think development a small part of the whole software supply
chain really is the bottleneck? If this feature or that feature is or
is not implemented, if the feature is or is not buggy how much does this
really impact the money making ability of SAFE?

I don't know the answer. And yet by playing the odd, I am convinced
development cannot always be the bottleneck.

If anyone has answers, I am listening.

- Zhon

Zhon Johansen
www.xputah.org
Sankarson Banerjee
2005-04-05 01:21:11 UTC
Permalink
Not always, you're right. I know this first hand by having managed
the product development for a small software company.

The biggest issue isn't really bandwidth but consistency in
promises. Marketing can do a very good job if it knows beforehand a
solid delivery date for a set of features. Our biggest headache used
to be that were selling a moving target - V1 on 1-Jan one day, then
V0.8 on 3-Feb another day. This is very bad.

The other problem is bug fixes. One V1 is out, we have x people
redeployed to V2 (only a small team doing V1 support), which then
gets promised to some customers. When some big bug comes in V1 (it
always does) or some major feature request from your largest
customer, suddenly priorities change and V2 is pushed out. Then the
whole cycle of bad promises on delivery becomes worse.

Note: this was not XP. We did CMM Level 4.

Shanky
Post by Zhon Johansen
Hi Clarke an Colin,
Post by Clarke Ching lists
Post by Colin Putney
... I've never encountered an organization that
employed people to write software that didn't have a huge
backlog of
Post by Zhon Johansen
Post by Clarke Ching lists
Post by Colin Putney
things for them to do. I'm told it happens, but in my experience
software development is always a bottleneck.
That has been my experience too. I've mostly worked for big
companies such
Post by Zhon Johansen
Post by Clarke Ching lists
as banks where IT is ingrained in their products and processes and IT is on
the critical path for almost all projects.
I too can't think of any software companies that don't have a huge
backlog for software development. Yet, is this truly the
bottleneck for
Post by Zhon Johansen
the organization?
Take for example a Software company (I'll call SAFE--Software
Actualize
Post by Zhon Johansen
For the Enterprise customer) creating multi-million dollar
products for
Post by Zhon Johansen
large enterprise companies. SAFE will often find their customers
require a six month lead time to gather money, signatures, and
hardware
Post by Zhon Johansen
to test and roll a SAFE product out. SAFE also has a large
software
Post by Zhon Johansen
portfolio with lots of missing features requiring years of backlog for
any development team.
Is the SAFE development team the bottleneck to making money?
Consider other parts of the organization, SAFE's marketing team requires
seven months lead time to prepare for a release. SAFE sales
requires 18
Post by Zhon Johansen
months of working with the customer to make a sale. Before SAFE product
management can dollar prioritize the software portfolio they need some
time to... SAFE Manufacturing needs.....
Do we really think development a small part of the whole software supply
chain really is the bottleneck? If this feature or that feature is or
is not implemented, if the feature is or is not buggy how much
does this
Post by Zhon Johansen
really impact the money making ability of SAFE?
I don't know the answer. And yet by playing the odd, I am
convinced
Post by Zhon Johansen
development cannot always be the bottleneck.
If anyone has answers, I am listening.
- Zhon
Zhon Johansen
www.xputah.org
Colin Putney
2005-04-05 03:23:35 UTC
Permalink
Post by Zhon Johansen
I too can't think of any software companies that don't have a huge
backlog for software development. Yet, is this truly the bottleneck for
the organization?
[snip]
Post by Zhon Johansen
I don't know the answer. And yet by playing the odd, I am convinced
development cannot always be the bottleneck.
Zhon,

I think you're right, a backlog of work doesn't necessarily mean that
software development is the bottleneck. However, it *has* been the
bottleneck in the organizations I have worked with.

Here's one example. For a number of years I worked at a sold hotel
reservations over the net. You could book though our web site, or you
could call and talk to a "reservations agent" that would make the
booking for you. We developed our own reservation system in house, and
with interfaces to the web site and the agents. We started with a
couple of agents and a completely manual system - email, spreadsheets,
faxes and Word documents. Over time we wrote software to automate the
booking process, interface to hotel reservation systems, track
commissions, etc.

From the beginning, it was clear that software was the bottleneck. We
had more business than we could handle, and every feature we delivered
made the agents more efficient or made it easier for people to book on
the web site rather than calling. That increased sales in a pretty
straightforward way. At one point, my boss asked me to gather some data
on the efficiency of the reservations agents. I ran a database query
that compared the agent payroll records to the number of bookings we
made during the pay period, then graphed the results in a spreadsheet.

The results were really heart-warming to me as a developer, because
they showed a long and steady decline in the cost-per-booking, almost
entirely attributable to improvements in the software. You could even
make good guesses as to when certain key features had been rolled out,
just by looking at the graph. What was interesting was that the trend
continued even after we added marketing into the equation. Eventually,
we increased our capacity enough to handle the business coming in the
door, and started actively looking for more. At that point, the
features that got added to the software started to be driven by
marketing considerations - new products, better integration with
strategic partners, promotions etc. Even so, the cost-per-booking
continued to decline, as the number of bookings increased faster than
total expenses.

Looking back, it seems that we actually had two bottlenecks. One was in
the business processes themselves: operations at first, and then
gradually shifting over to marketing. But there was also a bottleneck
to the improvement of those processes, which was always the software.
We used software to open up the other bottlenecks, and so software
itself became the bottleneck.

It was frustration with this situation - the desire to open up the
software bottleneck - that caused me to go looking for better ways to
write software, and led to my interest in XP.

Colin
Clarke Ching lists
2005-04-05 19:51:14 UTC
Permalink
Hi Colin,

Thanks for sharing your great story.
Post by Colin Putney
Looking back, it seems that we actually had two bottlenecks. One was in
the business processes themselves: operations at first, and then
gradually shifting over to marketing. But there was also a bottleneck
to the improvement of those processes, which was always the software.
We used software to open up the other bottlenecks, and so software
itself became the bottleneck.

I like to make the distinction between (a) the day-to-day operational side
of business and (b) the project side of the business, which is working to
change - and hopefully improve - the former. At any point in time each of
these "sides" has a bottleneck: (a) your ability to make and/or sell your
current products today (i.e. in the short term) is limited by the
operational bottleneck; your ability to improve in the future is often
limited by the project bottleneck.

I like it how you make the distinction that software was the bottleneck
because every feature you added contributed to increased sales. You are
right that a backlog isn't necessarily a good sign that software development
is a bottleneck. If you looked at the items on the backlog and asked "is
this feature going to make us more money (now or in the future)?" the
answer is often "NO". The only time it will make more money is if it
directly or indirectly improves the performance of the operational
bottleneck or makes more sales (like you describe).

If your operational systems are based around software systems (and this is
become increasingly common) then your project bottleneck is likely to be
your software development. This has been the case for most of my career
where I've worked in finanial or telecoms companies, but it wasn't the case
when I worked in a timber mill - they had plenty of capacity in the mill and
their bottleneck was finding an ongoing supply of timber for decades into
the future.

Clarke
Tim King
2005-04-07 21:32:55 UTC
Permalink
Post by Clarke Ching lists
I like to make the distinction between (a) the day-to-day operational
side of business and (b) the project side of the business...
I agree. These are two independent systems, with potentially two
different bottlenecks. They could even be two different business units,
each with its own process and management.

In (a), the running software makes it hard or easy to conduct business.
It could limit how much business can be conducted or how fast it can be
conducted, in which case this would be a bottleneck.

In (b), the process of developing software can make it hard or easy to
deploy new features. It could limit how quickly new services could be
offered, for example, in which case this would be a bottleneck.

Note that the software process itself doesn't directly affect whether
running software is the bottleneck in (a). Adequate software may have
been developed very slowly and even poorly. (I wouldn't want to place
bets on whether it could be developed again using the same process,
however.)

Also, having a backlog doesn't necessarily mean the software process is
a bottleneck in (b). In fact, it might mean the software process is
_not_ a bottleneck. If urgent features can bubble to the top of the
list, such that they can be deployed quickly, the software process could
provide these features before the business is ready to use them. In this
case, even less urgent features than this would be on the backlog, and
the software process would not be a bottleneck.

-TimK
--
J. Timothy King ..team-oriented..object-oriented..Agile..
www.jtse.com ..C++..Perl..Java..assembly..embedded.systems..
guate84105
2005-04-07 16:44:22 UTC
Permalink
Post by Colin Putney
It was frustration with this situation - the desire to open up the
software bottleneck - that caused me to go looking for better
ways to write software, and led to my interest in XP.
To me your story does not differenciate between
6 months between rolling out new features and 2 week between
rolling out new features, either of which could result in more
bookings per agent as reported, so I don't know from your
description what you wanted to do better. You describe the
change in the rate of the business process, but didn't describe
the rate nor the change in the rate of software production other
than to claim it was a bottleneck. Only the phrase "better ways to
write software" suggests the software production rate might have been
slow. It is this software production rate which is what we are
concerned with in a software process.

Do you understand my concern over the confusion of the various rates
to which you eluded to in the article?

-Paul
Kent Beck
2005-03-29 23:39:42 UTC
Permalink
Carlos,

Thank you for the followup. I've been thinking about the employment issue
too. The announcement by Peace Software that XP had enabled them to shrink
their staff by 20(?)% left me ambivalent. It's hard for me to imagine being
motivated to improve further in that environment. OTOH, if it was that or
have the whole company fail I would take improvement and the chance of
losing my job over the certainty of losing my job every time.

The lean manufacturing world has ideas for getting value from newly-freed
workers: getting training, consulting with other teams, experimenting with
new products or processes, forming new teams, working with marketing or
sales. A company anticipating growth will find ways for freed-up workers to
add value. A company needing to cut costs has a dilemma: keep the excess
workers around or fire them and risk squelching further improvement.

Ideally, freed-up workers would get to start on the next, great money-making
project.

Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Friday, March 25, 2005 4:39 AM
Subject: [xpe2e] Re: Practice: Shrinking Teams
I've been thinking about the unemployment issue...
We know that XP minds the human/social aspect of software development.
I sincerally understand the goal of eliminating waste and even think
that an idle team merber can add waste.
But if we don't need forming more teams what would we do with the
idle team member? Fire him?
Luiz Esmiralha
2005-03-30 15:25:32 UTC
Permalink
Kent,

I understand and share some of Carlos' feelings about "Shrinking
Teams" and unemployment. Brazil is facing an unemployment rate high
peak and definitely can't be seen right now as a culture of abundance,
where people can be kept around until the next project shows up.

Regards,
Luiz
Post by Kent Beck
Carlos,
Thank you for the followup. I've been thinking about the employment issue
too. The announcement by Peace Software that XP had enabled them to shrink
their staff by 20(?)% left me ambivalent. It's hard for me to imagine being
motivated to improve further in that environment. OTOH, if it was that or
have the whole company fail I would take improvement and the chance of
losing my job over the certainty of losing my job every time.
The lean manufacturing world has ideas for getting value from newly-freed
workers: getting training, consulting with other teams, experimenting with
new products or processes, forming new teams, working with marketing or
sales. A company anticipating growth will find ways for freed-up workers to
add value. A company needing to cut costs has a dilemma: keep the excess
workers around or fire them and risk squelching further improvement.
Ideally, freed-up workers would get to start on the next, great
money-making
project.
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Friday, March 25, 2005 4:39 AM
Subject: [xpe2e] Re: Practice: Shrinking Teams
I've been thinking about the unemployment issue...
We know that XP minds the human/social aspect of software development.
I sincerally understand the goal of eliminating waste and even think
that an idle team merber can add waste.
But if we don't need forming more teams what would we do with the
idle team member? Fire him?
Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Kent Beck
2005-03-31 07:56:02 UTC
Permalink
Luiz,

I think most people who work in technology are concerned about their jobs.
The question is, what does XP have to say about job security? Desperately
hanging onto a job by any means necessary doesn't lead to either personal
satisfaction or job security. I think integrity and accountability are
particularly important in a climate of fear. The culture of abundance is
inside your heart, not something you rely on someone else to hand you. If
XPers becomes known as people who work hard and honestly even in the most
trying circumstances, then we will be in a good position to influence
software development during the next upturn. If we abandon our principles at
the first sign of trouble, our principles must not be worth much.

Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Wednesday, March 30, 2005 7:26 AM
Subject: Re: [xpe2e] Re: Practice: Shrinking Teams
Kent,
I understand and share some of Carlos' feelings about "Shrinking
Teams" and unemployment. Brazil is facing an unemployment rate high
peak and definitely can't be seen right now as a culture of abundance,
where people can be kept around until the next project shows up.
Regards,
Luiz
Sankarson Banerjee
2005-04-02 01:54:18 UTC
Permalink
The social issue of what to do with surplus employees should not
impact the process of software development. It's a fallacy that the
two are linked; that if something gets done with 20% less resources
that those resources will need to be moved somewhere else.

The decision to lay off or not isn't linked to who is idle at a
point in time; productive workers are just as likely be laid off
because the company has to trim costs. For example, a school system
may lay off teachers even when there are students to be taught,
because there isn't enough money for all. Maybe they'll close the
Arts faculty and fire their award-winning music teacher, while
retaining an incompetent kindergarten teacher.

IT departments need people as production capacity. This is not true
of every department, but it is defnitely true of IT. No company
expects to shrink forever, or even for long periods - so replacement
cost is a very important concern for every layoff. There will always
be more projects and more work to do unless the company as a whole
is in trouble, or as is most common now - a merger has happened. One
does not fire a worked simply because there isn't any immediate
project - the cost of hiring a replacement when a project comes
along two months later is far too much. At minimum, you're paying a
headhunter, spending senior time on interviews, doing inductions,
building new team chemistry, potentially hiring the wrong person...

Shanky
Post by Luiz Esmiralha
Kent,
I understand and share some of Carlos' feelings about "Shrinking
Teams" and unemployment. Brazil is facing an unemployment rate high
peak and definitely can't be seen right now as a culture of
abundance,
Post by Luiz Esmiralha
where people can be kept around until the next project shows up.
Regards,
Luiz
Post by Kent Beck
Carlos,
Thank you for the followup. I've been thinking about the
employment issue
Post by Luiz Esmiralha
Post by Kent Beck
too. The announcement by Peace Software that XP had enabled
them to shrink
Post by Luiz Esmiralha
Post by Kent Beck
their staff by 20(?)% left me ambivalent. It's hard for me to imagine being
motivated to improve further in that environment. OTOH, if it was that or
have the whole company fail I would take improvement and the chance of
losing my job over the certainty of losing my job every time.
The lean manufacturing world has ideas for getting value from newly-freed
workers: getting training, consulting with other teams,
experimenting with
Post by Luiz Esmiralha
Post by Kent Beck
new products or processes, forming new teams, working with
marketing or
Post by Luiz Esmiralha
Post by Kent Beck
sales. A company anticipating growth will find ways for freed-
up workers to
Post by Luiz Esmiralha
Post by Kent Beck
add value. A company needing to cut costs has a dilemma: keep the excess
workers around or fire them and risk squelching further
improvement.
Post by Luiz Esmiralha
Post by Kent Beck
Ideally, freed-up workers would get to start on the next, great
money-making
project.
Kent Beck
Three Rivers Institute
-----Original Message-----
Sent: Friday, March 25, 2005 4:39 AM
Subject: [xpe2e] Re: Practice: Shrinking Teams
I've been thinking about the unemployment issue...
We know that XP minds the human/social aspect of software
development.
Post by Luiz Esmiralha
Post by Kent Beck
I sincerally understand the goal of eliminating waste and
even think
Post by Luiz Esmiralha
Post by Kent Beck
that an idle team merber can add waste.
But if we don't need forming more teams what would we do with the
idle team member? Fire him?
Yahoo! Groups Sponsor
ADVERTISEMENT
________________________________
Yahoo! Groups Links
http://groups.yahoo.com/group/xpbookdiscussiongroup/
Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
Loading...