Thanks for the plug Tom :-)

Actually, this presentation is a now somewhat
out-of-date outline for my first book which will be
published next year. The draft manuscript is finished
(all 280 pages) but I still have some diagrams to add
before it goes out for peer review. The working title
is "Agile Management - [subtitle TBD]". I see this
book as highly complimentary to Mary and Tom's book.

The main gist of the book is that TOC (along with
Systems Thinking and Lean Production) can be used to
explain why Agile Methods (and Lean Methods) are
actually better.

Of the 7 sections in the book, there are 3 specific
sections on FDD, XP and Scrum which look at the
process elements of each method and discuss how each
element contributes to the 5 steps in TOC:-
identifying a capacity constrained resource(CCR);
exploiting that CCR; subordinating other decisions to
the decision to exploit a CCR; elevating a CCR;
identifying the newly uncovered CCR after the previous
one was eliminated.

I have deliberated stayed away from trying to compare
FDD against Scrum and XP but rather focused on the
positives of each method and their abilities to
exploit or eliminate CCRs.

In software there are 4 main constraints:- time;
scope; budget; people. Specific CCRs are things like
the UI Designer or the DBA or Architects, even the
8-hour day.

I'd be interested to hear from anyone who would like
to take a look at the manuscript and provide either
formal or informal review comments. I haven't yet
decided whether or not to put the full manuscript up
on the web. I'll have a copy with me at OOPSLA later
today.

Cheers

David
--
David J. Anderson
http://www.uidesign.net/
The Webzine for Interaction Designers

--- Tom Poppendieck <tom@...> wrote:
> Jeff Sutherland pointed out an interesting
> presentation by
> David Anderson at Agile Management: Why Agile
> Methods are
> Better for Business
>
<http://www.hipaaccelerator.com/oopsla2002/positions/AgileMa
> nagement.pps> .  David applies Goldratt’s theory of
> constraints to mapping out an agile approach to
> improving
> software process. (This is being used in an OOPSLA
> workshop
> this week).
>
> - Tom Poppendieck
>
>
>


__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Tom writes, Might the theory of project management be the theory of a learning project team?

Oh, if it were just that simple.  The PMI appears to be agnostic towards theory.  PMI offers "over 1000 of the  best books on project management" many in stark contradiction.  Perhaps we'll find what we're looking for among one or more of these books.  I'm not so arrogant to deny that likelihood.  I do think the Lean Construction Insititute and the Agile Alliance have only scratched the surface for creating a new theory.  Koskela and Howell have made a very important contribution by roundly criticizing current theory.  We have many more steps to take.  I suspect we'll need to look in some of the more unlikely areas for the stimulation to develop our theory.  Too much of what we all have been doing is just adding a twist on existing theory.  Goldratt's Theory of Constraints is a unique contribution.  It led directly to the development of The Last Planner System™.

I agree fully with K&H's final sentence, "Theory and practice have to be developed concurrently, similarly to other science-based fields, where theory is explicated, tested and refined in a continuous dialog between the scientific and practitioner communitites."

  Tom Poppendieck <tom@...> wrote:

The postings Hal refers to below are at http://weblog.halmacomber.com/ .  If you have an interest in agile project management, Hal’s writings and references are well worth investigating.

 

We tried to abstract lean away from material flow and transformation in chapter 2 by phrasing the principles of lean software development as:

 

1. Add nothing but value (eliminate waste)
2. Center on the people who add value.
3. Let customers pull value (delay commitment, deliver fast)
4. Optimize across organizations.

 

Eliminating waste requires the capability of people to learn from their effective interaction.  Doing things right the first time is about stopping the line to clarify when learning is required to get something right.  Centering on people who add value anticipates that people will learn and adjust their work to balance competing values (personal, project, future users/maintainers, workgroup, …).  Delaying commitment is about maximizing opportunity for learning. 

 

A common critical component is building trust among parties based on performance.  Project participants need to establish trust in their capacity to act quickly, their ability to identify and avoid waste, and their ability to recognize and resolve ambiguity.  This direction of thought is reminding me of Covey’s principle-centered leadership discussion.  Lean leadership…  tool 19.  An effective project seems to require a leader, not just a manager.  The leader will cope with change, set overall direction, align the people on the project team, and motivate people.  To succeed as a lean leader, however, requires more, it requires shaping the team into what Senge calls a learning organization skilled at systems thinking.  Might the theory of project management be the theory of a learning project team?

 

- Tom Poppendieck

Get a daily dose of the changes underway in project management at Reforming Project Management.  What's a weblog?  http://weblog.halmacomber.com

978-470-8994

I'm not sure I'm ready to write persuasively (or even lucidly) about this.  Here's a short commentary (for now).

If you've been following the series of postings in my weblog on The Underlying Theory of Project Management is Obsolete you'll see a distinct focus in the current theory of project management on production...of both the physical and the abstract.  We use terminology like transformation, flow, value-generation, value stream.  These all have to do with materiel (intentional choice of the military logistics term).  As noted by the practitioners of agile methods while materiel is important, what occurs around the materiel is more important.  Who programs is more important on a project than who operates a drill press in production.  On a project there is the opportunity for innovation up until the project is closed.  In production the design is fixed.  The declaration of roles and assignment of people to those roles matters.  Further the organization of roles to one another and the constructs for interaction also make a difference.  Varying approaches will yield varying levels of creativity.

While I could go on, let me offer the most significant two issues.  People learn.  People have moods (they are disposed positively or negatively towards the future).  I'll be doing much more writing about both these subjects.  I don't yet know what I think about them, so going on here is premature.   In summary, the nature of projects has everything to do with people.  That makes it different from current theory that puts the activity at the center.  We use language (metaphors) that obscures the centrality of people, so much so that even in Koskela's and Howell's well-articulalted attack on current theory the inattention to people is missed.  This is similar to the current brain-as-computer metaphor that is so prevalent today.  When someone says "Give me a time to process that" or "I don''t have the cycles for that" they are speaking metaphorically.  And that keeps us from having serious conversations about the biological nature of knoweldge.

Now that I've read what I wrote I am sure that I'm not ready to argue persuasively.  I only hope it was coherent.

Hal
http://weblog.halmacomber.com

  Mary Poppendieck <mary@...> wrote:

Hal,

 

I am trying to figure out exactly what you mean by the machine metaphor.  I do not totally buy the concept that a project is simply a special case of production, but I am convinced that if you abstract the principles of production back far enough, they apply to projects also.  The level of abstraction I am looking at is the one which says that the reason lean works so well is that it focuses on allowing irreversible decisions to be delayed until as late as possible.  I think this “last responsible moment” is fundamental in a high speed environment.  If you look at set-based design in Toyota, it is based on this very same concept, allowing irreversible decisions to be delayed until as late as possible.  In economics, any endeavor which is subject to change and uncertainty develops a way to delay irreversible decisions.  That is what financial options are all about.  We all understand why farmers buy options to cover their bets.

 

The problem with delaying irreversible decisions is that there is no sense in delaying decisions unless once made, the decision can be rapidly and effectively implemented.  The speed with which a decision must be implemented changes the way in which people discover what work they should do next.  There is no longer time for someone to tell people what to do, the signaling must occur among workers.  This is why, for instance, you NEVER see an implementation of lean production without some kind of Kanban system.  Why is the Kanban necessary?  Because otherwise, people would not know what to do next.  In manufacturing, Kanban is the local signaling mechanism which allows decisions to be made late and implemented very quickly.

 

Unless and until projects implement the equivalent of Kanban, they will not be lean.  But we do not need Kanban in the normal, manufacturing sense of Kanban.  We need a mechanism for people to locally signal each other what to do next.  The reason you need flow is so that there is ‘pull’, and this is, in turn, so one person on the line can signal the next person down the line what they need. 

 

In projects, the moral equivalent of Kanban, in my opinion, is the daily or weekly meeting in which people signal to their peers what they need each other to do next.  In the case of lean construction, XP and Scrum, that meeting is quite structured and servers the exact same purpose of a Kanban system – it is the way people signal to each other what to do.  My theory is that without a way for people to effectively signal each other what to do, you have to have some outside force accomplish the same thing, with some sort of a schedule.

 

Now we who have been in manufacturing have all experienced the unreliability of schedules.  You do a MRP run, then find that whereas you were to make 50 gizmos this week, now you have to make 500.  And the 700 of those other gizmos you were working overtime to make – well, don’t need them any more.  There are good mathematical reasons why MRP schedules exhibit this ‘nervous’ behavior; you study them in operations classes.  The slightest variation in demand from forecast will cause nervousness in direct proportion to the batch sizes.  (Bigger batches, bigger swings.)

 

Pre-planned schedules do not work in an environment with even a bit of change.  I know this is also true in construction.  Or any project.  But the alternative is not so intuitive – because it requires setting up a fairly rigorous mechanism which will reliably let a large number of people respond rapidly and correctly to change.  That means the underlying organization must be in place to do so – and there is almost no theory out there other than Kanban which tells us how to do this. 

 

My summary would be this:  in my paradigm, delaying decisions until certainty makes them clear is always a wise approach.  The problem is, we need to have set up the mechanisms for a large number of people to respond rapidly and correctly once the decision is made.  This is much harder in projects, because there is no repetitive pattern upon which to establish a Kanban system.  But the Last Planner and Scrum meeting are the mechanism, we just have to get people to understand why these are so necessary and so effective, and make sure they are structured and used for the purpose they must serve.  

 

Mary Poppendieck

www.poppendieck.com

952-934-7998

 

-----Original Message-----
From: Hal Macomber [mailto:hal@...]
Sent: Thursday, October 31, 2002 10:35 PM
To: leandevelopment@yahoogroups.com
Subject: [leandevelopment] Re: Dangerous Metaphor

 

Hello Tom,

We are struggling with the lean metaphor in looking at projects in
general.  Too much of the attention of the metaphor attends to the
materiel elements of our world.  In Koskela's and Howell's paper
on "Obsolete Project Management Theory" they defacto accept the
proposition that "Projects are just special instances of
production."  While both K&H are dissatisfied with the current theory
they've failed to go to the root...examining what is a project.

The machine metaphor has us stuck.  We've accepted it for so long we
no longer see it as metaphor and all that is hidden by metaphor. 
Greg Howell and I struggle daily looking for a language that allows
us to make distinctions in a different paradigm.  We have concluded
that we may be best off avoiding metaphor altogether.  (We'll see how
long that lasts!)

In the meantime, I am paying close attention to you folks.  I learn
from you at each encounter.  You are struggling with the issues of
the failing of our principles and practices at a level of seriousness
and intensity that I have not witnessed anywhere except in our little
community of the Lean Construction Institute.  Let's wish each other
well!

Hal

Get a daily dose of the changes underway in project management at Reforming Project Management.  What's a weblog?  http://weblog.halmacomber.com

978-470-8994

-----Original Message-----
From: sentto-7737280-21-1035923926-kent=threeriversinstitute.org@... [mailto:sentto-7737280-21-1035923926-kent=threeriversinstitute.org@...] On Behalf Of Tom Poppendieck
Sent: Tuesday, October 29, 2002 12:39 PM
To: leandevelopment@yahoogroups.com
Subject: RE: [leandevelopment] Getting Agile across the Chasm

Kent –

 

Since you and Ward delivered a “Distinguished Lecture” on pair programming for the local Object technology user group symposium a couple years back, the majority of the invited lectures have addressed Agile topics and attracted 100-200 people. … there is interest.

 

In the Twin Cities area:

1.      I know of a large legal publishing company that uses XP in several areas. 

2.      Some groups at the local Federal Reserve Bank are using XP. 

3.      I am familiar with a major retailing software organization using XP for ALL their product development.

4.      A small HR product company has recently adopted XP for all their product development.

5.      A medium size nationwide mobile services dispatch organization recently switched to XP for their wireless and web  based product development.

6.      At least three local consultancies use XP for a large portion of their business. 

7.      A VERY large commodities company is using TDD to drive major restructuring of a critical Smalltalk application. 

8.      A big locally based mechanical test equipment company is considering adding XP engineering practices to the SCRUM management practices they have been using.  (Do you know of a good reference on TDD I can recommend to them? They have a BIG VB6 application that interacts with test equipment and takes too long to debug and deployment test.)

 

It seems to me that this is more than innovators toying with cool technology.  The organizations I am familiar with definitely are after and getting real business advantage.

   

On the other hand, Monster.com currently lists (nationwide)

·         5 openings that mention Scrum,

·         35 jobs that call out Extreme Programming

·         88 postings mention Agile though less than half of these are about software.

·         779 that refer to that other XP.

·         1005 postings refer to LEAN as in manufacturing.

Maybe I need to go back and re-read the Chasm book as well, lest I get too optimistic. 

 

Can anyone else on this list offer more examples or measures?

 

- Tom Poppendieck

--- In leandevelopment@y..., Arien Malec <arien_malec@y...> wrote:
>
> --- Tom Poppendieck <tom@p...> wrote:

>> We'd appreciate feedback from this group about how to make it more
>> effective in enabling these people to benefit from Lean Thinking on
>> software projects.... Does the book succeed at this in it's initial
>> draft posted at www.poppendieck.com/ld.htm?
>
> I'd say that it does an admirable job at giving a theoretical basis
> for why agile methodologies work, and in connecting agile
> methdologies to other similar approaches in other fields.

Just to add to my previous message, I think that within the parameters
of the book itself, it may be more valuable with some practices that
suppliment the theory and comparative information. I'll give one
example, with which I'm the most familiar:

In the discussion of real options, I think the theoretical discussion
is very well done, but the book lacks a connection to actual
practice. For example:

Let's say that I'm convinced that real options are the way to value
new and ongoing software projects, and I want to use this method
instead of DCF in constructing my business case:

1) Should I be using Black-Scholes or the Binomial Model?
2) How do I estimate option value and volatility for software projects?
3) What tools should I be using to calculate valuations?
4) How do I update valuations?
5) How do I control projects using real options valuations?

Or should I not be using numerical calculations at all? Then, how
should I be constructing my business case?

The chapter has some discussion of implications of using options
thinking. For instance, we create value by killing projects early. One
should also note that it becomes easier to start projects if one
values them using real options (because the risk exposure is much
lower). The real breakthrough, IMHO, comes when we manage portfolios
of options. But all of this has strong implications to project
oversight.

Arien

Hello Tom,

We are struggling with the lean metaphor in looking at projects in
general.  Too much of the attention of the metaphor attends to the
materiel elements of our world.  In Koskela's and Howell's paper
on "Obsolete Project Management Theory" they defacto accept the
proposition that "Projects are just special instances of
production."  While both K&H are dissatisfied with the current theory
they've failed to go to the root...examining what is a project.

The machine metaphor has us stuck.  We've accepted it for so long we
no longer see it as metaphor and all that is hidden by metaphor.
Greg Howell and I struggle daily looking for a language that allows
us to make distinctions in a different paradigm.  We have concluded
that we may be best off avoiding metaphor altogether.  (We'll see how
long that lasts!)

In the meantime, I am paying close attention to you folks.  I learn
from you at each encounter.  You are struggling with the issues of
the failing of our principles and practices at a level of seriousness
and intensity that I have not witnessed anywhere except in our little
community of the Lean Construction Institute.  Let's wish each other
well!

Hal


--- In leandevelopment@y..., "Tom Poppendieck" <tom@p...> wrote:
> As we wrote Lean Development, we tried to keep in mind the danger
posed by
> metaphors.  Indeed, the manufacturing metaphor with its focus on
repeatable
> process has been the cause of much failure and pain in the software
> development community.   Our belief is that the metaphor has failed
us
> because people applying it have had a very shallow understanding of
> manufacturing or construction reality.  Metaphor mapping has to be
done at
> the level of the principles and values that motivate the processes
and
> activities, not at the process/activity level.   Many manufacturing
> organizations copying lean appearance without adopting the
principles and
> values of lean thinking have failed.
>
> Lean is not a silver bullet formula one can plug in and magically
get
> results; it is a way of life.  Agile software development advocates
are
> rediscovering this way of life 15 years behind some other parts of
the
> economy.   In many manufacturing, logistics, supply chain, and
service
> domains, lean behavior is today the norm.  The problem is the same,
enabling
> a group of people to collaborate productively on a complex task.
The
> software development task may be more complex than some of these
other
> domains and the software developer may be more attuned to abstract
reasoning
> than the average factory worker but the human nature of all the
contributors
> and the issues they face in collaborating are the same.  Lean
principles
> work for all.
>
> We have lived in the lean manufacturing world, the lean product
development
> world, and in the software development worlds both as practitioners
and
> managers.  We believe that this book is a real start at getting the
mapping
> right.  It is written for managers and project leaders because an
> organizations leadership determines its values and mindset.  A
mindset is a
> very hard thing to change and can only be motivated by a very
powerful need.
> Today, the survival of our organizations in a world that demands
flexibility
> and responsiveness may provide that need.
>
>
> - Tom Poppendieck

-----Original Message-----
From: Tom Poppendieck [mailto:tom@...]
Sent: Tuesday, October 29, 2002 1:39 PM
To: leandevelopment@yahoogroups.com
Subject: RE: [leandevelopment] Getting Agile across the Chasm

Kent –

 

Since you and Ward delivered a “Distinguished Lecture” on pair programming for the local Object technology user group symposium a couple years back, the majority of the invited lectures have addressed Agile topics and attracted 100-200 people. … there is interest.

 

In the Twin Cities area:

1.      I know of a large legal publishing company that uses XP in several areas. 

2.      Some groups at the local Federal Reserve Bank are using XP. 

3.      I am familiar with a major retailing software organization using XP for ALL their product development.

4.      A small HR product company has recently adopted XP for all their product development.

5.      A medium size nationwide mobile services dispatch organization recently switched to XP for their wireless and web  based product development.

6.      At least three local consultancies use XP for a large portion of their business. 

7.      A VERY large commodities company is using TDD to drive major restructuring of a critical Smalltalk application. 

8.      A big locally based mechanical test equipment company is considering adding XP engineering practices to the SCRUM management practices they have been using.  (Do you know of a good reference on TDD I can recommend to them? They have a BIG VB6 application that interacts with test equipment and takes too long to debug and deployment test.)

 

It seems to me that this is more than innovators toying with cool technology.  The organizations I am familiar with definitely are after and getting real business advantage.

   

On the other hand, Monster.com currently lists (nationwide)

·         5 openings that mention Scrum,

·         35 jobs that call out Extreme Programming

·         88 postings mention Agile though less than half of these are about software.

·         779 that refer to that other XP.

·         1005 postings refer to LEAN as in manufacturing.

Maybe I need to go back and re-read the Chasm book as well, lest I get too optimistic. 

 

Can anyone else on this list offer more examples or measures?

 

- Tom Poppendieck
  

 

-----Original Message-----
From: Kent Beck [mailto:kent@...]
Sent: Tuesday, October 29, 2002 12:36 PM
To: leandevelopment@yahoogroups.com
Subject: RE: [leandevelopment] Getting Agile across the Chasm

 

I've re-read the Chasm book. I think XP is still stuck at the small
chasm, the one between innovators (technical people who want to do a new
process because it's cool) and visionaries (business people who accept
risks if they can create business advantage). I'm not going to worry
about the early majority until XP-related business success stories are
common.

Kent

To unsubscribe from this group, send an email to:
leandevelopment-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I've re-read the Chasm book. I think XP is still stuck at the small
chasm, the one between innovators (technical people who want to do a new
process because it's cool) and visionaries (business people who accept
risks if they can create business advantage). I'm not going to worry
about the early majority until XP-related business success stories are
common.

Kent

> -----Original Message-----
> From:
> sentto-7737280-19-1035869174-kent=threeriversinstitute.org@ret
> urns.groups.yahoo.com
> [mailto:sentto-7737280-19-1035869174-kent=threeriversinstitute
> .org@...] On Behalf Of Arien Malec
> Sent: Monday, October 28, 2002 9:26 PM
> To: leandevelopment@yahoogroups.com
> Subject: Re: [leandevelopment] Getting Agile across the Chasm
>
>
>
>
> --- Tom Poppendieck <tom@...> wrote:
> > We'd appreciate feedback from this group about how to make it more
> > effective in enabling these people to benefit from Lean Thinking on
> > software projects.
> ...
> > Does the book succeed at this in it's initial draft posted at
> > www.poppendieck.com/ld.htm?
>
> I'd say that it does an admirable job at giving a theoretical
> basis for why agile methodologies work, and in connecting
> agile methdologies to other similar approaches in other fields.
>
> What I think will be needed eventually will include the
> theoretical and comparative approach of Lean Toolkit,
> combined with the empirical appoach of something like The
> Machine That Changed the World and the case study/evangelical
> approach of Lean Thinking. That is to say, I think the early
> majority need to see:
>
> 1) Proof that this stuff works
> 2) Some basis for how it works and some assurance that this
> is not crazy
> 3) Some people "just like me" who made it work, with some
> sense for the real issues that come up in a transformation to agile.
>
> On the other hand, I've already drunk the Kool-Aid, as it
> were, so it's hard for me to switch back my focus. I will say
> that Lean Toolkit has broadened my theoretical understanding
> of how and why approaches like Scrum and XP work.
>
> Arien
>
> __________________________________________________
> Do you Yahoo!?
> HotJobs - Search new jobs daily now
> http://hotjobs.yahoo.com/
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~--> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA> /NhFolB/TM
>
>
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> leandevelopment-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

--- Tom Poppendieck <tom@...> wrote:
> We’d appreciate feedback from this group about how to make it more effective
> in enabling these people to benefit from Lean Thinking on software projects.
...
> Does the book succeed at this in it’s initial draft posted at
> www.poppendieck.com/ld.htm?

I'd say that it does an admirable job at giving a theoretical basis for why
agile methodologies work, and in connecting agile methdologies to other similar
approaches in other fields.

What I think will be needed eventually will include the theoretical and
comparative approach of Lean Toolkit, combined with the empirical appoach of
something like The Machine That Changed the World and the case
study/evangelical approach of Lean Thinking. That is to say, I think the early
majority need to see:

1) Proof that this stuff works
2) Some basis for how it works and some assurance that this is not crazy
3) Some people "just like me" who made it work, with some sense for the real
issues that come up in a transformation to agile.

On the other hand, I've already drunk the Kool-Aid, as it were, so it's hard
for me to switch back my focus. I will say that Lean Toolkit has broadened my
theoretical understanding of how and why approaches like Scrum and XP work.

Arien

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

-----Original Message-----
From: Mary Poppendieck [mailto:mary@...]
Sent: Monday, October 21, 2002 12:23 PM
To: leandevelopment@yahoogroups.com
Subject: RE: [leandevelopment] Dangerous Metaphor

I agree Kent, Lean Thinking is not the ‘norm’ in manufacturing (whatever that means).  I think this is, in part, because many places tried implementing the lean mechanisms (eg. kanban, Kaizan) and forgot about the people aspects behind the mechanisms. 

 

However, one thing lean has going for it in manufacturing (as opposed to software) is that lean is considered an OKAY approach in manufacturing.  If you tell your boss you are going to move to a lean approach in your factory, you will probably get support, not skepticism.    Not so in software development.  I’m jealous.   

 

Mary Poppendieck

www.poppendieck.com

952-934-7998

 

-----Original Message-----
From: Kent Beck [mailto:kent@...]
Sent: Monday, October 21, 2002 11:42 AM
 

I agreed with your whole posting except the implication that lean thinking is the norm. The NWLEAN mailing list suggests to me that lean is still working its way through the Early Majority. I might say that "lean thinking" definitely isn't going away, but the transition is still perilous.

 

Kent

To unsubscribe from this group, send an email to:
leandevelopment-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

The problem with slides is that they need a
dissertation to go with them, or you need to see them
"live" with the author talking to it.

Hence, I need to think more about how to circulate the
bigger set to a wider audience. Circulating publicly
is different from private circulation.

Getting back to your questions...

Actually, I would put CMM Level 1 down in the Fire
Fighting quadrant too - though you could argue Level 1
is "all over the map".

I believe that using the Lapre/Wassenhove definition
and the definition given by many of the XP community
(I know Dave Astels and Miroslav Novak for example)
that XP is "craft" and is firmly in the "artisan
skills" quadrant.

I placed Scrum where I did for several reasons. I
interpreted the "know why" from the Lapre/Wassenhove
article not to be process "know why" but domain "know
why". I refer to this as the "natural philosophy of
software". In the Scrum book and on the Scrum list,
the advocates explicitly shun modeling and design. By
doing so, they are declaring a position that software
is "alchemy" and somehow "unknowable" in a "know why"
sense. Hence, it must stay in the lower half of the
graph.

The point, if any, is that Scrum allows you to make
sense of a world in the lower half of the graph and
move forward. Scrum probably has the lowest barrier to
entry of any Agile Method. And as such I like it. I
actually have a Scrum/FDD hybrid project running in my
shop at the moment.

I placed FDD where I did for 1 main reason. It is
often misunderstood that FDD is founded in three
areas: software process experience (mainly from the
work of Brooks and Weinberg, adapted by De Luca);
psychology (again, Weinberg and others, adapted by De
Luca); and natural philosophy of software (the unique
contribution of Peter Coad).

Those in the Agile community who don't come from an OO
theory background have completely missed the benefit
or truth in the advances of Peter Coad's (and more
recently Stephen Palmer's) modeling techniques.

The "repeatability" claim for FDD is based on the work
of Coad/Palmer/Mayfield and Nicola (and occasionally
me, and Ian Horrocks, for UI Features).

In his book, Jim Highsmith seems to wrongly associate
"empirical" with "unmeasurable" or "unestimatable"
where the actual dictionary meaning is different - it
means "relying on or derived from observation". Hence,
the Coad/Palmer work on Feature definition, class
Archetypes and the Coad/Palmer/Nicola/Mayfield work on
Domain Neutral Component and/or Pattern Players and
Collaboration Patterns, have created a codification
which has proven, over a 5 year period, on many
diverse projects, in several countries around the
world, to be repeatable. This to me is "know why".
However, ability with these techniques has to be
learned. Hence, I placed FDD across the boundary
between low and high conceptual learning, because its
practitioners will be somewhere on the scale. Because
of all this "know why" conceptual learning, FDD has a
higher barrier to entry than Scrum or XP.

Now if we look at RUP/UDP, which I didn't explicity
place on this diagram. I would place it (or more
accurately a version of it based on OOSE) mostly over
the RSM box but again it could straddle into the lower
row and left hand column. Why?

My view of RUP is that it too seeks to explain a large
amount of the "natural philosophy of software". RUP
was also guided as a purely political play to sell
more tools. The advocates of RUP had a vested interest
in making it as difficult as possible in order to sell
tools and consultancy. I have attended OMG meetings
where there has been rampant argument being Rational
and non-Rational staff regarding the complexity versus
simple elegance argument.

Hence, RUP proposes a large degree of "know why" but
the model isn't always correct. At one stage Use Cases
were advocated as the silver-bullet. A Use Case we
were told was: the requirements; the procedure for the
controller in an MVC pattern; and the test case. We
know now that this was wrong. I would compare it to
the "plumb pudding" model for the nucleus of an atom -
nice while it lasted, until something better came
along.

RUP has a high barrier to entry, there is a lot of
conceptual learning and often the theory is unproven.

Now, let's look at the RUP as a meta-holder for XP.
Again, we need to revisit the history of Rational
Corporation and how you account for continued growth.
So once upon a time there was Jacobson's OOSE, then it
was called Objectory and it had a tool. Later, after
the acquisition of the three-amigos, it was renamed
RUP. Once, the market for Use Case addicts has been
exhausted how do you build the market yet further?
Easy - you declare that RUP isn't really a process but
a meta-process. The same thing happened with UML - it
moved up the stack to meta-modeling. So, if you don't
like the UML, just define your own version using the
UML meta-model. Which led to, if you don't like the
Rational version of RUP, just define your own version
of a process using RUP, the meta-process.

Where am I going with this? Well frankly RUP is not a
process, it is a meta-process. What many shops using
the RUP call RUP is really just OOSE with a few
updates. As for XP as a plug-in to RUP - it is really
XP with some compromises (by all accounts).

Comparing RUP (the meta-process) to XP (the process)
or Scrum (the process) or FDD (the process) is like
comparing apples to mail order catalogs. If I had to
draw OOSE (or a more recent derivative on the chart)
it would be firmly in the top half and much of it in
the "unproven theory" column.

Gee! I haven't written a stir-up the controversy type
post like this in a long time. Better put my tin hat
on now.

David


--- Tom Poppendieck <tom@...> wrote:
> David -
>
> Would you be willing to share the other views you
> mentioned below?
>
> I think I would place CMM Level 1 down in the
> firefighting quadrant, not
> Scrum.
>
> - Tom Poppendieck
>
>


__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

I think that we need to start now and change the
mental model in the Agile community from "metaphor" to
"abstraction" (or at worst "simile"). If people can
adopt a mental model around the notion of abstraction,
it prevents them from atempting to over-strech the
metaphor - which is what debunked metaphor in the UI
world and I see happening all over again in the Agile
world.

(Primarily) Alan Cooper led the UI world from a mental
model of "metaphor" to a mental model of "idiomatic
controls". A similar thing needs to happen in the
Agile world. The XP community introduced the notion of
metaphor and created a mental model which ultimately
restricts the ability of the wider community to absorb
ideas which can move the debate/dialogue forward.
Hence, it is time to "out" the metaphor based mental
model and replace it with something more powerful -
systems absraction!

David

--- Tom Poppendieck <tom@...> wrote:
> David -
>
> You are right.  The mapping has to occur at a
> systems thinking level of
> abstraction.  I chose the term metaphor because that
> is the term being used
> on other currently active groups.  The principles of
> lean thinking are a
> powerful abstraction that encapsulates much
> understanding of how to
> collaborate on complex problems.
>
> - Tom Poppendieck
>
>
>

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

It's interesting that you should pick up the Lapre and
Wassenhove article from HBR. I read it on the way to
work a week or so ago and it caused me to create this
diagram (attached) which maps (IMO) where various
methodologies would place themselves on the map.

This is one slide from a number of others which seek
to show that there is a maturity model involved with
Agile Methods. I treat CMM Level 1 as useless and
analyze how an organization can produce results and
mature without necessarily trying to jump the high
barrier to entry of CMM Level 2 and traditional
methods. The Lapre/Wassenhove model is just one of a
number of orthogonal views I have taken, in an attempt
to try and explain why Agile Methods are useful and
where their place in the world actually lies.

As this slide is a first stab, I would appreciate
feedback. Thanks

David


--- Tom Poppendieck <tom@...> wrote:
> In the October 2002 Harvard Business review, Michael
> Lapre and Luk Van
> Wassenhove offer some insight in an article called
> “Learning Across Lines,
> The secret to more efficient factories”.  They
> distinguish two kinds of
> learning, conceptual learning and operational
> learning.  An organizations
> processes are based on some combination of these.
> Operational learning
> yields know-how based on operational experience with
> what works.  Conceptual
> learning is root-cause understanding based on sound
> theory.  It is know-why?
>
> -----------+-------------+-------------------------+
> conceptual | unvalidated | operationally validated |
>    high    | theories    | theories                |
> -----------+-------------+-------------------------+
> conceptual | fire        | artisan                 |
>    low     | fighting    | skills                  |
> -----------+-------------+-------------------------+
>            | operational | operational             |
>  LEARNING  | low         | high                    |
>
> Only process improvements based on BOTH know-how and
> know–why are found to
> have lasting, long-term, bottom line impact across
> the organization.  Our
> goal in this book is to assist organizations in
> moving to the upper right
> quadrant of this learning matrix by offering
> examples of how lean thinking
> theory has been operationally validated in other
> domains and offering a map
> to show how the concepts can be applied in software
> development.  The next
> step is to operationally validate the tools in your
> own development
> environment.
>
> We’d appreciate your feedback on the tools we offer
> here.
>
>
> - Tom Poppendieck
>
>
>



__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

I think the problem is in the use of the word
"metaphor" and not in the comparison to manufacturing.

What you are really saying is that you want people to
use a systems thinking approach to software
development. A manufacturing factory is a good example
of a factory. So it would be more accurate to use the
word "analogy" rather than metaphor. Hence, "software
development can be thought of 'like' a factory".

However, I would go further and suggest that analogy
is not strong enough. You are really talking about
abstraction. If a factory is a system, you are saying
that software development is also a system. When you
talk about principles and values, you are talking
about the principles and values which belong to the
abstraction (of systems thinking), not to the reality
of manufacturing process.

Regards,

David

PS There is a whole history of why metaphor is
dangerous published in the UI design field.
Unfortunately, no immediate reference jumps to mind.

--
David J. Anderson
http://www.uidesign.net/
The webzine for interaction designers


--- Tom Poppendieck <tom@...> wrote:
> As we wrote Lean Development, we tried to keep in
> mind the danger posed by
> metaphors.  Indeed, the manufacturing metaphor with
> its focus on repeatable
> process has been the cause of much failure and pain
> in the software
> development community.   Our belief is that the
> metaphor has failed us
> because people applying it have had a very shallow
> understanding of
> manufacturing or construction reality.  Metaphor
> mapping has to be done at
> the level of the principles and values that motivate
> the processes and
> activities, not at the process/activity level.
> Many manufacturing
> organizations copying lean appearance without
> adopting the principles and
> values of lean thinking have failed.
>
>

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

Hi Mary,

congtrats. I will have some time after I get back week after next to look it
over.

Jim

Mary Poppendieck writes:

> Hello Everyone,
>
>
>
> Today I posted the full first draft of the book:  Lean Development:  A
> Toolkit for Software Development Managers at www.poppendieck.com/ld.htm.
> By agreement with the editor, this is the last version which will be
> posted on the web.  However, I can mail out new drafts by request, and
> this discussion group will be a way to find out about changes.
>
>
>
> The book is scheduled to be available in April, but is still under
> active revision.  Comments are more than welcome!
>
>
>
> Mary Poppendieck
>
> www.poppendieck.com <http://www.poppendieck.com/>
>
> 952-934-7998
>
>
>