Home > Archive > Extreme Programming > July 2004 > Design for Six Sigma (for Software)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Design for Six Sigma (for Software)
|
|
| Isaac Gouy 2004-06-24, 7:01 pm |
| The emphasis in popular management books on DFSS seems to run /so/
counter to the emphasis in XP:
"Basically, the first step is all about coming up with a detailed,
ambitious but manageable Project Plan, one that includes the project's
objectives and goals, the scope of what you're addressing, and a
timeline for getting it all done. I can't stress enough the need to be
/specific/, and /to write it down!/ Ideas that aren't written down
float away. Putting them in writing makes them real. Things that are
written down happen; things that are merely discussed do not."
| |
| Robert C. Martin 2004-06-24, 7:01 pm |
| On 24 Jun 2004 10:16:38 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
>The emphasis in popular management books on DFSS seems to run /so/
>counter to the emphasis in XP:
Well, lets do a comparison:
>"Basically, the first step is all about coming up with a detailed,
>ambitious but manageable Project Plan, one that includes the project's
>objectives and goals, the scope of what you're addressing, and a
>timeline for getting it all done. I can't stress enough the need to be
>/specific/, and /to write it down!/ Ideas that aren't written down
>float away. Putting them in writing makes them real. Things that are
>written down happen; things that are merely discussed do not."
The first step in an XP project is exploration. This is when we talk
over the project with the stakeholders and write the story cards.
Next we create a plan for the first iteration, and the first release.
This plan is a sequence of stories allocated into time boxes.
This plan exists in physical form, either as a stack of cards, or as a
list of stories on a whiteboard, or some other equivalent form.
Where do you see the difference in emphasis? Note, I'm not trying to
claim that XP is just like SS, I just don't see the drastic difference
in emphasis in the quoted paragraph.
-----
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
| |
|
| Robert C. Martin wrote:
> Next we create a plan for the first iteration, and the first release.
> This plan is a sequence of stories allocated into time boxes.
I'm not sure about calling them time boxes. I guess 3 story units for a
given story, at a velocity of 2 days per story point, I might keep working
until the six days are up.
Frequent customer review is supposed to control scope, but I'd reserve the
term "time box" for 30 to 90 minute experiments before giving up without
progress and trying something else.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
| |
| Isaac Gouy 2004-06-25, 6:46 pm |
| Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<375md0p6h5huv4u1p5qjcejl0ovhnr18ja@4ax.com>...
> On 24 Jun 2004 10:16:38 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
>
>
> Well, lets do a comparison:
>
>
> The first step in an XP project is exploration. This is when we talk
> over the project with the stakeholders and write the story cards.
>
> Next we create a plan for the first iteration, and the first release.
> This plan is a sequence of stories allocated into time boxes.
>
> This plan exists in physical form, either as a stack of cards, or as a
> list of stories on a whiteboard, or some other equivalent form.
>
> Where do you see the difference in emphasis? Note, I'm not trying to
> claim that XP is just like SS, I just don't see the drastic difference
> in emphasis in the quoted paragraph.
"a timeline for getting it all done"
(Note: DFSS not SS)
| |
| Scott Kinney 2004-06-25, 6:46 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0406250847.19b639cb@posting.google.com...
> Robert C. Martin <unclebob@objectmentor.com> wrote in message
news:<375md0p6h5huv4u1p5qjcejl0ovhnr18ja@4ax.com>...
>
> "a timeline for getting it all done"
>
> (Note: DFSS not SS)
It's awful to commit to a result, isn't it?
| |
| Laurent Bossavit 2004-06-25, 6:46 pm |
| Isaac:
>
> "a timeline for getting it all done"
> (Note: DFSS not SS)
How about the Release Plan ?
Laurent
| |
| Robert C. Martin 2004-06-25, 6:46 pm |
| On Thu, 24 Jun 2004 18:07:27 GMT, "Phlip" <phlip_cpp@yahoo.com> wrote:
>Robert C. Martin wrote:
>
>
>I'm not sure about calling them time boxes. I guess 3 story units for a
>given story, at a velocity of 2 days per story point, I might keep working
>until the six days are up.
I was referring to iterations. Iterations are true timeboxes.
-----
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
| |
| Robert C. Martin 2004-06-25, 6:46 pm |
| On 25 Jun 2004 09:47:43 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
>Robert C. Martin <unclebob@objectmentor.com> wrote in message news:<375md0p6h5huv4u1p5qjcejl0ovhnr18ja@4ax.com>...
>
>"a timeline for getting it all done"
That's the XP release plan. After exploration we plan out the next
several months worth of work by allocating stories to the next
half-dozen or so iterations.
This time-line is highly volatile; but it exists from the beginning
and is changed only as new data makes those changes necessary.
>(Note: DFSS not SS)
;-) How about 6E
-----
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
| |
| Robert C. Martin 2004-06-25, 6:46 pm |
| On Fri, 25 Jun 2004 14:02:40 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>It's awful to commit to a result, isn't it?
It's awful if you aren't sure you can make it. In fact, it's
irresponsible.
Software professionals have often placed themselves in an untenable
situation by making commitments they aren't sure they can meet. This
is not fair to their customers, to their managers, or to themselves.
Instead, developers have to learn how to present completion dates as a
probability; and they have to learn how to compute that probability.
See:
www.objectmentor.com/resources/listArticles?key=topic&topic=Project%20Management
-----
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
| |
| Scott Kinney 2004-06-29, 3:56 am |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:lgtod09916tdi7ur6itt0v48qqp6qrbpel@
4ax.com...
> On Fri, 25 Jun 2004 14:02:40 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
>
> It's awful if you aren't sure you can make it. In fact, it's
> irresponsible.
>
> Software professionals have often placed themselves in an untenable
> situation by making commitments they aren't sure they can meet. This
> is not fair to their customers, to their managers, or to themselves.
>
From my perspective as the project manager, I see this a little
differently. In my experience, where there's a project:
the business owner/sponsor has committed to a result
I've committed to a result
Members of my team commit to the result.
When software developers on the team won't
commit to a result, well, we've got to pull apart the ambivalence...
If they disagree with the goal, it's their responsibility to say so and say
why
If they disagree with the strategy, it's their responsibility to say so and
say why
If they feel they don't have the right resources,...you get the idea
If they lack confidence in their abilities, they need to frank about that as
well.
If they're just afraid of making a commitment because they've been burned
before, then they've got to find a way to get over it, or they won't be
taken
seriously as partners to the solution.
If they just fold their arms and mutter that it's never going to work, then
they'll get replaced.
It's not fair to the rest of the team if they're dragging their feet the
whole way.
(Note: this applies to everyone on the team, not just software or
application
folks. )
As the project manager, I'll help people who are trying, but having a
hard time, I'll remove barriers, negotiate away competing work, get
them expert support if they're trying to help themselves. I'm not so
sanguine about people who refuse to help themselves.
> Instead, developers have to learn how to present completion dates as a
> probability; and they have to learn how to compute that probability.
>
I agree, and that means they'll have to learn some tools, become
comfortable with a certain level of ambiguity, and if at all possible,
partner up with a real-live-certified project manager (whether that's a PMP,
a Prince2 cert, or the equivalent.)
> See:
>
www.objectmentor.com/resources/list...roject%20Manage
ment
>
I have a couple of questions (and corrections) for "Agile Methods: The
Bottom Line."
The main questions first:
It seems to me that both teams; 'exaggerated for effect' and 'Agile Methods'
have certain information about the project:
how much work has been done,
how much remains to be done,
changed and new requirements,
effects of actual information on estimates.
For whatever reason (you don't give one, perhaps it's
a Lovecraftian nameless dread.) the 'exaggerated for effect' team
is unwilling to update their project charts to avoid giving the news
that the project will take longer than the given date.
I don't see anything in the 'Agile Methods' team that would overcome
that same fear. Did I miss something?
Also, a project network chart shows all four of the
previously mentioned data unambigously in one picture.
The Agile Method requires two pictures and interpolation to
get the same data. Why is this clearer?
Corrections (sort of)
In the 6th paragraph, I think you mean the "date" is frozen, not "data".
Also, you really know 3 things about the project; its goal, its main
strategy and
the date.
In the 7th paragraph, the name of the chart is "Gantt", not "GHANT". (Since
it's
someone's name, there's no need to capitalize every letter.)
In your final paragraph, the French phrase is spelled "raison d'etre". It
means
"The purpose which justifies a thing's existence.", do you really mean to
say the
the purpose of , or the reason that Agile Methods exist is to generate data
about
software development?
| |
| Robert C. Martin 2004-06-29, 4:04 pm |
| On Mon, 28 Jun 2004 22:06:27 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:lgtod09916tdi7ur6itt0v48qqp6qrbpel@
4ax.com...
>From my perspective as the project manager, I see this a little
>differently. In my experience, where there's a project:
>the business owner/sponsor has committed to a result
>I've committed to a result
>Members of my team commit to the result.
>When software developers on the team won't
>commit to a result, well, we've got to pull apart the ambivalence...
Does your lawyer commit to winning your cases? Does your doctor
commit to curing your ills? We can claim that these people aren't
"team-players" when they refuse to commit, but I think that's
specious.
There is no certainty in developing software. The only commitments
that can be made are commitments to "do our best." Managers may not
like this; but that's the managers' problem.
<<I agree with all elided statements>
>
>As the project manager, I'll help people who are trying, but having a
>hard time, I'll remove barriers, negotiate away competing work, get
>them expert support if they're trying to help themselves. I'm not so
>sanguine about people who refuse to help themselves.
A developer who refuses to commit to a date is not a developer who
refuses to help themselves. Such a developer may be honestly saying
that any such commitment is no better than hope and prayer, and that
some "better" way must be found to measure progress and manage the
project.
Management by commitment is not a very reliable technique. On the
other hand, management by continuous measurement is very reliable.
>
>I agree, and that means they'll have to learn some tools, become
>comfortable with a certain level of ambiguity, and if at all possible,
>partner up with a real-live-certified project manager (whether that's a PMP,
>a Prince2 cert, or the equivalent.)
Agreed. By the same token, project managers, and everyone they report
to also have to learn to deal with a certain amount of ambiguity and
risk.
>
>www.objectmentor.com/resources/list...roject%20Manage
>ment
>
>I have a couple of questions (and corrections) for "Agile Methods: The
>Bottom Line."
>
>The main questions first:
>
>It seems to me that both teams; 'exaggerated for effect' and 'Agile Methods'
>have certain information about the project:
>how much work has been done,
>how much remains to be done,
>changed and new requirements,
>effects of actual information on estimates.
>
>For whatever reason (you don't give one, perhaps it's
>a Lovecraftian nameless dread.) the 'exaggerated for effect' team
>is unwilling to update their project charts to avoid giving the news
>that the project will take longer than the given date.
>I don't see anything in the 'Agile Methods' team that would overcome
>that same fear. Did I miss something?
Yes. Particularly Agile Methods are about measurement, whereas
non-agile methods are about conformance to plan. An agile team
measures continuously and replans based on those measurements. A
non-agile team tries to force the existing plan to be true, despite
measurements to the contrary.
Clearly serious project managers don't behave in a non-agile way.
Unfortunately there are a vast number of project managers who do.
Indeed, there are far too many project management techniques that can
have a non-agile interpretation.
One of the big differences between agile and non-agile disciplines is
that agile disciplines are specifically designed to generate data that
can be meaningfully measured. Non-agile methods are not.
>Also, a project network chart shows all four of the
>previously mentioned data unambigously in one picture.
>The Agile Method requires two pictures and interpolation to
>get the same data. Why is this clearer?
You can use any chart you wish to represent the data. I find the two
charts in the article to be intuitive to people who aren't familiar
with more complex tools.
>Corrections (sort of)
>In the 6th paragraph, I think you mean the "date" is frozen, not "data".
>Also, you really know 3 things about the project; its goal, its main
>strategy and
>the date.
>In the 7th paragraph, the name of the chart is "Gantt", not "GHANT". (Since
>it's
>someone's name, there's no need to capitalize every letter.)
Thanks for the copy edits.
>In your final paragraph, the French phrase is spelled "raison d'etre". It
>means
>"The purpose which justifies a thing's existence.", do you really mean to
>say the
>the purpose of , or the reason that Agile Methods exist is to generate data
>about
>software development?
Yes.
-----
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
| |
| Scott Kinney 2004-06-29, 4:04 pm |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:nv13e0108b04t8bvil4l4j74nai36oh0fi@
4ax.com...
> On Mon, 28 Jun 2004 22:06:27 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Does your lawyer commit to winning your cases? Does your doctor
> commit to curing your ills? We can claim that these people aren't
> "team-players" when they refuse to commit, but I think that's
> specious.
>
Actually, she (the lawyer on my last two projects) does. She commits
to winning the case; and as a result; selects a strategy and supporting
tactics commensurate with winning the case, and does the preparation
required to implement. She acts 'as if' she will win the case. That's not
the same thing as guaranteeing an outcome, but it does provide a
basis upon which to proceed. The outcome can still be bad, not every
thing is under our control, but taking purposeful action requires that
you believe in ultimate success.
> There is no certainty in developing software. The only commitments
> that can be made are commitments to "do our best." Managers may not
> like this; but that's the managers' problem.
>
Very few meaningful undertakings come with guarantees. I fail to see
why software developers should be immune to the same risks that
everyone else involved is subject to.
> <<I agree with all elided statements>
>
> A developer who refuses to commit to a date is not a developer who
> refuses to help themselves. Such a developer may be honestly saying
> that any such commitment is no better than hope and prayer, and that
> some "better" way must be found to measure progress and manage the
> project.
>
My point was, if folding their arms and demurring on results and/or dates
is *all* they're doing, then they are refusing to help themselves, and
refusing to help their teammates. If they won't contribute alternative
strategies, rationales, data, experience to back up their ambivalence,
then they are refusing to help themselves and the team.
> Management by commitment is not a very reliable technique. On the
> other hand, management by continuous measurement is very reliable.
I don't know what 'management by commitment' is. I only know that
commitment is a required component for a team.
PMP,[color=darkred]
>
> Agreed. By the same token, project managers, and everyone they report
> to also have to learn to deal with a certain amount of ambiguity and
> risk.
They already know how to deal with risk and amibguity. Someone who says
"I'm not going to commit to achieving that result, I don't agree with it,
I don't agree with how you're going about it, I'm not going to offer any
reasons, or alternatives. I'm not going to expose myself to the same risks
as everyone else. I don't have to tell you my strategy for doing this work,
or estimate its completion. I'm just going to 'do my best.'", does not
represent ambiguity. They represent a kind of passive/aggressive
instransigence.
And you're right, that is the manager's problem. I can say from experience,
though that there's no guarantee that they'll like the manager's solution.
>
>www.objectmentor.com/resources/list...Project%20Manag
e
Methods'[color=darkred]
>
> Yes. Particularly Agile Methods are about measurement, whereas
> non-agile methods are about conformance to plan. An agile team
> measures continuously and replans based on those measurements.
> A non-agile team tries to force the existing plan to be true, despite
> measurements to the contrary.
>
This is untrue, and shows a lack of understanding of the methods and
purposes of project management. Granted, it's consistent with Agile
rhetoric, and it helps you make your point. It just isn't an accurate
reflection of 'serious' practice.
> Clearly serious project managers don't behave in a non-agile way.
> Unfortunately there are a vast number of project managers who do.
> Indeed, there are far too many project management techniques that can
> have a non-agile interpretation.
Which doesn't justify your comparison of a bad implementation of
one methodology against the serious implementation of another.
It's no surprise that you came to the conclusion you did. I'd have
more respect for your analysis if you did a straight up comparison of
serious practice of both methodologies.
Imagine the argument I could make comparing the serious practice
of 'classical' project management to the bad or even negligent practice
of an Agile Methodology. I can hear the protests now, and they'd
be right. To be intellectually honest, you need to take both methodologies
seriously. Not better than what they are, but not worse than they are,
either.
>
> One of the big differences between agile and non-agile disciplines is
> that agile disciplines are specifically designed to generate data that
> can be meaningfully measured. Non-agile methods are not.
>
Untrue on its face.
>
data[color=darkred]
>
> Yes.
>
I'm not sure I follow this. My mental analogy is that the GPS, speedometer
and
odometer of a car provide extremely important information, but they are not
the raison d'etre of the car.
| |
| Ronald E Jeffries 2004-06-29, 4:04 pm |
| On Tue, 29 Jun 2004 13:16:12 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>This is untrue, and shows a lack of understanding of the methods and
>purposes of project management. Granted, it's consistent with Agile
>rhetoric, and it helps you make your point. It just isn't an accurate
>reflection of 'serious' practice.
Scott, I can tell you that it is very consistent with serious practice
in almost every client site I visit. Management sets deadlines and
"holds programmers' feet to the fire". When deadlines are not met, it
is deemed to be the fault of the programmers.
There are two important issues with this, both perhaps subject to
debate:
First, when deadlines are not met, it is very likely NOT the fault of
the programmers. It is just as likely the fault of the managers, or of
the requirements givers.
Second, if the organization is not /prepared/ for the deadline not to
be met, this is a clear failure of management to get the right
information, or to act on it, or both.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Scott Kinney 2004-06-29, 8:56 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:7ud3e0hjmjiqtqsukn1s75ln3140reblab@
4ax.com...
> On Tue, 29 Jun 2004 13:16:12 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Scott, I can tell you that it is very consistent with serious practice
> in almost every client site I visit. Management sets deadlines and
> "holds programmers' feet to the fire". When deadlines are not met, it
> is deemed to be the fault of the programmers.
>
We'll probably have to chalk this up to different worlds of
experience. In 17 years of project management the people I've
trained with, worked with and worked for have all been held to much
higher standards of performance. I'd have gotted my head handed
to me for any of the things you and Robert cite as 'serious project
management.' I'll be sticking by my own experience, thank you.
Don't get me wrong, I've seen the kind of work you describe. Not
that I'd consider them role models. They seem to spring from two
main sources; consultants from big 8 accounting firms, and people
who've been 'pronounced' project managers by their bosses.
> There are two important issues with this, both perhaps subject to
> debate:
>
> First, when deadlines are not met, it is very likely NOT the fault of
> the programmers. It is just as likely the fault of the managers, or of
> the requirements givers.
Absent any other information, the fault for missing a deadline lays
equally on everyone, I agree. (Although, having 'been in front of the
big desk' on those occasions, more of the fingers were pointing at
me than at programmers.....)
>
> Second, if the organization is not /prepared/ for the deadline not to
> be met, this is a clear failure of management to get the right
> information, or to act on it, or both.
Specifically, it would be the fault of the project manager.
| |
| Ronald E Jeffries 2004-06-30, 4:00 am |
| On Tue, 29 Jun 2004 18:41:30 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>We'll probably have to chalk this up to different worlds of
>experience. In 17 years of project management the people I've
>trained with, worked with and worked for have all been held to much
>higher standards of performance. I'd have gotted my head handed
>to me for any of the things you and Robert cite as 'serious project
>management.' I'll be sticking by my own experience, thank you.
>
>Don't get me wrong, I've seen the kind of work you describe. Not
>that I'd consider them role models. They seem to spring from two
>main sources; consultants from big 8 accounting firms, and people
>who've been 'pronounced' project managers by their bosses.
I don't think Bob or I are holding them up as role models either, just
as very typical cases, in companies ranging from small to large.
>
>
>Absent any other information, the fault for missing a deadline lays
>equally on everyone, I agree. (Although, having 'been in front of the
>big desk' on those occasions, more of the fingers were pointing at
>me than at programmers.....)
I don't see how the workers can be at fault for missing a deadline if
there's a manager around somewhere. Management does that planning
staffing organizing directing controlling thing, and owns the
responsibility to measure project progress and do something about it
if it's not coming in.
I could imagine a manager who delegated the responsibility /and/ the
authority, though I have rarely seen one. And even then, the folks up
the chain cannot really justly wash their hands of it all.
>
>Specifically, it would be the fault of the project manager.
Only if the PM owns the company. The buck stops at the top as I read
the rulebook.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Frédéric Gédin 2004-06-30, 4:00 am |
| Ronald E Jeffries wrote:
>
> I don't see how the workers can be at fault for missing a deadline if
> there's a manager around somewhere. Management does that planning
> staffing organizing directing controlling thing, and owns the
> responsibility to measure project progress and do something about it
> if it's not coming in.
Taking your way of thinking in an other way, can we say that you don't see
either how the workers can be congratulated for attaining a deadline if
there is a manager somewhere?
I really think that success and failure is under the responsibility of all
the stakeholders.
>
> I could imagine a manager who delegated the responsibility /and/ the
> authority, though I have rarely seen one. And even then, the folks up
> the chain cannot really justly wash their hands of it all.
I agree. It is not because a manager delegates that he does not still have
to manage. If he does not manage the team, he still has to manage the
person who received delegation.
Regards.
Frederic
| |
| Scott Kinney 2004-06-30, 9:04 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:2874e0h6q3pbbupfjekdbgjakct4ejdhh8@
4ax.com...
> On Tue, 29 Jun 2004 18:41:30 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
> I don't think Bob or I are holding them up as role models either, just
> as very typical cases, in companies ranging from small to large.
OK, they're not role models, they're just your consistently applied
standard for comparison.......
[color=darkred]
>
> I don't see how the workers can be at fault for missing a deadline if
> there's a manager around somewhere. Management does that planning
> staffing organizing directing controlling thing, and owns the
> responsibility to measure project progress and do something about it
> if it's not coming in.
>
You're too funny...if you just try a little harder you could be
pinning the blame on 'society as a whole', or the TriLateral Commission,
or a vast Luddite conspiracy.
>
> Only if the PM owns the company. The buck stops at the top as I read
> the rulebook.
The top of the project is the PM.
| |
| Ronald E Jeffries 2004-06-30, 9:04 am |
| On Wed, 30 Jun 2004 08:09:29 +0200, Frédéric Gédin <badaddress@bad.fr>
wrote:
>
>Taking your way of thinking in an other way, can we say that you don't see
>either how the workers can be congratulated for attaining a deadline if
>there is a manager somewhere?
>I really think that success and failure is under the responsibility of all
>the stakeholders.
Very good question, as it challenges me to be more clear about what I
think on this topic. Let's see whether I can. Hmmmm ...
Generally speaking, I do believe that success is a team result, and
that failure is not. That is the contradiction that you, Frédéric,
observed, and in fact I embrace that contradiction.
Let's go back to what I originally said:
>When deadlines are not met, it
>is deemed to be the fault of the programmers.
>
>There are two important issues with this, both perhaps subject to
>debate:
>
>First, when deadlines are not met, it is very likely NOT the fault of
>the programmers. It is just as likely the fault of the managers, or of
>the requirements givers.
>
>Second, if the organization is not /prepared/ for the deadline not to
>be met, this is a clear failure of management to get the right
>information, or to act on it, or both.
So I'm saying that except in the very rare case where the team is
completely autonomous, the team "owner" has a kind of responsibility
for failure that she does not have for success. She has the
responsibility to track the team well enough to know when they're off
track, and to do what is necessary to get them back on, or to stop the
project, long before it fails.
Does that make any kind of sense?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Scott Kinney 2004-06-30, 3:58 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:rp05e01rsd67gt2pdsue9qf4vads32jm10@
4ax.com...
> On Wed, 30 Jun 2004 08:09:29 +0200, Frédéric Gédin <badaddress@bad.fr>
> wrote:
>
see[color=darkred]
all[color=darkred]
>
> Very good question, as it challenges me to be more clear about what I
> think on this topic. Let's see whether I can. Hmmmm ...
>
> Generally speaking, I do believe that success is a team result, and
> that failure is not. That is the contradiction that you, Frédéric,
> observed, and in fact I embrace that contradiction.
>
Ron, you and Robert have painted a very compelling picture:
We're entitled to swagger a little as providers of real,
measurable business value.
We share in the credit when the project is successful.
We don't have to take on the same risks as our
business sponsor, or even the same risks as our
project teammates.
We owe no more quantifiable performance committment
than "We'll do our best."
And the best part is, wait for it.....
if it all goes to hell, it's never our fault, there's
always someone else to blame.
It's just too beautiful.
Then I wake up.
I remember that real rewards come with real risks.
I remember that putting my ass out on the line with
my business sponsor will earn more trust than the
bland assurance that 'I'll do my best.'
I remember that being part of a team comes with
a set of responsibilities; among them the responsibility
to actively communicate instead of waiting for someone
to read my mind.
Oddly, sometimes I remember Sir Ranulph Fiennes;
deathly afraid of heights, so the only way he could
parachute in the SAS was to
close his eyes when he jumped from the planes.
| |
| Ron Ruble 2004-06-30, 3:58 pm |
|
"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:UoudnVtbzZmHbXzdRVn_iw@comcast.com...
>
> "Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:7ud3e0hjmjiqtqsukn1s75ln3140reblab@
4ax.com...
<snip>[color=darkred]
> We'll probably have to chalk this up to different worlds of
> experience. In 17 years of project management the people I've
> trained with, worked with and worked for have all been held to much
> higher standards of performance. I'd have gotted my head handed
> to me for any of the things you and Robert cite as 'serious project
> management.' I'll be sticking by my own experience, thank you.
>
> Don't get me wrong, I've seen the kind of work you describe. Not
> that I'd consider them role models. They seem to spring from two
> main sources; consultants from big 8 accounting firms, and people
> who've been 'pronounced' project managers by their bosses.
I think it's more pervasive than that. I agree that the two
examples you mention are both typical sources of this
sort of thing, but this has been growing for a long time
in a large number of 'sick' organizations.
By 'sick', I mean those organization with existing, significant.
problems which are not adequately recognized or addressed
by management. Often this results from pressure to make
money-losiing ventures show a profit, or overcommitments.
It's also typified by organizations that actively prevent
open and honest communication. Everyone lies to
everyone else, and never mentions the emperor has
no clothes.
>
> Absent any other information, the fault for missing a deadline lays
> equally on everyone, I agree. (Although, having 'been in front of the
> big desk' on those occasions, more of the fingers were pointing at
> me than at programmers.....)
One caveat. -If- the development staff was not consulted before
a deadline was determined, and -if- the development staff informed
the PM that the date was unworkable, and -if- the PM responded
by covering up the problem (or being ordered or encouraged by
his superiors to ignore the problem and lash the coders harder),
then the fault is that of management.
I have found myself in at least 3 projects in the last few years,
all for different companies, where I had to escalate this kind of
problem over at least three levels of management just to get an
acknowlegement that there is a problem with the project
plan. At all intervening levels, the management response
was to hide the problem.
In two of these cases, the response from upper management was
to alter the plan in an unworkable 'Silver Bullet' fashion, changing
the back end database at the 11th hour, or committing to
a porting the code to a new language at the 11th hour, again
without consultation with developers *.
>
> Specifically, it would be the fault of the project manager.
Ehhh, not entirely. Again, on each of the last projects, the
word from the highest levels of management was that the
date -must- and -shall- be met, even though it was untenable
from the start. Certainly, the PM failed to take actions he
should have, but he was also ordered not to take those
actions, and micromanaged to take inadvisable actions.
-------------------------------
* In the one case, we spent w s in meetings and generating
documentation on what was involved in porting from Oracle
to DB2, driven by a desire to use a single feature of DB2.
After ws of work and finally getting meetings with the DB2
admins, it turns out the feature can't be used anyway. The
way the servers are set up, the feature isn't available, wouldn't
work as expected anyway, and there isn't a way to enable it
without taking a chance of breaking all the other DB2 apps.
The language change was to avoid a 'limitation' in a particular
interface to a certain server product, that management wanted
to avoid
....a product which was removed and replaced anyway
with a new version
....which caused the same 'limitation' to appear regardless of
which interface you used, so the language change was irrelevant
....and which I created a simple workaround in four hours,
which I suggested before the language change.
....which would have saved use at least 6 ws or work
porting the code in the first place.
| |
| Ron Ruble 2004-06-30, 3:58 pm |
|
"Ron Ruble" <raffles2@att.net> wrote in message
news:2hBEc.165999$Gx4.114745@bgtnsc04-news.ops.worldnet.att.net...
<snip>
I thought of a few additional points after posting the earlier
message.
Failing because management actively prevented success
in the ways I mentioned earlier doesn't relieve developers
from responsibility. But it does mean they need to change
the typical division of responsibilities.
In a sick organization, where the project is -not- going
to be a success due to unrealistic management decisions,
developers need to be more open, honest, and candid,
and increase visibility. That's one of the things I find
attractive about XP. I have no problem with a lot of
the overhead in Big Up Front Planning.
But having been on a lot of projects that suffered from
lack of feedback and lack of honest metrics, a system
that uses simpler reporting and tracking, which is more
objective and harder to fudge, and which makes the
progress (or lack of it) more visible is very appealing.
Scott, you're right about your sense that everyone
on the team has to share in the ownership of failures
and successes. But when management is overriding
the judgment of the professionals or altering the
metrics, developers need to change typical way they
respond from a success perspective to a failure
perspective.
I'm still working on this in my own mind.
| |
| Ronald E Jeffries 2004-06-30, 3:58 pm |
| On Wed, 30 Jun 2004 06:03:40 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:2874e0h6q3pbbupfjekdbgjakct4ejdhh8@
4ax.com...
>OK, they're not role models, they're just your consistently applied
>standard for comparison.......
They are the kinds of projects that I consistently encounter when I'm
brought in to help people improve their software development. I don't
recommend behaving that way. I do observe that many many organizations
/do/ behave that way.
>
>You're too funny...if you just try a little harder you could be
>pinning the blame on 'society as a whole', or the TriLateral Commission,
>or a vast Luddite conspiracy.
I see that the desire for rational discussion has left you. Perhaps
it'll come back. I'm just pointing out, apparently not clearly enough,
that management should not, rarely if ever does, and perhaps never
does, delegate /all/ responsibility and /all/ authority to the team
and then walk away.
Management owns the responsibility to know whether the team is
performing, and to change things if they're not. That responsibility
ought not be delegated in my opinion.
>
>
>The top of the project is the PM.
Is the PM getting paid? Is the project important? Is it perhaps life-
or money-threatening? If so, the execs of the organization are in fact
legally responsible for what happens. Firing the PM won't get them off
the hook.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-06-30, 3:58 pm |
| On Wed, 30 Jun 2004 11:20:26 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>Ron, you and Robert have painted a very compelling picture:
>
>We're entitled to swagger a little as providers of real,
>measurable business value.
I don't know about swagger, but I hope that everyone who does good
work gets real pleasure from it.
>We share in the credit when the project is successful.
Certainly.
>We don't have to take on the same risks as our
>business sponsor, or even the same risks as our
>project teammates.
That is formally and legally, as well as morally correct. Each of us
takes on different risks from anyone else. I risk my contract, you
risk your job, the guy who tests the plane we write the control system
for risks his life.
And the guys who put up the money risk that, which can be lots. That's
why when we all succeed, they get lots of money and we get less.
>We owe no more quantifiable performance committment
>than "We'll do our best."
I have never said that. Nor is it an even somewhat reasonable
paraphrase of what I have said.
>And the best part is, wait for it.....
>if it all goes to hell, it's never our fault, there's
>always someone else to blame.
I'm not into blame. I'm pointing out that the final decision point for
the project is not in the programmer, nor is it in the PM, it is in
the hands of whoever really owns the project. And if the project goes
in the weeds, that individual owns the responsibility to get it out of
the weeds or otherwise deal with the situation.
>It's just too beautiful.
>
>Then I wake up.
>
>I remember that real rewards come with real risks.
Yes. And people who work for wages get different rewards in return for
taking different risks.
>I remember that putting my ass out on the line with
>my business sponsor will earn more trust than the
>bland assurance that 'I'll do my best.'
I do not recommend bland assurances of any kind. Nor, last time I
spoke with him, does Bob Martin. We recommend hard measures of real
team performance, making progress public for all. We also believe that
project plans (consisting of assigned budget, scope, and time) are
generally, if not always, ill founded. We also believe that not every
such project is capable of being done as contemplated, and that wise
project owners will recognize that their responsibility is to steer
the project, not just to imagine the outcome and send people off.
(Yet, all too often, that is what we see people doing.)
>I remember that being part of a team comes with
>a set of responsibilities; among them the responsibility
>to actively communicate instead of waiting for someone
>to read my mind.
Unless I am very sorely mistaken, and I am not, the XP values are
Simplicity, Communication, Feedback, and Courage. The practices of XP
provide the feedback we need to know where we are. The communication
value requires us to actively communicate, and the courage value is
there to help us do so.
Mind-reading must be part of some other method. It is not part of
Extreme Programming, nor is it part of anything that Bob and I
recommend. If we could read minds, we would be in entirely different
lines of work.
>
>Oddly, sometimes I remember Sir Ranulph Fiennes;
>deathly afraid of heights, so the only way he could
>parachute in the SAS was to
>close his eyes when he jumped from the planes.
Please open your eyes when next you jump into this group. You are
raising ideas which do not reflect the meat of XP, and which are not
even particularly good straw men.
Thanks,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Donald Roby 2004-07-01, 3:56 am |
| On Wed, 30 Jun 2004 16:01:51 +0000, Ron Ruble wrote:
> "Ron Ruble" <raffles2@att.net> wrote in message
> news:2hBEc.165999$Gx4.114745@bgtnsc04-news.ops.worldnet.att.net...
> <snip>
>
> I thought of a few additional points after posting the earlier message.
>
> Failing because management actively prevented success in the ways I
> mentioned earlier doesn't relieve developers from responsibility. But it
> does mean they need to change the typical division of responsibilities.
>
> In a sick organization, where the project is -not- going to be a success
> due to unrealistic management decisions, developers need to be more
> open, honest, and candid, and increase visibility. That's one of the
> things I find attractive about XP. I have no problem with a lot of the
> overhead in Big Up Front Planning.
>
Honesty in an atmosphere of dishonesty also has its risks.
Usually the most effective form of honesty in this situation is the exit
interview.
| |
| Ron Ruble 2004-07-01, 3:58 pm |
|
"Donald Roby" <droby@acm.org> wrote in message
news:pan.2004.07.01.02.00.27.566282@acm.org...
> On Wed, 30 Jun 2004 16:01:51 +0000, Ron Ruble wrote:
<snip>
> Honesty in an atmosphere of dishonesty also has its risks.
Yes. But more and more, I'm becoming convinced that honesty
and candor, tempered with kindness, is even more necessary in
an atmosphere of dishonesty.
| |
| Robert C. Martin 2004-07-01, 3:58 pm |
| On Tue, 29 Jun 2004 13:16:12 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:nv13e0108b04t8bvil4l4j74nai36oh0fi@
4ax.com...
>
>Actually, she (the lawyer on my last two projects) does. She commits
>to winning the case; and as a result; selects a strategy and supporting
>tactics commensurate with winning the case, and does the preparation
>required to implement. She acts 'as if' she will win the case. That's not
>the same thing as guaranteeing an outcome, but it does provide a
>basis upon which to proceed. The outcome can still be bad, not every
>thing is under our control, but taking purposeful action requires that
>you believe in ultimate success.
In other words, you'd be a fool to depend on her commitments. Indeed,
they aren't commitments so much as they are intentions, towards which
she will make her best effort.
>
>Very few meaningful undertakings come with guarantees. I fail to see
>why software developers should be immune to the same risks that
>everyone else involved is subject to.
They aren't immune. Nobody is saying that. But, like your lawyer,
all they can really do is state their intention, and give their best
efforts.
However, *they* have to believe in that intention. All too often a
statement of intension is coerced from them. Such a statement is
worse than worthless.
>My point was, if folding their arms and demurring on results and/or dates
>is *all* they're doing, then they are refusing to help themselves, and
>refusing to help their teammates.
Granted. They'd better be doing more than that. They can't simply
stonewall and say "it'll be done when it's done."
>If they won't contribute alternative
>strategies, rationales, data, experience to back up their ambivalence,
>then they are refusing to help themselves and the team.
Agreed.
>
>I don't know what 'management by commitment' is. I only know that
>commitment is a required component for a team.
Management by commitments is when the manager extracts a commitments
from the team and then believes his job is done. If they fail,
they've broken their commitments.
>
>They already know how to deal with risk and amibguity.
Some do. Many don't.
>Someone who says
>"I'm not going to commit to achieving that result, I don't agree with it,
>I don't agree with how you're going about it, I'm not going to offer any
>reasons, or alternatives. I'm not going to expose myself to the same risks
>as everyone else. I don't have to tell you my strategy for doing this work,
>or estimate its completion. I'm just going to 'do my best.'", does not
>represent ambiguity. They represent a kind of passive/aggressive
>instransigence.
>And you're right, that is the manager's problem. I can say from experience,
>though that there's no guarantee that they'll like the manager's solution.
But I'd agree with it.
>This is untrue, and shows a lack of understanding of the methods and
>purposes of project management. Granted, it's consistent with Agile
>rhetoric, and it helps you make your point. It just isn't an accurate
>reflection of 'serious' practice.
Rhetoric, Schmetoric. I just defined one aspect of non-agility. If
you attempt to manage to a plan, (i.e. force the plan to be true) then
you are non-agile.
>
>Which doesn't justify your comparison of a bad implementation of
>one methodology against the serious implementation of another.
Have I done that?
>It's no surprise that you came to the conclusion you did. I'd have
>more respect for your analysis if you did a straight up comparison of
>serious practice of both methodologies.
Which two are we talking about?
>Imagine the argument I could make comparing the serious practice
>of 'classical' project management to the bad or even negligent practice
>of an Agile Methodology. I can hear the protests now, and they'd
>be right. To be intellectually honest, you need to take both methodologies
>seriously. Not better than what they are, but not worse than they are,
>either.
Have I said that classical project management is bad? Have I said
that classical project management is always non-agile? I don't think
so.
>Untrue on its face.
True by definition.
>I'm not sure I follow this. My mental analogy is that the GPS, speedometer
>and
>odometer of a car provide extremely important information, but they are not
>the raison d'etre of the car.
An agile method is a project management tool. It's reason for
existence it to facilitate management of the project.
-----
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
| |
| Ron Ruble 2004-07-01, 3:58 pm |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:g8i8e0lkuhu0ubhtvkp5jirenuql6h6rcd@
4ax.com...
> On Tue, 29 Jun 2004 13:16:12 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
<snip>
>
> They aren't immune. Nobody is saying that. But, like your lawyer,
> all they can really do is state their intention, and give their best
> efforts.
>
> However, *they* have to believe in that intention. All too often a
> statement of intension is coerced from them. Such a statement is
> worse than worthless.
True. On a project a few years ago, management decided
on a completely unworkable schedule. In a meeting with
the development staff where each of us was asked to select
what we could -commit- to, and when it could be delivered,
there was a huge amount of pressure.
Of 12 developers, I was the only one who met my commitment.
I was also the one who pushed back hardest in terms of getting
commitments from management to clarify 'soft' requirements
before areeing to commit.
10 of twelve were late by at least 600%, largely because they
caved in to the pressure to 'take one for the team'.
No, it is true -of a large number of organizations-. I agree that
it is not true of non-agile methods, but it -is- typical of a large
percentage of organizations ostensibly using non-agile methods.
[color=darkred]
>
> True by definition.
There may be a difference of experience here. Robert, I
have also experienced that a large number of organizations
using non-agile methods fail to track -meaningful- metrics,
and that a large percentage of courses intended to teach
non-agile disciplines -do not- teach the need to track
metrics, or revise project plans.
Scott, based on feedback I've heard, I would suggest
that this omission is fairly widespread. I agree that it
is an omission, one of many in the training of developers
and project managers, but I feel it -is- typical.
| |
| Vladimir Levin 2004-07-01, 8:57 pm |
| "Scott Kinney" <sakinney@ix.netcom.com> wrote in message news:<_LidnViA769APnzd4p2dnA@comcast.com>...
> Actually, she (the lawyer on my last two projects) does. She commits
> to winning the case; and as a result; selects a strategy and supporting
> tactics commensurate with winning the case, and does the preparation
> required to implement. She acts 'as if' she will win the case. That's not
> the same thing as guaranteeing an outcome, but it does provide a
> basis upon which to proceed. The outcome can still be bad, not every
> thing is under our control, but taking purposeful action requires that
> you believe in ultimate success.
I agree with RCM's comments, and further, it is interesting to note
that in most cases lawyers do not waive their services for free if
they lose the case. It is known from the beginning that the case is
fundamentally risky and that you're paying for the lawyer's expertise,
not for winning this particular case. I don't think software needs to
be as risky as law, but it is risky. Clearly therefore it is necessary
to manage the development as it goes along rather than making a
commitment at the very beginning of the project and not budging from
there.
I don't think any serious user of XP thinks that XP is an excuse for
laziness. But what you know about your rate of progress before a
project starts can change quite dramatically as it goes on. Therefore
there has to be give and take. It all sounds pretty common-sensical to
me.
| |
|
|
| Frédéric Gédin 2004-07-02, 3:56 am |
| Ronald E Jeffries wrote:
> On Wed, 30 Jun 2004 08:09:29 +0200, Frédéric Gédin <badaddress@bad.fr>
> wrote:
>
>
> Very good question, as it challenges me to be more clear about what I
> think on this topic. Let's see whether I can. Hmmmm ...
>
> Generally speaking, I do believe that success is a team result, and
> that failure is not. That is the contradiction that you, Frédéric,
> observed, and in fact I embrace that contradiction.
>
> Let's go back to what I originally said:
>
>
> So I'm saying that except in the very rare case where the team is
> completely autonomous, the team "owner" has a kind of responsibility
> for failure that she does not have for success. She has the
> responsibility to track the team well enough to know when they're off
> track, and to do what is necessary to get them back on, or to stop the
> project, long before it fails.
>
> Does that make any kind of sense?
>
OK! If I rephrase, you say that the manager is responsible for detecting
risks of failure and processing them. So, if the project fails, this mans
that the manager was not able to predict the failure and to carry out
corrective actions. I agree for the "risk detection" part. I do not agree
regarding the corrective actions because the whole team responsibility will
come back here.
Regards
Frederic
| |
| Ronald E Jeffries 2004-07-02, 8:56 am |
| On Fri, 02 Jul 2004 03:45:04 +0200, Frédéric Gédin <badaddress@bad.fr>
wrote:
>OK! If I rephrase, you say that the manager is responsible for detecting
>risks of failure and processing them. So, if the project fails, this mans
>that the manager was not able to predict the failure and to carry out
>corrective actions. I agree for the "risk detection" part. I do not agree
>regarding the corrective actions because the whole team responsibility will
>come back here.
I'm not saying that the team has no responsibility to do things. I'm
saying that those in positions of power, such as managers, cannot
delegate away all their responsibility.
Suppose that the manager does not detect that the project is in
trouble. Then the manager is doing a poor job of paying attention or
of requiring the team to emit management-useful measurable
information.
Suppose that the manager does detect trouble, and does nothing. Bad
management. When there's trouble in something one manages, one takes
action.
Suppose that the manager detects trouble and just tells the team "work
harder and work smarter". Bad manager. [I believe that] teams always
work about as hard and as smart as they can, and that more specific
management action is almost certainly needed.
The manager is higher up the food chain of authority (and usually
money). As such, she bears more responsibility. And, very likely,
there are actions which only she can take, such as adding people,
changing out people, changing the objectives, cancelling the project,
and so on.
Now in general, I expect no objections to any of the above -- though I
would welcome them in the spirit of trying to discover what we agree
upon and to discover new ideas.
Scott seems to think that Bob and I are saying that the team bears no
responsibility. That's not the case. In fact, XP and the agile methods
in general are about the team having /more/ responsibility, not less.
We are just talking about a particularly pernicious management
behavior, which occurs rather often in our experience. Too often,
managers do not require their teams to produce useful measurements of
progress, and when they finally find out that there is trouble, take
no productive action, instead merely pushing on, and ultimately
blaming the team.
I expect that we'll also agree that the behavior described in the
paragraph just above is not good management behavior. (Again, I'd
welcome arguments to the contrary.)
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Scott Kinney 2004-07-02, 8:56 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:46cae0hrnhhjvrf22sdfci2kpbvm6cg2vs@
4ax.com...
> On Fri, 02 Jul 2004 03:45:04 +0200, Frédéric Gédin <badaddress@bad.fr>
> wrote:
>
agree[color=darkred]
will[color=darkred]
>
> I'm not saying that the team has no responsibility to do things. I'm
> saying that those in positions of power, such as managers, cannot
> delegate away all their responsibility.
>
> Suppose that the manager does not detect that the project is in
> trouble. Then the manager is doing a poor job of paying attention or
> of requiring the team to emit management-useful measurable
> information.
>
> Suppose that the manager does detect trouble, and does nothing. Bad
> management. When there's trouble in something one manages, one takes
> action.
>
> Suppose that the manager detects trouble and just tells the team "work
> harder and work smarter". Bad manager. [I believe that] teams always
> work about as hard and as smart as they can, and that more specific
> management action is almost certainly needed.
>
> The manager is higher up the food chain of authority (and usually
> money). As such, she bears more responsibility. And, very likely,
> there are actions which only she can take, such as adding people,
> changing out people, changing the objectives, cancelling the project,
> and so on.
>
> Now in general, I expect no objections to any of the above -- though I
> would welcome them in the spirit of trying to discover what we agree
> upon and to discover new ideas.
>
> Scott seems to think that Bob and I are saying that the team bears no
> responsibility. That's not the case. In fact, XP and the agile methods
> in general are about the team having /more/ responsibility, not less.
>
Well, no. Scott thinks that you (and not Bob)have spent several paragraphs
detailing how and why the fault, blame and responsibility would lay with
the manager without, until now, mentioning that the team members might
also shoulder some responsibility.
Now, this manager you're writing about, is it the project manager, the
project sponsor, some other manager? And do you consider that the
project manager is part of the project team?
| |
| Scott Kinney 2004-07-02, 8:56 pm |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:g8i8e0lkuhu0ubhtvkp5jirenuql6h6rcd@
4ax.com...
> On Tue, 29 Jun 2004 13:16:12 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
This[color=darkred]
>
> In other words, you'd be a fool to depend on her commitments. Indeed,
> they aren't commitments so much as they are intentions, towards which
> she will make her best effort.
I think we're using two different meanings of the word
'commitment', and that's leading to some of this disagreement.
I'm using commitment in its meaning 'steadfast fixity of purpose' or
'binding oneself to a course of action.' I'm not using it in the sense
of a written or oral pledge. What does it mean to you?
[color=darkred]
>
>
> Rhetoric, Schmetoric. I just defined one aspect of non-agility. If
> you attempt to manage to a plan, (i.e. force the plan to be true) then
> you are non-agile.
>
What does 'force the plan to be true' mean? It doesn't feel the same to me
as the phrase 'manage to a plan', so you must have some other meaning.
For me, 'manage to a plan' is a lot like 'navigate using a map'.
| |
| Robert C. Martin 2004-07-02, 8:56 pm |
| On Fri, 2 Jul 2004 11:50:47 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>I think we're using two different meanings of the word
>'commitment', and that's leading to some of this disagreement.
>I'm using commitment in its meaning 'steadfast fixity of purpose' or
>'binding oneself to a course of action.' I'm not using it in the sense
>of a written or oral pledge. What does it mean to you?
If people are punished (overtly or covertly) for missing their
commitments, then they were taken as pledges irrespective of what
anyone said. Indeed, the very statement "to miss the commitments" is
indicative of a pledge. There is a very big different between:
"Committing to a course of action" and "Committing to an end result."
Many managers assume the latter when the former was given.
>
>What does 'force the plan to be true' mean? It doesn't feel the same to me
>as the phrase 'manage to a plan', so you must have some other meaning.
>For me, 'manage to a plan' is a lot like 'navigate using a map'.
People sometimes try to force a plan to be true by:
1. Creating it up front and then not changing it.
2. Pasting it on the wall and comparing all progress to it.
3. Putting pressure on the team to make up for all deviations.
In such situations re-planning is considered failure.
In an agile environment re-planning is considered necessary, and is
done very frequently.
-----
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
| |
| Scott Kinney 2004-07-02, 8:56 pm |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:2nlbe0pri793v49dv0eduku999ad7u5n23@
4ax.com...
> On Fri, 2 Jul 2004 11:50:47 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
me[color=darkred]
>
> People sometimes try to force a plan to be true by:
>
> 1. Creating it up front and then not changing it.
Bad practice, and one that doesn't fool anyone.
> 2. Pasting it on the wall and comparing all progress to it.
And this would be different from the charts agile groups put on their
walls because,......?
> 3. Putting pressure on the team to make up for all deviations.
Which is sort of like #1 anyway.
>
> In such situations re-planning is considered failure.
>
Well, not where I've worked. Whatever.
> In an agile environment re-planning is considered necessary, and is
> done very frequently.
>
And in some 'classical' environments as well.
| |
| Ronald E Jeffries 2004-07-03, 4:08 am |
| On Fri, 2 Jul 2004 11:38:45 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>Well, no. Scott thinks that you (and not Bob)have spent several paragraphs
>detailing how and why the fault, blame and responsibility would lay with
>the manager without, until now, mentioning that the team members might
>also shoulder some responsibility.
True. I've also left out lots of other important notions. One
productive way of learning my position on any of those which might be
important to you would be to ask.
>
>Now, this manager you're writing about, is it the project manager, the
>project sponsor, some other manager?
I'm writing about any and all managers who have authority and
responsibility over the project. As I believe I may have said in an
earlier posting, I do not believe that responsibility ends with the
project manager. In particular, the real company executives always
bear real responsibility for what those in their employ do, or do not
do.
>And do you consider that the
>project manager is part of the project team?
It would depend on the particular team, I'd think. In general, agile
methods do not, so far as I know, define a role named "project
manager", though there are analogous roles within the methods, and of
course real organizations might have people in those roles.
I would say that in most of the teams I have observed, the project
manager was emphatically not a member of the team, but was instead
configured as an independent monitoring function, adjacent to the
team, not in or of it. I'm not suggesting that that's the right thing
to do -- I believe that it is not.
What is your position on whether the PM is, and should be, part of the
team?
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-07-03, 4:08 am |
| On Fri, 2 Jul 2004 19:00:30 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>And this would be different from the charts agile groups put on their
>walls because,......?
Agile projects post /results/ on the wall. They might work to improve
results, but they should not be working to make the results hit some
magic pre-defined marker.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Frédéric Gédin 2004-07-03, 4:08 am |
| Ronald E Jeffries wrote:
> On Fri, 02 Jul 2004 03:45:04 +0200, Frédéric Gédin <badaddress@bad.fr>
> wrote:
>
>
> I'm not saying that the team has no responsibility to do things. I'm
> saying that those in positions of power, such as managers, cannot
> delegate away all their responsibility.
I agree on that.
>
> Suppose that the manager does not detect that the project is in
> trouble. Then the manager is doing a poor job of paying attention or
> of requiring the team to emit management-useful measurable
> information.
I agree on that.
>
> Suppose that the manager does detect trouble, and does nothing. Bad
> management. When there's trouble in something one manages, one takes
> action.
I agree on that.
>
> Suppose that the manager detects trouble and just tells the team "work
> harder and work smarter". Bad manager. [I believe that] teams always
> work about as hard and as smart as they can, and that more specific
> management action is almost certainly needed.
I agree on that.
>
> The manager is higher up the food chain of authority (and usually
> money). As such, she bears more responsibility. And, very likely,
> there are actions which only she can take, such as adding people,
> changing out people, changing the objectives, cancelling the project,
> and so on.
Here I start not to fully agree. Unfortunately, managers are not always
highly empowered people who can decide to change team members, change
objectives and so on. What is often required from a manager is to take the
responsibility of a team and to drive it to the objective. In general,
there are few opportunities to change the people (and I think it's good) or
the objective.
For me the role of a manager is to take the best of the whole team, to
orient it towards the objective and to verify that the direction and the
pace towards the objective are OK. Maybe can you say that, if a manager
cannot always drive a given team to a given objective, he/she's not a good
manager. In this case, I really don't know such good managers.
My understanding is that you provide too simple examples of situations where
the manager's responsibility is obvious. From my experience,you may have
other situations where tha manager doesn't have any control.
For example, what do you think of the situation where a technical issue
raises. The manager processes the issue and discovers that there is no
solution taking into account the given team and the given budget. The
project is stopped and considered as failed. I don't think this is
manager's responsibility.
Ok! Maybe can you say that it is the manager's manager's responsibility and
climb the chain until you reach God. But I am not sure it will fit either.
An other situation is the case where some members of the team cheat on the
manager (I am not sure that "cheat" is the right word as this may be done
unvolontarily) and provide results which can be seen as real or good today
but false later in the project. What I mean here is that everybody can make
a mistake, the manager, the developers and even the whole team together. In
such a case, the whole team is responsible for the mistake they have made.
>
> Now in general, I expect no objections to any of the above -- though I
> would welcome them in the spirit of trying to discover what we agree
> upon and to discover new ideas.
>
> Scott seems to think that Bob and I are saying that the team bears no
> responsibility. That's not the case. In fact, XP and the agile methods
> in general are about the team having /more/ responsibility, not less.
So if they have responsibility, this responsibility is shared both in case
of success and in case of failure. I you say to your team: I share the
success responsibility but I keep the failure responsibility you may have
some troubles with your team. How can they consider themselves as
responsible if they are sure they will never fail?
>
> We are just talking about a particularly pernicious management
> behavior, which occurs rather often in our experience. Too often,
> managers do not require their teams to produce useful measurements of
> progress, and when they finally find out that there is trouble, take
> no productive action, instead merely pushing on, and ultimately
> blaming the team.
As said before, on this I fully agree.
>
> I expect that we'll also agree that the behavior described in the
> paragraph just above is not good management behavior. (Again, I'd
> welcome arguments to the contrary.)
>
Ditto.
Regards
Frederic
| |
| Ronald E Jeffries 2004-07-03, 8:56 am |
| On Sat, 03 Jul 2004 10:04:52 +0200, Frédéric Gédin <badaddress@bad.fr>
wrote:
>My understanding is that you provide too simple examples of situations where
>the manager's responsibility is obvious. From my experience,you may have
>other situations where tha manager doesn't have any control.
The key aspects of management, from Peter Drucker, are "Planning,
Organizing, Staffing, Directing, and Controlling". Setting up a
manager to be "responsible" without control is not setting up a
manager at all, and it is just as wrong as setting up a team to be
responsible without control.
>
>For example, what do you think of the situation where a technical issue
>raises. The manager processes the issue and discovers that there is no
>solution taking into account the given team and the given budget. The
>project is stopped and considered as failed. I don't think this is
>manager's responsibility.
As I read the above, it seems to mix the notion of "blame" intothe
term "responsible". Is that your intention?
Whoever decided to stop the project is in fact responsible for
stopping the project. They could have decided to push on, to add time,
money, other resources.
>Ok! Maybe can you say that it is the manager's manager's responsibility and
>climb the chain until you reach God. But I am not sure it will fit either.
Someone in the organization owns that decision: they are /responsible/
for making that decision.
>
>An other situation is the case where some members of the team cheat on the
>manager (I am not sure that "cheat" is the right word as this may be done
>unvolontarily) and provide results which can be seen as real or good today
>but false later in the project. What I mean here is that everybody can make
>a mistake, the manager, the developers and even the whole team together. In
>such a case, the whole team is responsible for the mistake they have made.
Here again, I am reading the notion of who is to /blame/, where I'm
talking about the responsibility to make a decision, not the notion of
blame.
One of the problems with conventional project management as often
applied to software development is that the information asked for or
provided does not provide good information about the actual progress
of the project. In particular, waterfall-style projects sometimes tend
to track how far along the requirements are, then how far along the
design is, then how far along the code is, then how far along the
testing is.
The problem with this kind of approach is that there is critical
information about the requirements that only comes along when we do
the testing. There is critical information about the design that only
comes along when we do the coding. The people doing the requirements
say that they are done and the project manager duly reports this fact.
Ws or months later, testing discovers that the system doesn't do
what it should. The truth may be that the requirements were wrong, or
wrongly described, and therefore the requirements were in fact not
done. It's too late to do anything about this, and sometimes the PM
doesn't go back and say "what I told you six months ago about
requirements wasn't right". The project just "suddenly" goes off
schedule because we have to "fix this bug".
Now often, by this stage someone probably gets to take the /blame/,
because the mistake is far in the past. There will be finger-pointing
and dissection to decide whether the requirement was really right,
whether the writing was really clear, whether the designers really
understood, whether the programmers really screwed up. It doesn't
matter. The truth of the situation is that the project management
process did not tell the truth, because it did not /have/ the truth.
Agile software processes are different from the above: they are
incremental. Done right, they deliver running tested features, agreed
by the customer to be what is wanted, from the beginning of the
project right on until the end. Because what they deliver is concrete,
agile processes are easier to manage, easier to predict, easier to
control. A short article relating to this -- from the viewpoint of
using this information to bring about agility -- is at
http://www.xprogramming.com/xpmag/jatRtsMetric.htm .
In all too many projects, responsibility turns into blame. I think
that's what Bob was talking about, and I'm sure it's what I have been
talking about. My interest is in success, not failure, good results,
not allocating the blame.
There are many ways to bring about good results, and if your teams are
getting good results now, then I'd advise caution in changing things
around. If, on the other hand, there seem to be too many failures, if
you seem to be caught up in too many determinations of the wrong kind
of responsibility, I'd suggest that a look at what agile methods
really are might be of value.
Agile methods do at least two things that are important in this
context. First of all, they focus on continuous delivery of measurable
progress -- software, not paperwork. Second, they bring
responsibility, in the positive sense, to the people who do the work,
while providing the ability to measure and steer to the people who
manage the work.
Teams all over are finding agile methods to be a good way to do
things. There are many reasons why, and many things that teams have to
do to accomplish those results. At the base of it all, in my opinion,
is incremental production of running tested features.
Your thoughts?
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Scott Kinney 2004-07-03, 8:56 am |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:7p5ce05u6pm8oirlld8bcsmja4mdcvts23@
4ax.com...
> On Fri, 2 Jul 2004 19:00:30 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Agile projects post /results/ on the wall. They might work to improve
> results, but they should not be working to make the results hit some
> magic pre-defined marker.
>
And presumably they have no interest in ongoing review or
comparisons of their estimates to actual results. (?)
| |
| Ron Ruble 2004-07-03, 3:56 pm |
|
"Scott Kinney" <sakinney@ix.netcom.com> wrote in message
news:g9ydnTKbl96NdHjd4p2dnA@comcast.com...
>
> "Robert C. Martin" <unclebob@objectmentor.com> wrote in message
> news:2nlbe0pri793v49dv0eduku999ad7u5n23@
4ax.com...
> me
> Bad practice, and one that doesn't fool anyone.
"That doesn't fool anyone" -in a healthy organization. In
an organization where 'thou darest not tell the Emperor
he has no clothes', it's extremely common.
> And this would be different from the charts agile groups put on their
> walls because,......?
Only in the sense that charts agile groups put out are based
on the idea that reality is definitive, and deviations indicate
problems with the plan. In fact the charts are designed to use
simple, unambiguous metrics to help find plan defects.
In the case Robert mentioned, like the trial in "The Hitchhiker's
Guide To The Galaxy', they are used to judge -reality- to
be in contempt of court for finding defects in the plan, and
to jail the heretics who pointed out the flaws.
> Well, not where I've worked. Whatever.
Sigh. Sounds nice. wish I'd been there.
| |
| Isaac Gouy 2004-07-03, 3:56 pm |
| Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<otuce0hur3p959t6ao2sjecd0mt3ohi75j@4ax.com>...
-snip-
> Agile software processes are different from the above: they are
> incremental. Done right, they deliver ...
-snip-
So this comparison is between approach A *done wrong* and approach B *done right*?
Shouldn't we compare
A *done right* with B *done right*
and
A *done wrong* with B *done wrong*
| |
| Scott Kinney 2004-07-03, 3:56 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:9c5ce0l9ggaogkoe79a6hjqgb3522pb796@
4ax.com...
> On Fri, 2 Jul 2004 11:38:45 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> I'm writing about any and all managers who have authority and
> responsibility over the project. As I believe I may have said in an
> earlier posting, I do not believe that responsibility ends with the
> project manager. In particular, the real company executives always
> bear real responsibility for what those in their employ do, or do not
> do.
>
So, it's too broad a role to be of any real use in the discussion.
>
> It would depend on the particular team, I'd think. In general, agile
> methods do not, so far as I know, define a role named "project
> manager",though there are analogous roles within the methods, and of
> course real organizations might have people in those roles.
>
> I would say that in most of the teams I have observed, the project
> manager was emphatically not a member of the team, but was instead
> configured as an independent monitoring function, adjacent to the
> team, not in or of it. I'm not suggesting that that's the right thing
> to do -- I believe that it is not.
>
> What is your position on whether the PM is, and should be, part of the
> team?
>
In my experience (and it's my position as well), the project manager
is a part of the team. To be specific, the project team is normally
costituted with a business customer, an architecture rep, an operations rep,
and the applications. Depending on the scope and nature of the project,
there may well be customers from multiple divisions or lines of business,
multiple applications and operations areas. There may also be legal,
finance,
training and corporate communications.
| |
| Scott Kinney 2004-07-03, 3:56 pm |
|
"Ron Ruble" <raffles2@att.net> wrote in message
news:CfyFc.183661$Gx4.64790@bgtnsc04-news.ops.worldnet.att.net...
>
> "Scott Kinney" <sakinney@ix.netcom.com> wrote in message
> news:g9ydnTKbl96NdHjd4p2dnA@comcast.com...
to[color=darkred]
meaning.[color=darkred]
>
> "That doesn't fool anyone" -in a healthy organization. In
> an organization where 'thou darest not tell the Emperor
> he has no clothes', it's extremely common.
>
For such a fabrication to work at all, you have to have
remarkable consistency of fiction across applications,
across departments and across projects. You also have
to get your customers to play along.Failing that,
you have to hope that none of the managers talk to
each other.
To think it will work for very long is pure fantasy.
In a recent interview Grady Booch said something
along the lines of "It's dangerous to underestimate the
intelligence of anyone smart enough to grow or run a
business large enough to require sophisticated systems."
>
> Only in the sense that charts agile groups put out are based
> on the idea that reality is definitive, and deviations indicate
> problems with the plan. In fact the charts are designed to use
> simple, unambiguous metrics to help find plan defects.
>
I understood the individual words here, but strung together,
they made absolutely no sense to me.
>
>
> Sigh. Sounds nice. wish I'd been there.
Hey every place has its own neuroses. My company's
are probably just different than yours.
At lunch the other day with a peer of mine at another
company, we were comparing notes on our respective
IT divisions. We found something in common; a tendency
to 'yes' everybody. Maybe not all that surprising.
The surprising part was, in both our cases, project
sponsors (and project managers and PMO oversight
people) would go to these groups and plead with them
for some realistic review of their capacity. "Look, you've
got 8 major projects going, 3 major releases in the next month,
none of them tested successfully yet, and you've agreed to
take on a 9th project. Tell us what you can actually handle."
They'll diffidently say, "We can handle it."
We'd all say, "Seriously, we will bring in temps for the scut
work, shelve some low-priority projects, shift some other
resources, but you've gotta be honest with us about
how much, how many and how long...."
"We can handle it"
And of course, they can't......
| |
| Scott Kinney 2004-07-03, 3:56 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0407030841.683635c1@posting.google.com...
> Ronald E Jeffries <ronjeffries@acm.org> wrote in message
news:<otuce0hur3p959t6ao2sjecd0mt3ohi75j@4ax.com>...
>
> -snip-
> -snip-
>
> So this comparison is between approach A *done wrong* and approach B *done
right*?
>
> Shouldn't we compare
> A *done right* with B *done right*
> and
> A *done wrong* with B *done wrong*
Isaac, thanks. The US$5 is in the mail......
| |
| Ronald E Jeffries 2004-07-03, 8:55 pm |
| On Sat, 3 Jul 2004 14:46:22 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote
>So, it's too broad a role to be of any real use in the discussion.
On the contrary, for example, the fiscal responsibilities of
Sarbanes-Oxley, as I understand them, cannot be delegated away by the
company officers. Certainly they can and must require specific things
to be done, but if they are not done, the officers are themselves
legally responsible.
There might be other responsibilities, which, though delegated in
part, cannot be released by managers up the food chain.
It seems to me that one might will find value in discussing how
responsibilities work up and down the chain. Not that I'm terribly
interested either -- just pointing out that in fact it might be of use
after all.
>
[color=darkred]
>
>In my experience (and it's my position as well), the project manager
>is a part of the team. To be specific, the project team is normally
>costituted with a business customer, an architecture rep, an operations rep,
>and the applications.
I have never in my life encountered a project with those roles on the
team, so it may not be as normal as your experience suggests. (I note
that you didn't include "project manager" in that list, but I take it
that you meant to. And I'm not sure what you meant to say by "the
applications".)
>Depending on the scope and nature of the project,
>there may well be customers from multiple divisions or lines of business,
>multiple applications and operations areas. There may also be legal,
>finance,
>training and corporate communications.
I have seen all those folks /involved/ in projects, but in general it
has not been my experience that they are fully committed team members.
Our experience, though broad, has been quite different, it seems. One
could imagine that leading us to quite different conclusions.
Regards,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-07-03, 8:55 pm |
| On 3 Jul 2004 09:41:32 -0700, igouy@yahoo.com (Isaac Gouy) wrote:
>Ronald E Jeffries <ronjeffries@acm.org> wrote in message news:<otuce0hur3p959t6ao2sjecd0mt3ohi75j@4ax.com>...
>
>-snip-
>-snip-
>
>So this comparison is between approach A *done wrong* and approach B *done right*?
>
>Shouldn't we compare
> A *done right* with B *done right*
>and
> A *done wrong* with B *done wrong*
I don't follow your notion here. I'm not sure what you are asking me
to compare, but I'm trying to compare A done right with B done right.
Agile software processes -- done right -- deliver software
incrementally. Plan-driven projects do not. A paragraph deleted was
this:
[color=darkred]
The distinction I'm drawing is that waterfall style projects, even
done "right", if there is such a thing, lack key information which
agile projects have, because waterfall style projects focus,
especially in early stages, on document completion, while agile
projects focus on software completion.
In my model of the world, conventional project plans literally do not
have "the truth" of progress, because progress is not well measured by
estimates of requirements completion, design completion, and so on.
I welcome your thoughts on this notion.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-07-03, 8:55 pm |
| On Sat, 3 Jul 2004 07:32:29 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
> news:7p5ce05u6pm8oirlld8bcsmja4mdcvts23@
4ax.com...
>
>And presumably they have no interest in ongoing review or
>comparisons of their estimates to actual results. (?)
Of course they are interested. The difference I'm trying to draw is
that agile projects consider actual performance to be a measurement of
true velocity, and estimates to be just that, estimates.
Making estimates and actuals match is a plan-driven tactic. Measuring
true progress and using it to steer the project is the corresponding
agile tactic, and they are quite different in practice.
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Ronald E Jeffries 2004-07-03, 8:55 pm |
| On Sat, 3 Jul 2004 15:01:24 -0400, "Scott Kinney"
<sakinney@ix.netcom.com> wrote:
>At lunch the other day with a peer of mine at another
>company, we were comparing notes on our respective
>IT divisions. We found something in common; a tendency
>to 'yes' everybody. Maybe not all that surprising.
>
>The surprising part was, in both our cases, project
>sponsors (and project managers and PMO oversight
>people) would go to these groups and plead with them
>for some realistic review of their capacity. "Look, you've
>got 8 major projects going, 3 major releases in the next month,
>none of them tested successfully yet, and you've agreed to
>take on a 9th project. Tell us what you can actually handle."
>They'll diffidently say, "We can handle it."
>We'd all say, "Seriously, we will bring in temps for the scut
>work, shelve some low-priority projects, shift some other
>resources, but you've gotta be honest with us about
>how much, how many and how long...."
>"We can handle it"
>
>And of course, they can't......
It sounds like your world is more like mine than our earlier
discussions had indicated. What does a project manager in your world
do when those things are being said? Doesn't it mean that the projects
you manage will in fact not come in on time, and it will be your
responsibility?
What an agile team, or a project manager using agile methods might do
would be to show the graph of features done over time, and show that
that graph is not pointing at the dates "committed". See, for some
thoughts along those lines,
http://www.xprogramming.com/xpmag/jatRtsMetric.htm .
On a plan-driven project, unfortunately, that graph of features done
doesn't exist for most of the project (the requirements phase, design
phase), and isn't accurate for the coding phase because the testing is
insufficient to give confidence in the graph.
So what do you do to fulfil the responsibility to deliver on the
predicted date? Or is it someone else's fault when it doesn't happen?
(I am of a mind that it is the fault of whoever said it could be done,
but I could be wrong ...)
Thanks,
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
| |
| Scott Kinney 2004-07-03, 8:55 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:s98ee0hkjq4ef9drgnfrbavuqv05u7ja48@
4ax.com...
> On Sat, 3 Jul 2004 14:46:22 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
rep,[color=darkred]
>
> I have never in my life encountered a project with those roles on the
> team, so it may not be as normal as your experience suggests. (I note
> that you didn't include "project manager" in that list, but I take it
> that you meant to. And I'm not sure what you meant to say by "the
> applications".)
>
It seemed immodest, but yes, there is a project manager....
Our IT environment is pretty stove-piped; each major software
application has its own staff dedicated to its care and feeding.
>
> I have seen all those folks /involved/ in projects, but in general it
> has not been my experience that they are fully committed team members.
>
That's a shame. And as you said, it probably explains a lot about your
biases.
| |
| Scott Kinney 2004-07-03, 8:55 pm |
|
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:mf9ee0hig53f760td50v1f0m8c3hv47p4r@
4ax.com...
> On Sat, 3 Jul 2004 07:32:29 -0400, "Scott Kinney"
> <sakinney@ix.netcom.com> wrote:
>
>
> Of course they are interested. The difference I'm trying to draw is
> that agile projects consider actual performance to be a measurement of | | |