Re: Back to one's roots

I need to hear more of your ideas on the things you mention. I'm not
getting enough of your vision yet. Some comments and questions below, to
keep the flow, um, flowing.

On Wednesday, January 22, 2003, at 8:39:20 AM, Bill Tozier wrote:

> In making a firm more agile, it seems to me that you can choose to 
> address a lot of different aspects of the business process, which I've 
> broadly categorized into: technological solutions (networks, "smarter" 
> machines on the factory floor, &c), infrastructure solutions (formal 
> processes, better forecasting, knowledgebases, and other operations 
> stuff like that there), and cultural solutions (changing the social 
> network, changing the workplace layout, eliminating silos, formal 
> communication channels and barriers, &c).

Yes. Most everything in one of these classifications partakes of the
others, it seems to me. I would imagine that we agree on that.

> For agile manufacturing, the focus of ongoing R&D is firmly entrenched 
> in the tech and infrastructure categories, with very little mention 
> ever made of the cultural side. Walk down the hall at a Big Three or 
> European car manufacturer's research facility, and you'll see a lot of 
> "rapidly reconfigurable tooling rigs" and "networked agent-based 
> market-directed factory layouts." (the case is qualitatively different 
> in Japan, but I won't be going into that here ;-)

Well, in the few situations I have contact with, there are cultural
attempts as well. RAD teams, multi-disciplinary task forces, and the like.
That these rarely work does not deny that there is attention paid.

I suspect that MFG companies of interest are mostly large, with a high
investment in capital, and often a long history of doing it in "our way".
They may be almost literally blind to cultural changes other than of a
certain kind. They may be quite emotionally dedicated to command and
control.

> On the other hand, agile software development R&D is focused on 
> infrastructure and culture, and right this second I confess I can't 
> think of a single author who has suggested a technological "gadgety" 
> approach to software agility that has become popular (anybody?).

I can't either. Of course I have historically crushed any such efforts to
the best of my ability, so perhaps people are keeping their heads down.

Seriously, there are efforts. Refactoring tools are perhaps the most
visible. Collaboration software permitting remote pairing are in the works.
People keep trying requirements and story management software over my
curmudgeonly objections that cards are better.

  (Relatedly, see my forthcoming paper on the use of the bark of certain
  trees, cut to appropriate sizes, to avoid the overly technical paper
  cards that people persist in using. There is also this trick where you
  mark in wet clay and then allow the sun to harden it, but that's still in
  research stages. Early results suggest that the technique is
  insufficiently agile.)

Overall, however, you're surely right: agile software focuses much more on
the people side. Even most of the infrastructural things you mention are
usually considered secondary by the agilites. Agilions. Whatever.

> I confess that I'd like to see more cross-talk between the agile 
> manufacturing and agile software development efforts. Or an explanation 
> of why there shouldn't be. It strikes me that there are more than 
> analogies and metaphors linking them: there is a kernel of business 
> strategy that can be shared both ways.

Almost certainly true. Yet there are some fundamentals at work. Software is
more like a drawing of a car than it is like a car. The dynamics of change
in the medium of software and that of manufacturing may be so different as
to result in a very different proper balancing of the forces toward
agility.

> So to summarize, we have:
> - the same simple business case for adaptability in manufacturing and 
> software
> - very different perceptions of the need in those two aspects of 
> business
> - very different focus in R&D supporting agility in those two aspects 
> of business

> What's driving the split?

It might be what Glen calls the "domain". It really is easier to refactor a
program, or a programming team, than a machine or an assembly line.

The low hanging fruit may be on different trees entirely. Still, I'd hope
for more commonality than has been found so far.

> Might it be a good thing to reunite these efforts?

Sure might. I'm for it. The analogies alone are probably worth it.

> Might it benefit the promotion of XP to re-emphasize the link to agile 
> manufacturing?

It might well. Most of us are using the link informally already. Why do we
want to promote XP?

Ron Jeffries
www.XProgramming.com
Inigo Montoya: You are wonderful!
Man in Black: Thank you. I have worked hard to become so.


To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/