--- In extremeprogramming@yahoogroups.com, "Gary Brown" <glbrown@...>
wrote:
>
> This is a current issue in my organization. In the past, we have
responded
> to the ImproveProductivity command, by hiring more developers. Every
time
> we did that, TotalVelocity dropped for about six months, then got back
to
> even for a few months, then improved.
>
> Before anyone jumps on the obvious Velocity != Productivity argument,
allow
> me to explain. Let's say that I have five teams of six developers (30
> people), with a TotalVelocity of 120. TotalVelocity is the sum of
> TeamVelocity for all five teams. I add twelve developers (now 42
people),
> and reorganize into seven teams of six people. TotalVelocity goes to
60.
>
> We have gone from 4 units of work per developer, to 1.4 units of work
per
> developer. How did that happen? In my organization, pure technical
skills
> are a small part of what we need from our developers (I expect that is
true
> in your organization, as well). They also need to learn our business,
our
> applications, XP style development, and how to work in a team (a real
team,
> not one of those everyone in their own cubes, doing their own thing
teams).
> The new people need to get up to speed. That puts a drag on the team.
>
> We are fortunate, that we have an organization based on trust and
honesty.
> Our existing developers knew our way of estimating and calculating
Velocity,
> and stuck with it, even though they knew the numbers went down. It is
easy
> to game Velocity.
>
> Having lived through that experience a few times, we have decided to
take a
> different approach to that latest ImproveProductivity command. We are
not
> going to hire new developers, over and above attrition (about 7% here,
which
> is 5 - 6 people). We are going to improve our skills, improve our
code, and
> eliminate waste.
>
> The metrics we have decided will tell us how we are doing are
completed
> stories, average story size, defects delivered to production, and
project
> efficiency. Project efficiency is measured by completing a Value
Stream
> Map, see "Lean Software Development - From Concept to Cash", by the
> Poppendiecks. VSMs can be a bit subjective, but if you are able to be
> honest about them, they will point you to areas for improvement.
>
> We are taking a leap of faith here, but we think that this path has a
better
> chance of actually improving productivty.
>
> GB.
>

Gary -

Productivity is value created per employee and is a measure of
performance of the organization. Lean manufacturing abandoned detailed
cost accounting, which attempted to assign increments of value and
associated costs to each part and each step used to produce parts and
assemble products decades ago. Attempts to subdivide contributions to
productivity in software development are equally destructive to progress
in actually improving productivity. This may seem paradoxical but the
way to improve productivity is to remove waste.

Value is defined by what a customer is willing to pay for.

Increase productivity by delivering more value by eliminating waste.
Investing time to implement less valuable stories instead of spending
the time to identify and implement more valuable stories is an obvious
example of waste.

Relentlessly eliminate waste by respecting people by training and
leading them to collaboratively improve their tools, skills, practices,
processes, and understanding of what is valuable to the customer.

Do not confuse performance measures with data. If you treat velocity as
data, it is useful for planning. As soon as you treat velocity as a
performance measure, the integrity of estimates will vanish and each
story point will represent fewer and fewer hours of work.

Delivery of the benefits promised in a business case is the most
important measure of the performance of a product development effort.
Data about costs of each part, conformance to plans, and all the
tradeoffs made in pursuit of the expected benefits may be informative
and useful in the context of steering this effort and hopefully for
future similar efforts but these are not usefully construable as
performance indicators.

Cycle time is the most important measure for development process
performance. Cycle times begin and end with the customer. If the
process is fixing defects this is the time from detecting a defect that
is going to be fixed to the time the repair is in production. If the
process is adding a feature to an existing application, it is the time
from when the feature is requested and put on the list of things that
really will get done to the time the new feature is live in production.
If the process is creating a new application, the time is from when a
concept is selected for implementation to the time the application is
live for a real customer. Data about defects, story points per
iteration, etc. are useful to help with understanding the process and
forming hypotheses to be tested by experiments to see if a change will
actually improve performance.

Jim Womack addressed one aspect of "Respect People" in his
December newsletter
http://tech.groups.yahoo.com/group/leandevelopment/message/2344
<http://tech.groups.yahoo.com/group/leandevelopment/message/2344> where
he makes the point that a competent lean manager will teach each person
they manage to see waste and to identify opportunities to eliminate it.
Then s/he will collaborate with anyone with an idea to define a
meaningful experiment to assess the idea and provide whatever is require
to try the idea and ensure appropriate data is collected to determine
whether it is actually an improvement. Eliminating instances any of the
7 wastes will add value and hence increase productivity.

Much more about the lean view of "Respect for People" is at
http://www.superfactory.com/articles/Emiliani_respect_people_0208_print.\
htm
<http://www.superfactory.com/articles/Emiliani_respect_people_0208_print\
.htm>

- Tom



[Non-text portions of this message have been removed]