Home > Archive > Extreme Programming > June 2004 > Empowering the developer using a software kanban system
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 |
Empowering the developer using a software kanban system
|
|
| Generic Usenet Account 2004-05-21, 2:35 pm |
| [My apologies to comp.software-eng and comp.sources.d readers for the
reposting. I am crossposting to additional groups to solicit more
response. Thanks to Phlip, Arasa Kumaran and Parks for their valuable
input]
Recently I read about the software kanban system in Mary & Tom
Poppendieck's book ("Lean Software Development, An Agile Toolkit"). I
was excited by the whole concept of jotting down the list of pending
tasks/features/stories on index cards and posting them on a board in a
"To Do" area. As the developers figure out what they are interested
in working in, they move the cards to a "Checked Out" area with their
name attached. When a developer is done coding and testing, he/she
moves his/her card to the "Tests Passed" area and checks out another
card.
When I presented this idea to the team, they were totally fascinated!
We surely are going to give this a try.
Does anyone out there have any experience with the software kanban
system, as described in Mary & Tom Poppendieck's book? Did it work
for you as described, or did you have to make some adjustments?
Regards,
Bhat
| |
| Zahid Faizal 2004-05-22, 2:30 am |
| usenet@sta.samsung.com (Generic Usenet Account) wrote in message news:<90e5135.0405210914.7ba0170e@posting.google.com>...
> [My apologies to comp.software-eng and comp.sources.d readers for the
> reposting. I am crossposting to additional groups to solicit more
> response. Thanks to Phlip, Arasa Kumaran and Parks for their valuable
> input]
>
>
> Recently I read about the software kanban system in Mary & Tom
> Poppendieck's book ("Lean Software Development, An Agile Toolkit"). I
> was excited by the whole concept of jotting down the list of pending
> tasks/features/stories on index cards and posting them on a board in a
> "To Do" area. As the developers figure out what they are interested
> in working in, they move the cards to a "Checked Out" area with their
> name attached. When a developer is done coding and testing, he/she
> moves his/her card to the "Tests Passed" area and checks out another
> card.
>
> When I presented this idea to the team, they were totally fascinated!
> We surely are going to give this a try.
>
> Does anyone out there have any experience with the software kanban
> system, as described in Mary & Tom Poppendieck's book? Did it work
> for you as described, or did you have to make some adjustments?
>
> Regards,
> Bhat
This certainly looks interesting, but I am not sure how it will work
when the team size exceeds a certain critical mass, or if you are
outsourcing. You almost need to invent a metropolitan-area or
wide-area kanban board!
-- ZF
| |
|
| On Fri, 21 May 2004 17:14:42 UTC, usenet@sta.samsung.com (Generic Usenet
Account) wrote:
> [My apologies to comp.software-eng and comp.sources.d readers for the
> reposting. I am crossposting to additional groups to solicit more
> response. Thanks to Phlip, Arasa Kumaran and Parks for their valuable
> input]
>
>
> Recently I read about the software kanban system in Mary & Tom
> Poppendieck's book ("Lean Software Development, An Agile Toolkit"). I
> was excited by the whole concept of jotting down the list of pending
> tasks/features/stories on index cards and posting them on a board in a
> "To Do" area. As the developers figure out what they are interested
> in working in, they move the cards to a "Checked Out" area with their
> name attached. When a developer is done coding and testing, he/she
> moves his/her card to the "Tests Passed" area and checks out another
> card.
>
> When I presented this idea to the team, they were totally fascinated!
> We surely are going to give this a try.
>
> Does anyone out there have any experience with the software kanban
> system, as described in Mary & Tom Poppendieck's book? Did it work
> for you as described, or did you have to make some adjustments?
>
> Regards,
> Bhat
Bhat,
I resisted the urge to reply to this post the first time around.
However, I was enlightened by the responses to your post. So, for
what its worth, I'll add my $0.02 USD.
Has anyone NOT done this before? Perhaps for a non-programming
project? The concept of a To Do List (in the form of index cards)
and sharing those ideas with others seems to be a very old concept.
I'm pretty sure we did a similar exercise in grade school. Why is
the need for such a concept 'new' or 'interesting' to some
programmers? We've all learned many useful organisational and
planning strategies for writing papers, giving speeches, planning
a project, and doing many day-to-day activities in our lifetimes.
Why is it when people are faced with a new concept (programming?)
they suddenly forget all their other skills?
There are times when larger groups or longer memories require
that we use tools to help us do our work. Why is it that we tend
to want special tools when simpler solutions (IMHO) are available?
David
| |
|
| Zahid Faizal wrote:
> This certainly looks interesting, but I am not sure how it will work
> when the team size exceeds a certain critical mass, or if you are
> outsourcing. You almost need to invent a metropolitan-area or
> wide-area kanban board!
When you pay someone to solve a problem for you, you must give them both
responsibility and authority. They must be empowered to solve your problem
their way.
If you don't like that, the fix is to help them solve the problem. Be
onsite.
Outsourcing can work two ways. Either you give responsibility, reserve
authority, and generate incredible friction, or you also grant some
authority.
If you do that, you are giving your business away. The remote team now runs
the show, and you are an absentee mill owner.
The simple logic and easy results of a software kanban system are a
demonstration why insourcing is best.
David wrote:
> Has anyone NOT done this before? Perhaps for a non-programming
> project? The concept of a To Do List (in the form of index cards)
> and sharing those ideas with others seems to be a very old concept.
> I'm pretty sure we did a similar exercise in grade school. Why is
> the need for such a concept 'new' or 'interesting' to some
> programmers? We've all learned many useful organisational and
> planning strategies for writing papers, giving speeches, planning
> a project, and doing many day-to-day activities in our lifetimes.
> Why is it when people are faced with a new concept (programming?)
> they suddenly forget all their other skills?
>
> There are times when larger groups or longer memories require
> that we use tools to help us do our work. Why is it that we tend
> to want special tools when simpler solutions (IMHO) are available?
Because engineers learn a bias towards high-tech solutions, even when the
low-tech ones are best.
A software solution that simulates "cards pinned to a bulletin board" would
need to simulate all their properties to be effective.
--
Phlip
http://industrialxp.org/community/b...tUserInterfaces
| |
| John Roth 2004-05-22, 9:31 am |
| "Generic Usenet Account" <usenet@sta.samsung.com> wrote in message
news:90e5135.0405210914.7ba0170e@posting.google.com...
> [My apologies to comp.software-eng and comp.sources.d readers for the
> reposting. I am crossposting to additional groups to solicit more
> response. Thanks to Phlip, Arasa Kumaran and Parks for their valuable
> input]
Since I didn't see the original conversation, I may be plowing
old ground here, but...
> Recently I read about the software kanban system in Mary & Tom
> Poppendieck's book ("Lean Software Development, An Agile Toolkit"). I
> was excited by the whole concept of jotting down the list of pending
> tasks/features/stories on index cards and posting them on a board in a
> "To Do" area. As the developers figure out what they are interested
> in working in, they move the cards to a "Checked Out" area with their
> name attached. When a developer is done coding and testing, he/she
> moves his/her card to the "Tests Passed" area and checks out another
> card.
That's a simple self-organizing mechanism, and it's been used for
ages in lots of areas. In this particular case, it works because there
is a pool of developers each of who can work on most of the tasks
on the board.
With all due respect to the Poppendiecks, it is not, strictly speaking,
kanban. Kanban is a technique of not creating the input to a process
until you need it. A good example of kanban is the XP technique of
not doing detailed requirements until you have developers availible
to work on them, as distinguished from doing all the requirements
in full detail up front.
To have a true kanban system for engineering tasks, you would have
to eliminate iteration boundaries. As the inventory of tasks
drops, you introduce the next story, do the detailed requirements
and the engineering task breakdown, and then add those tasks
to the inventory of waiting tasks. I think experiance shows that the
iteration boundaries, with the "production quality deployable"
invariant, is much too important to allow this.
John Roth
> Regards,
> Bhat
| |
| Jeff Grigg 2004-05-22, 12:33 pm |
| > --- usenet@sta.samsung.com (Generic Usenet Account) wrote:
Sounds like our "to do" list of screens on the eight person TRx
project I worked on a few years ago.
Here's a problem we experienced:
The acts of adding and removing tasks are done independently, often at
different times by different people. This loses the social nature of
negotiating work creation and execution, which can lead to problems.
We had a chronic problem of running out of work -- some team members
were idle for up to one third of the time. In a more *social* work
creation and execution environment, the work "doers" could negotiate
with the work "producers" to pass the work through with a higher level
of trust that an informal agreement on requirements would be
sufficient to get things done right. You can't do this when people
aren't talking to each other. Also, when the "doers" are idle, it
would be easier for some of them to switch to the "producer" role, if
the two groups were working more closely with each other.
Also...
We did enjoy a high level of trust that people would be responsible
for doing, finishing and delivering any work they signed up for. So
we didn't track who was doing what. To volunteer for a task, a person
would *erase* it from the board. And when it's done, it's done.
--- "David" <FlyLikeAnEagle@United.Com> wrote...[color=darkred]
> Has anyone NOT done this before? Perhaps for a non-programming
> project? The concept of a To Do List (in the form of index cards)
> and sharing those ideas with others seems to be a very old concept.
> I'm pretty sure we did a similar exercise in grade school. Why is
> the need for such a concept 'new' or 'interesting' to some
> programmers? [...] Why is it that we tend to want special tools
> when simpler solutions (IMHO) are available?
It's an old and highly effective consultants trick to push new and
obscure terminology, such as words from a foreign language, to confuse
the listeners, make them impressed by your knowledge, and make them
dependent on you to find the truth and wisdom of your words. If we
just said, "make a TO DO list," no one would take it seriously. ;->
| |
| Robert C. Martin 2004-05-23, 10:30 am |
| On 21 May 2004 22:17:12 -0700, zahidfaizal@canada.com (Zahid Faizal)
wrote:
>usenet@sta.samsung.com (Generic Usenet Account) wrote in message news:<90e5135.0405210914.7ba0170e@posting.google.com>...
>
>
>This certainly looks interesting, but I am not sure how it will work
>when the team size exceeds a certain critical mass, or if you are
>outsourcing. You almost need to invent a metropolitan-area or
>wide-area kanban board!
I know of one team of ~60 that has split into about a dozen sub teams,
each of which use a similar idea. They've been doing it for about 18
months with remarkable success. They use a backlog on a whiteboard
instead of cards, but the idea is the same.
-----
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
| |
| Isaac Gouy 2004-05-23, 5:32 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10auiuf6nihbdd9@news.supernews.com>...
-snip-
> To have a true kanban system for engineering tasks...
"So why has it been so difficult to decode the Toyota Production
System? The answer, we believe, is that observers confuse the tools
and practices they see on their plant visits with the system itself.
That makes it impossible for them to resolve an apparent paradox of
the system - namely, that activities, connections, and production
flows in a Toyota factory are rigidly scripted, yet at the same time
Toyota's operations are enormously flexible and adaptable...
To understand Toyota's success, you have to unravel the paradox - you
have to see that the rigid specification is the very thing that makes
the flexibility and creativity possible." p97
Spear, S. and Brown, H.K. (September-October 1999). "Decoding the DNA
of the Toyota Production System." Harvard Business Review, 97-106.
| |
| John Roth 2004-05-23, 8:30 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0405231218.46f40565@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<10auiuf6nihbdd9@news.supernews.com>...
>
> -snip-
>
> "So why has it been so difficult to decode the Toyota Production
> System? The answer, we believe, is that observers confuse the tools
> and practices they see on their plant visits with the system itself.
> That makes it impossible for them to resolve an apparent paradox of
> the system - namely, that activities, connections, and production
> flows in a Toyota factory are rigidly scripted, yet at the same time
> Toyota's operations are enormously flexible and adaptable...
> To understand Toyota's success, you have to unravel the paradox - you
> have to see that the rigid specification is the very thing that makes
> the flexibility and creativity possible." p97
>
> Spear, S. and Brown, H.K. (September-October 1999). "Decoding the DNA
> of the Toyota Production System." Harvard Business Review, 97-106.
An excellent observation. What makes the Toyota Production
system work is not the process that produces something, it's
knowing how to set up a process that produces something, and
having the confidence that you can set up a working process when
you need to. And have that knowledge shared among everyone on
the team that cares to learn it.
That's why I've said occasionally that XP is an instance of Lean
Software Development. If you only understand XP, you may have
trouble adapting it to specific instances. If you understand Lean,
you will not only understand why XP works, but also how to
create a development process for other environments.
John Roth
| |
| Vladimir Trushkin 2004-05-24, 3:40 am |
|
"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:d291b0t43dc99lbj7ico0m1a3f64nopkt9@
4ax.com...
> On 21 May 2004 22:17:12 -0700, zahidfaizal@canada.com (Zahid Faizal)
> wrote:
> I know of one team of ~60 that has split into about a dozen sub teams,
> each of which use a similar idea. They've been doing it for about 18
> months with remarkable success. They use a backlog on a whiteboard
> instead of cards, but the idea is the same.
Robert, if you don't mind we would like to hear more about "a remarkable
success".
*Still looking for evidence...*
----
Best Wishes,
Vladimir
| |
| Gerold Keefer 2004-05-24, 4:30 am |
| thanks for this very interesting citation. i am highly critical
of any pool system as it requires equal capability of the
implementers.
best regards,
gerold
Isaac Gouy wrote:
> "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10auiuf6nihbdd9@news.supernews.com>...
>
> -snip-
>
> "So why has it been so difficult to decode the Toyota Production
> System? The answer, we believe, is that observers confuse the tools
> and practices they see on their plant visits with the system itself.
> That makes it impossible for them to resolve an apparent paradox of
> the system - namely, that activities, connections, and production
> flows in a Toyota factory are rigidly scripted, yet at the same time
> Toyota's operations are enormously flexible and adaptable...
> To understand Toyota's success, you have to unravel the paradox - you
> have to see that the rigid specification is the very thing that makes
> the flexibility and creativity possible." p97
>
> Spear, S. and Brown, H.K. (September-October 1999). "Decoding the DNA
> of the Toyota Production System." Harvard Business Review, 97-106.
| |
| Isaac Gouy 2004-05-24, 1:31 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10b2e3mb64tpi01@news.supernews.com>...
>
> An excellent observation.
I recommend the article.
-snip-
> That's why I've said occasionally that XP is an instance of Lean
> Software Development.
There seem to be different opinions about that...
http://groups.google.com/groups?q=g...ting.google.com
| |
| John Roth 2004-05-24, 2:31 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0405240806.1e41f257@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<10b2e3mb64tpi01@news.supernews.com>...
>
>
> I recommend the article.
>
> -snip-
>
> There seem to be different opinions about that...
>
http://groups.google.com/groups?q=g...ting.google.com
I'm not sure how that's a different opinion. Lean Manufacturing
explicitly rejects the Henry Ford/Fredrick Taylor Pseudoscientific
Management view of how to organize
manufacturing, and Lean Software Development, in particular,
comes from product development, not from product manufacturing.
John Roth
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10b4ccl957qfged@news.supernews.com>...
[color=darkred]
> I'm not sure how that's a different opinion. Lean Manufacturing
> explicitly rejects the Henry Ford/Fredrick Taylor Pseudoscientific
> Management view of how to organize manufacturing
The rejection of "manufacturing" as a model makes it a different
opinion:
"Buried beneath the practices is the paradigm that software
development is a manufacturing process... we must adopt a new
paradigm... Extreme Programming proposes "conversation" as the new
paradigm"
"Fred Taylor, Making Software, and Conversation" Kent Beck
TOOLS-34"00 Abstract
> and Lean Software Development, in particular,
> comes from product development, not from product manufacturing
Help me understand. Here's a Poppendieck article which (in my reading)
explains how Lean Programming is derived from lean manufacturing -
'product development' doesn't seem to be mentioned.
http://www.poppendieck.com/lean.htm
| |
| John Roth 2004-06-03, 7:08 pm |
| "Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0405250809.624013ae@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<10b4ccl957qfged@news.supernews.com>...
>
>
>
> The rejection of "manufacturing" as a model makes it a different
> opinion:
>
> "Buried beneath the practices is the paradigm that software
> development is a manufacturing process... we must adopt a new
> paradigm... Extreme Programming proposes "conversation" as the new
> paradigm"
>
> "Fred Taylor, Making Software, and Conversation" Kent Beck
> TOOLS-34"00 Abstract
The hangup here is that there are two different things
that are being conflated. One is the transition between
Henry Ford/Frederic Taylor "PseudoScientific MisManagement"
manufacturing, and Lean manufacturing; the other is
that product development is not manufacturing, no matter
which model of manufacturing you are using.
It's legitimate to say that a lot of people are trying to
make software development look like the Henry Ford/
Frederic Taylor manufacturing model. However, just saying
that it's not manufacturing drops you into the product development
model that was used in conjunction with that: it doesn't work
either.
The actual distinction is a diagonal: it is neither manufacturing
production, nor is it Ford/Taylor production or product
development.
>
> Help me understand. Here's a Poppendieck article which (in my reading)
> explains how Lean Programming is derived from lean manufacturing -
> 'product development' doesn't seem to be mentioned.
>
> http://www.poppendieck.com/lean.htm
It gets a bit confusing. "Lean Manufacturing" is a renaming of
the "Toyota Production System." "Lean Product Development"
is a renaming of the "Toyota Development System". They have
a great deal in common, but they're not the same thing.
Mary Poppendieck's background is in product development
at 3M, and a lot of that shows when you read the book. I
highly recommend reading the entire book, and then reading
something on the Lean Manufacturing or the Toyota Production
System. I've got "Lean Thinking" by Womak and Jones on my
shelf - it's very enlightening.
John Roth
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10b6tqm73570vb4@news.supernews.com>...
-snip-
> The actual distinction is a diagonal: it is neither manufacturing
> production, nor is it Ford/Taylor production or product
> development.
So what is it?
>
> It gets a bit confusing. "Lean Manufacturing" is a renaming of
> the "Toyota Production System." "Lean Product Development"
> is a renaming of the "Toyota Development System". They have
> a great deal in common, but they're not the same thing.
>
> Mary Poppendieck's background is in product development
> at 3M, and a lot of that shows when you read the book.
The part of the book that seems specifically from product development
is about set-based design, which we've mentioned here:
http://groups.google.com/groups?q=g...ting.google.com
Where in XP could we be said to carry forward multiple designs?
> I highly recommend reading the entire book, and then reading
> something on the Lean Manufacturing or the Toyota Production
> System. I've got "Lean Thinking" by Womak and Jones on my
> shelf - it's very enlightening.
Spear, Steven J. (May 2004). "Learning to Lead at Toyota."
Harvard Business Review, 78-86.
It's very enlightening.
| |
| John Roth 2004-06-03, 7:08 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0405251723.37f345c6@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<10b6tqm73570vb4@news.supernews.com>...
>
> -snip-
>
> So what is it?
The fourth cell in the square, obviously.
>
> The part of the book that seems specifically from product development
> is about set-based design, which we've mentioned here:
>
>
http://groups.google.com/groups?q=g...ting.google.com
>
> Where in XP could we be said to carry forward multiple designs?
Set based development (not design) is tool 6 in the book. It's
about exploratory decision making, not about carrying multiple
designs forward.
Carrying multiple designs forward is one way of delaying
decisions until the last responsible moment, and is the subject
of Chapter 3.
There are a lot of things that XP doesn't say to do, but that
doesn't mean that we can't do them in an XP project. The
key thing here is whether the proposed practice will violate
the integrity of the basic XP workflow. Carrying multiple
designs forward until you can make an informed decision
doesn't do that, so it's a perfectly valid practice.
In fact, you could make quite a good arguement that the
very common practice of using mock objects to speed up
tests is carrying multiple designs forward.
There is a hidden value in doing this: you have to decouple
the area where you are doing multiple implementations from
the rest of the project. This usually has good effects.
John Roth
| |
| Jeff Grigg 2004-06-03, 7:08 pm |
| --- igouy@yahoo.com (Isaac Gouy) wrote...
> The part of the book that seems specifically from product development
> is about set-based design, which we've mentioned here:
>
> http://groups.google.com/groups?q=g...ting.google.com
http://tinyurl.com/2m9hh
> Where in XP could we be said to carry forward multiple designs?
IM(ns)HO... ;->
In XP, we don't really think about it that way. But the closest
equivalent is You Ain't Gonna Need It (YAGNI): We avoid committing to
high level design decisions early by deferring the decisions until the
last responsible moment -- the moment where any further deferral would
cause duplicate code (violating Once And Only Once, OAOO). And I
think that the testing focus, with a heavy emphasis on refactoring
enables us to "keep the options open" in that we can *change* the
design much more easily, so the decision to go down some design path
is not nearly as much of a final commitment to it.
| |
| Laurent Bossavit 2004-06-03, 7:08 pm |
| Isaac:
> Where in XP could we be said to carry forward multiple designs?
I'm still trying to wrap my head around what it could possibly mean to
"carry forward multiple designs" in a software project. Would you be
willing to help me with that - such as by proposing a narrative example?
Laurent
http://bossavit.com/thoughts/
| |
| John Roth 2004-06-03, 7:08 pm |
|
"Laurent Bossavit" <laurent@dontspambossavit.com> wrote in message
news:MPG.1b1eceb27317d8c6989796@news.noos.fr...
> Isaac:
>
>
> I'm still trying to wrap my head around what it could possibly mean to
> "carry forward multiple designs" in a software project. Would you be
> willing to help me with that - such as by proposing a narrative example?
The Poppendiecks give three examples under "Set Based
Software Development". One was a team that developed
several prototypes in parallel so the champion could pick
the best features from each one. Another was an enterprise
system where they had to decide which of three platforms
was best, and developed for all three until the choice was
clear. A third is a web design company that develops two
or three different site designs and has the customer pick
the parts they like, and then merges them into the final
design. See p. 42 and 43 for the discussion.
My favorite example was IBM's System 360
development. They did five processors in parallel,
and that constrained the instruction set architecture
to a very clean model, that has lasted for fourty
years with only minor modifications.
John Roth
>
> Laurent
> http://bossavit.com/thoughts/
| |
| Jeff Grigg 2004-06-03, 7:08 pm |
| --- Laurent Bossavit <laurent@dontspambossavit.com> wrote...
> I'm still trying to wrap my head around what it could possibly mean to
> "carry forward multiple designs" in a software project. Would you be
> willing to help me with that - such as by proposing a narrative example?
I don't think the "carry forward multiple designs" concept applies
directly to XP (or any other highly iterative process with refactoring
and emergent design), because an XP system always has a design -- one
single design -- the simplest design possible for implementing the
features that have been implemented up to that point.
So the "range of designs" XP makes possible is the range of designs
that the system may have in the future -- not a range of top-down
designs.
Now as for top-down plan driven development...
My experience is that it's rare to find a development team that's
really good at considering all the ramifications of *one single*
abstract design. I can't think of any development group I've ever
worked for that I would credit with being able to rationally discuss
and carry forward multiple abstract designs at one time. The
communication barriers and natural sources of confusion and
misunderstanding are just too strong, even with highly motivated
collocated teams.
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10b93ams6dse73a@news.supernews.com>...
>
> The fourth cell in the square, obviously.
Nothing like clear communication.
> http://groups.google.com/groups?q=g...ting.google.com
>
> Set based development (not design) is tool 6 in the book. It's
> about exploratory decision making, not about carrying multiple
> designs forward.
>
> Carrying multiple designs forward is one way of delaying
> decisions until the last responsible moment, and is the subject
> of Chapter 3.
>
> There are a lot of things that XP doesn't say to do, but that
> doesn't mean that we can't do them in an XP project.
-snip-
I keep hearing that.
Is there some problem with simply stating that XP doesn't talk about these things?
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| Laurent Bossavit <laurent@dontspambossavit.com> wrote in message news:<MPG.1b1eceb27317d8c6989796@news.noos.fr>...
> Isaac:
>
>
> I'm still trying to wrap my head around what it could possibly mean to
> "carry forward multiple designs" in a software project. Would you be
> willing to help me with that - such as by proposing a narrative example?
I'm still trying to wrap my head around what it means to do set-based
concurrent engineering. I'm starting to get the impression that's it's
another of those Toyota things where other organisations try and fail.
Maybe they just work a lot of overtime ;-)
"At Toyota, missing launch dates is simply not permitted. Toyota
developers may work in excess of 80 hours per w as phase deadlines
approach in order to finish projects by the launch date." p14
"Explaining the Second Toyota Paradox by Modeling Real Options in
Product Development"
http://www.coe.montana.edu/ie/facul...tions_paper.pdf
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| jgrigg@mo.net (Jeff Grigg) wrote in message news:<c794c0fd.0405260955.2cfc42fd@posting.google.com>...
> --- Laurent Bossavit <laurent@dontspambossavit.com> wrote...
>
> I don't think the "carry forward multiple designs" concept applies
> directly to XP (or any other highly iterative process with refactoring
> and emergent design), because an XP system always has a design -- one
> single design -- the simplest design possible for implementing the
> features that have been implemented up to that point.
>
> So the "range of designs" XP makes possible is the range of designs
> that the system may have in the future -- not a range of top-down
> designs.
imo the "Lean Software Development" book gives a different emphasis to
high stake constraints:
"It is not possible to build in flexibility to accomodate arbitrary
change cheaply. The idea is to build tolerance for change into the
system along domain dimensions that are likely to change." p52
"Certain architectural concepts such as usability design, layering and
component packaging are best made early so as to facilitate emergence
in the rest of the design. A bias toward late commitment must not
degenerate into a bias toward no commitment." p59
"There are a few basic architectural decisions that you need to get
right at the beginning of development becuase they fix the constraints
of the system for it's life... choice of language, architectural
layering, choice to interact with a database used by other
applications." p50
> Now as for top-down plan driven development...
> My experience is that it's rare to find a development team that's
> really good at considering all the ramifications of *one single*
> abstract design. I can't think of any development group I've ever
> worked for that I would credit with being able to rationally discuss
> and carry forward multiple abstract designs at one time. The
> communication barriers and natural sources of confusion and
> misunderstanding are just too strong, even with highly motivated
> collocated teams.
| |
| Laurent Bossavit 2004-06-03, 7:08 pm |
| John:
> The Poppendiecks give three examples under "Set Based Software
> Development".
Thanks - I have the book but didn't think to look there. Should I
understand that "set based design" and "concurrent design" are in fact
synonymous ? I had formed a different impression.
> One was a team that developed several prototypes in parallel so
> the champion could pick the best features from each one. [...] A third
> is a web design company that develops two or three different site
> designs and has the customer pick the parts they like
But those are "just" prototyping or spiking, aren't they - the set is
decimated at some early point (one month out in the first case), after
which only one design is fully developed ?
> Another was an enterprise system where they had to decide which of three
> platforms was best, and developed for all three until the choice was
> clear.
Mary quotes them as saying "this was at the cost of making the
underlying development a little more general". From that I would infer
that they carried forward only *one* design - a more abstract one,
perhaps backed by a simple implementation such as a low-end RDBMS,
before picking a higher-end platform late in the project. That strikes
me as more akin to YAGNI than to "carrying forward multiple designs".
Laurent
http://bossavit.com/thoughts/
| |
| Laurent Bossavit 2004-06-03, 7:08 pm |
| Isaac (quoting another D.N. Ford paper):
> "At Toyota, missing launch dates is simply not permitted. Toyota
> developers may work in excess of 80 hours per w as phase deadlines
> approach in order to finish projects by the launch date." p14
Yeah. Missing launch dates wasn't permitted at NASA, either. They're
slowly recovering from that.
The above refers to "product developers" rather than "software
developers", but as more and more software wends its ways into the cars
we drive, perhaps we will someday have a disaster on our hands of a
sufficient magnitude to call into question practices such as suggested
above. A big carmaker could be wiped out by a large enough recall.
I have less of an objection to overtime paid at overtime rate; in such
cases the management accounting system allows, at least in principles,
for correct arbitration between costs and benefits. Unpaid overtime is
two things: a) a scam - passing on the costs of poor planning to the
employees, and b) managerial suicide - you are destroying management
information.
"In modern warfare, the first step in hostilities is to destroy the
enemy's communication and control system, after which they can be easily
defeated because of their confusion and inability to coordinate their
forces. This is exactly the strategy that seems to be taking place when
the development organization destroys its management's ability to
control the organization."
http://www.stsc.hill.af.mil/crossta...4/Weinberg.html
Weinberg does not specifically discuss overtime in the above article,
but the same reasoning applies.
Laurent
http://bossavit.com/thoughts/
| |
| John Roth 2004-06-03, 7:08 pm |
| "Laurent Bossavit" <laurent@dontspambossavit.com> wrote in message
news:MPG.1b1fc5f16efeda9198979c@news.noos.fr...
> John:
>
>
> Thanks - I have the book but didn't think to look there. Should I
> understand that "set based design" and "concurrent design" are in fact
> synonymous ? I had formed a different impression.
My impression of concurrent design is that you've got different
teams working on different aspects of the project, with some form
of coordination, rather than having a single team working in
serial fashion.
>
> But those are "just" prototyping or spiking, aren't they - the set is
> decimated at some early point (one month out in the first case), after
> which only one design is fully developed ?
Yes.
>
> Mary quotes them as saying "this was at the cost of making the
> underlying development a little more general". From that I would infer
> that they carried forward only *one* design - a more abstract one,
> perhaps backed by a simple implementation such as a low-end RDBMS,
> before picking a higher-end platform late in the project. That strikes
> me as more akin to YAGNI than to "carrying forward multiple designs".
You'd have to ask them, but my impression is that they got quite far
into development before having to commit to one of them.
The thing I take from all of this is that there are a lot of circumstances
where the cost of parallel development to defer a decision until you
have better data is less than the risk premium you would pay for
making a decision with incomplete data.
>
> Laurent
> http://bossavit.com/thoughts/
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| Laurent Bossavit <laurent@dontspambossavit.com> wrote in message news:<MPG.1b1fc3167f168f7098979b@news.noos.fr>...
-snip-
> The above refers to "product developers" rather than "software
> developers", but as more and more software wends its ways into the cars
> we drive, perhaps we will someday have a disaster on our hands of a
> sufficient magnitude to call into question practices such as suggested
> above. A big carmaker could be wiped out by a large enough recall.
-snip-
"What Do You Get When You Cross a Computer with a Car?" p8
"The Inmates Are Running The Asylum" Alan Cooper
Not sure if the Porsche Boxster ignition shut-off story (fast
cornering with low fuel interpreted as catastrophic failure of the
fuel injection system) is apocryphal.
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| Laurent Bossavit <laurent@dontspambossavit.com> wrote in message news:<MPG.1b1fc3167f168f7098979b@news.noos.fr>...
> Isaac (quoting another D.N. Ford paper):
David N Ford /and/ Durward K Sobek
Mr Sobek also seems to have some interesting publications (probably in
the "Lean Software Development" bibliography).
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10b6tqm73570vb4@news.supernews.com>...
-snip-
> Henry Ford/Frederic Taylor "PseudoScientific MisManagement"
> manufacturing, and Lean manufacturing;
-snip-
Stumbled on this suggestion that the introduction of 'Taylorism' could
give rise to something quite different from 'Fordism':
'Importantly, the intention was not, as in the USA, to simplify work
methods and thus to raise the efficiency of untrained labor. On the
contrary, the Japanese managers wanted to build on the existing skills
of their workforce in the railways, to encourage them to stay with
them for their entire careers. In the final analysis, Japan absorbed
and adapted Taylorism in an "organization-oriented," rather than a
"market-oriented," context.'
http://courses.bus.ualberta.ca/orga...shef/taylor.htm
| |
| John Roth 2004-06-03, 7:08 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0405270823.4dea0a6f@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<10b6tqm73570vb4@news.supernews.com>...
>
> -snip-
> -snip-
>
> Stumbled on this suggestion that the introduction of 'Taylorism' could
> give rise to something quite different from 'Fordism':
>
> 'Importantly, the intention was not, as in the USA, to simplify work
> methods and thus to raise the efficiency of untrained labor. On the
> contrary, the Japanese managers wanted to build on the existing skills
> of their workforce in the railways, to encourage them to stay with
> them for their entire careers. In the final analysis, Japan absorbed
> and adapted Taylorism in an "organization-oriented," rather than a
> "market-oriented," context.'
>
> http://courses.bus.ualberta.ca/orga...shef/taylor.htm
Thanks for the reference. I wasn't aware that Taylor preceded
Ford by that much.
However, there's still a vast gulf. The Japanese experience you quote
from the reference was pre WWII; Toyota was post WWII. I suspect
there's some confusion of "Lean Manufacturing" with "Japanese
Manufacturing." I've seen it said that Toyota is actually farther out of
the Japanese mainstream that it is out of the US or European mainstream.
I'd particularly like to draw your attention to Taylor's "rabble
hypothesis."
Nothing could be more opposed to the notion of self-organized teams,
and of putting your trust in the worker.
John Roth
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10bc81cjac7a143@news.supernews.com>...
> However, there's still a vast gulf. The Japanese experience you quote
> from the reference was pre WWII; Toyota was post WWII. I suspect
> there's some confusion of "Lean Manufacturing" with "Japanese
> Manufacturing." I've seen it said that Toyota is actually farther out of
> the Japanese mainstream that it is out of the US or European mainstream.
>
> I'd particularly like to draw your attention to Taylor's "rabble
> hypothesis."
> Nothing could be more opposed to the notion of self-organized teams,
> and of putting your trust in the worker.
"On closer inspection, the association made by Womack cs. of
teamworking with the Toyota Production System a.k.a. lean production
seems somewhat of a fabrication."
Neo-Tayloristic and anti-Tayloristic Models of Team-working
http://web.eur.nl/fsw/english/staff...ruijt/Teampaper
| |
| John Roth 2004-06-03, 7:08 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0405271748.7f6ed0b5@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<10bc81cjac7a143@news.supernews.com>...
>
>
> "On closer inspection, the association made by Womack cs. of
> teamworking with the Toyota Production System a.k.a. lean production
> seems somewhat of a fabrication."
>
> Neo-Tayloristic and anti-Tayloristic Models of Team-working
> http://web.eur.nl/fsw/english/staff...ruijt/Teampaper
Interesting paper. It's going to take a bit of time to digest.
However, I'd suggest that his dichotomy, while historically
accurate, is not entirely correct in describing what is actually
happening in XP type environments. Of course, some of this
may be my biases - I'm about as far left as it's possible to be
and still maintain a coherent conversation with other people.
John Roth
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10be94cr57ddr32@news.supernews.com>...
>
> Interesting paper. It's going to take a bit of time to digest.
> However, I'd suggest that his dichotomy, while historically
> accurate, is not entirely correct in describing what is actually
> happening in XP type environments.
Let me just suggest that we should be very clear about why we think XP
has something to do with 'lean software development', and what 'lean
software development' has to do with 'lean manufacturing' and 'lean
product development'.
From "Fred Taylor, Making Software, and Conversation" we'd say that XP
is 'Anti-Tayloristic'. OTOH claiming a heritage from 'lean
manufacturing' would suggest that XP is 'Neo-Tayloristic'.
Sometimes it seems like buzzword compliance - all the Harvard Business
Review readers have heard how /efficient/ 'lean' can be, so we say
this is like 'lean' for software.
> Of course, some of this
> may be my biases - I'm about as far left as it's possible to be
> and still maintain a coherent conversation with other people.
| |
| John Roth 2004-06-03, 7:08 pm |
| "Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0405281008.129b7724@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<10be94cr57ddr32@news.supernews.com>...
>
>
> Let me just suggest that we should be very clear about why we think XP
> has something to do with 'lean software development', and what 'lean
> software development' has to do with 'lean manufacturing' and 'lean
> product development'.
I'm not so sure I care. My view on the situation is that there
are five identifiable perspectives and value systems in the world,
of which the two most prevalent are one that values personal
achievement and hierarchy, and one that values interrelations
and egalitarianism. Each of these is about 1/3 of the world
population (the second is a higher proportion in Europe).
Taylor is an excellent spokesman for the first (achievement
and hierarchical) viewpoint. "Self organizing teams" or whatever
you want to call it is an excellent exemplar of the second. The
first viewpoint is quite well worked out, the second is still getting
organized.
So to talk about "neo-Taylorism" and "anti-Tailorism" is,
for me, missing the point. These viewpoints and value systems
would be there regardless of whether Taylor existed, or whether
anyone formulated those specific doctrines in that way. They
are fundamental; Taylor is not.
As far as "neo-Taylorism" is concerned, I think the referenced
paper makes a cardinal mistake about Japan and Toyota by
seeing what Japanese manufacturing is like, and then assuming
that it is what Toyota is doing.
> From "Fred Taylor, Making Software, and Conversation" we'd say that XP
> is 'Anti-Tayloristic'. OTOH claiming a heritage from 'lean
> manufacturing' would suggest that XP is 'Neo-Tayloristic'.
Lean Software Development is anti-Tailoristic. Read the book.
> Sometimes it seems like buzzword compliance - all the Harvard Business
> Review readers have heard how /efficient/ 'lean' can be, so we say
> this is like 'lean' for software.
The Toyota Production System and the Toyota Development System
are based on a number of principles, including the elimination of
waste, which they classify in 7 categories. The Poppendiecks map
this into 7 categories of waste in software development. All you have
to do is take the list of wasteful activities and compare and contrast
the classical software development process ("waterfall" or "plan driven")
with XP using those 7 categories to come to a conclusion.
The rest is academic babble.
John Roth
| |
| Laurent Bossavit 2004-06-03, 7:08 pm |
| John:
> I'm not so sure I care. My view on the situation is that there
> are five identifiable perspectives and value systems in the world,
> of which the two most prevalent are one that values personal
> achievement and hierarchy, and one that values interrelations
> and egalitarianism.
The other three being ?
Laurent
http://bossavit.com/thoughts/
| |
|
| Laurent Bossavit wrote:
>
> The other three being ?
Sex, chocolate, and rock-n-roll.
--
Phlip
| |
| Isaac Gouy 2004-06-03, 7:08 pm |
| "John Roth" <newsgroups@jhrothjr.com> wrote in message news:<10bfarju8nj376@news.supernews.com>...
> I'm not so sure I care.
-snip-
> So to talk about "neo-Taylorism" and "anti-Tailorism" is,
> for me, missing the point. These viewpoints and value systems
> would be there regardless of whether Taylor existed, or whether
> anyone formulated those specific doctrines in that way. They
> are fundamental; Taylor is not.
Seems like quibbling about how to label those viewpoints.
> As far as "neo-Taylorism" is concerned, I think the referenced
> paper makes a cardinal mistake about Japan and Toyota by
> seeing what Japanese manufacturing is like, and then assuming
> that it is what Toyota is doing.
The 'referenced paper' does not make that mistake.
It's quite clear which material is specific to Toyota Motor
Corporation.
-snip-
> The Toyota Production System and the Toyota Development System
> are based on a number of principles, including the elimination of
> waste, which they classify in 7 categories. The Poppendiecks map
> this into 7 categories of waste in software development.
They bend things to fit into 7 categories - does 'task switching'
really correspond to 'transportation' waste?
| |
| John Roth 2004-06-03, 7:08 pm |
|
"Laurent Bossavit" <laurent@dontspambossavit.com> wrote in message
news:MPG.1b21cc9d9ff080d69897ac@news.noos.fr...
> John:
>
>
> The other three being ?
Security, knowledge and survival, in that order of prevalence.
Security tends to be very resistant to change.
John Roth
>
> Laurent
> http://bossavit.com/thoughts/
| |
| John Roth 2004-06-03, 7:08 pm |
|
"Isaac Gouy" <igouy@yahoo.com> wrote in message
news:ce7ef1c8.0405301331.2876dd72@posting.google.com...
> "John Roth" <newsgroups@jhrothjr.com> wrote in message
news:<10bfarju8nj376@news.supernews.com>...
>
> -snip-
>
> Seems like quibbling about how to label those viewpoints.
I disagree, but I don't think we're going to get anywhere
argueing definitions.
[color=darkred]
> They bend things to fit into 7 categories - does 'task switching'
> really correspond to 'transportation' waste?
I tend to agree that those two really don't correspond. Modern
software development really doesn't incur significant costs, either
in time or in money, from moving development artifacts around.
Manufacturing, however, does incur significant costs from moving
chunks of matter around.
On the other hand, would you say that "task switching" in the
sense of frequent, time wasting interruptions is not wasteful?
It certainly seems to be a valid category to me; it's less important
that one has a one to one map of manufacturing waste to
development waste.
I should also point out that there's a bit of selection in the
manufacturing side as well - lean experts pursue rapid machine
tool setup as a necessary part of reducing down time when you
use small batches. That doesn't seem to be in the list anywhere,
but it does seem to be a fairly basic strategy.
The whole notion of "7 categories" doesn't seem to me to be
all that fundamental. It's simply a useful cutoff to avoid stupefying
your audience by listing dozens and dozens of factors. You could
just as easily produce a top ten list. It might be enlightening to see
what other things people would put on that list, and their justifications.
John Roth
| |
| Laurent Bossavit 2004-06-03, 7:08 pm |
| John:
>
> Security, knowledge and survival, in that order of prevalence.
> Security tends to be very resistant to change.
Just quibbling, but it seems to me that you have identified seven
distinct values, not five value systems: personal achievement,
hierarchy, interrelations, egalitarianism, security, knowledge,
survival. Of the previous seven I value all but hierarchy.
Laurent
http://bossavit.com/thoughts/
|
|
|
|
|