James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131467409/ref=jranch-20" target="_blank" rel="nofollow">"Organizational Patterns of Agile Software Development"</a>
Originally posted by Neil B. Harrison:
Let me add a bit. Cope and I have studied the dynamics of software organizations for over ten years, and we have found many fundamental characteristics of highely successful organizations. We have written these characterstics as a pattern language (actually four pattern languages). That is what you find in the book. You can apply these at many levels in an organization, depending on your particular role in the organization, to improve your organization's effectiveness.
[ May 04, 2005: Message edited by: Neil B. Harrison ]
Kishore
SCJP, blog
Originally posted by Kishore Dandu:
Are u indirectly implying that successful organizations are using agile approaches to create successful projects(unintentionally). But my thinking was, we have agile nominclature that came to prominence only recently. But I did observe many successful projects that employed RUP or waterfall in some cases and not necessarily agile.
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131467409/ref=jranch-20" target="_blank" rel="nofollow">"Organizational Patterns of Agile Software Development"</a>
Originally posted by Kishore Dandu:
Are u indirectly implying that successful organizations are using agile approaches to create successful projects(unintentionally). But my thinking was, we have agile nominclature that came to prominence only recently. But I did observe many successful projects that employed RUP or waterfall in some cases and not necessarily agile.
James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Originally posted by James Coplien:
Success" may not be what you think it is. If a project uses waterfall and delivers, I guess it is a success.
Since just about everything can be said to be part of RUP, I am not sure what meaning to ascribe to the statements "RUP works" or "RUP doesn't work." RUP seems to be both everything and nothing at the same time. I'll let someone else take up that point.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Jim Bracks:
Does the book include any detailed case study of some successful project?
James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Originally posted by Alvin chew:
as author view of you , what are the best organization pattern in current day ?
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131467409/ref=jranch-20" target="_blank" rel="nofollow">"Organizational Patterns of Agile Software Development"</a>
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
I think I can imagine what most of them are about. But I'm not sure about
Domain Expertise In Roles
and
Function Owner and Component Owner
James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Originally posted by James Coplien:
Domain Expertise in Roles:
If you need to staff all roles, it's difficult to determine how to match people to roles to optimize communication. Then: match people to roles based on domain expertise, and emphasize that people play those roles in the organization.
Function Owner and Component Owner: If you organize teams by components, functions suffer, and vice versa, Then: Make sure every function has an owner, every component has an owner.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Originally posted by James Coplien:
Your understanding of Function Owner and Component Owner is correct, but is contrary to what I hear from the Extreme High Priests like Kent. To them there is only corporate ownership;
to me, something that is owned by everyone is owned by no one.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
With all due respect, but perhaps that's only true for you because you think it is true?
Seriously, I think that it's possible to build a culture of quality where everyone feels responsible for (and wants to be pride of) the whole system. In fact I think that there are always some team members who have a finer nose for component quality than their coworkers, and I'd rather have them feel responsible for the whole system - and possibly even produce some peer pressure - than having them only care about their own personal niches.
James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Originally posted by Don Stadler:
James, I would like you to expand further on the "Function Owner and Component Owner" and the "Mercenary Analyst" patterns.
Also I wonder whether "Firewalls" means well-defined interfaces bewtween subsystems (as I presume) or something else....
Does "Developer Controls Process" mean flexible agile process where ichdevelopers & designers select the artifacts which are produced. Thus getting away from the straitjacket which CMM seems to impose all too often?
James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Originally posted by James Coplien:
The point is that if no one owns a component, there is no oracle to go to who can either tell what is going on with that component at the time or who can coordinate efforts on that component.
Someone needs to be around to advocate a component's stake in the architecture
And if no one owns a feature, the feature may languish. Someone must advocate the feature and champion the customer interest. If you leave this to everyone, you usually have a lot of opinions that are not grounded with customer contact. If you leave all the features to one person, you eschew the domain expertise necessary to represent the interests of the feature to the architecture and the team.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by James Coplien:
That leads to good feelings and good morale, but it's not conducive to action or to business goals--at least, that's what we found over the ten years of studying stuff like this.
We found a high correlation (no surprise) between corporate ownership cultures and consensus cultures.
The usual failure modes of the first group included analysis paralysis, design paralysis
and most importantly, a lot of "stepping on each others' toes." Tasks became blocked because the synchronization points (the code) weren't owned. Or, worse, they would try to do two things in the same piece of code at the same time, mutually unaware. Pair programming would have been ideal if they had known about each other, but there was no oracle to consult about activity on that piece of code.
So I feel our results are right because we've seen it.
These cultures are rooted in a highly egalitarian value system, and that seems to allow ownership to flow. In Norway (where we worked with several companies including Schlumberger), or in Denmark (Navision, Nykredit, and others) it is not a good thing if you stand out or have any personal hallmark of excellence.
Reflecting on it, the time cost was high relative to ownership cultures, though; they had more meetings, and more meetings of broader scope, than we tended to find in ownership cultures.
Maybe there is something in XP that is reminiscent of the Nordic cultures. I haven't seen anything in XP that screams out for excellence. It's kind of an Animal Farm where all the animals are equal--though the Consultant is a bit more equal than others.
In spite of the fact that the original XP denied the value of either architecture, or ownership, or specialization, or documentation
it is good to know that the "Explained" book took the Code Ownership cue from the pattern language and reversed his earlier position.
Even before that book, we, too, had found that most projects that called themselves "XP" had ownership which was, at the time, contrary to The Dogma.
I had always found the Extreme Priests to be adamant against it.
In fact, it has been interesting to watch XP principles and practices slowly converge on the Organizational Patterns over the years with little or no acknowledgment of the source.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
James O. Coplien<br /> Object Architect, DAFCA, Inc., Framingham, MA<br /> Visiting Professor of School of Informatics, University of Manchester<br /> <a href="http://users.rcn.com/jcoplien/" target="_blank" rel="nofollow">http://users.rcn.com/jcoplien/</a>
Originally posted by James Coplien:
Ilija -- your long response above leaves me, well, speechless :-)
In the interest of Saying the Simplest Thing that could Possibly Work, let me summarize by saying that our broad research over a decade points to the value of ownership.
It doesn't matter as much in simple or general-purpose domains, but it matters in those cases where it matters to have a business edge.
I've come to the conclusion over the past two weeks that XP has finally reached the stage of RUP: it can be anything you want it to be.
What's interesting is that other high-context cultures we've studied, such as the Borland QPW project that, historically, kicked off the entire Agile movement (including XP) also has an obscure trajectory.
I worry a lot about burnout; we have several sections about this in the Organiztional Patterns book. I know XP has an 8-hour day
the pressure of appearing accountable before a group in a morning stand-up meeting puts developers in a posture where they carry the work home in their head.
Pair programming means that there's always a (implicitly, "big") brother looking over their shoulder.
We need more empirical work in this area, more substantiation of what does and does not work. The rest is just flapping our gums.
However, I am always skeptical of classroom experiments
The clients later let me know that the results were counterindicative to the value pair programming.
I've worked with military projects on three continents and can believe it works there, in a high-context culture where discipline is handed out in bottles the first day you arrive on the job.
Software development is a collection of largely undisciplined cultures
(The organizational pattern work is the only study I know of that looked at software process over a period of longer than a year, and we took ten years.)
The results of these studies will vary radically from culture to culture, organiztaion to organization, and product to product. Don't believe what's in the books. Unlike books written by most consultants, the bottom line of patterns isn't to give you a method to follow, but to open you up to the opportunities provided by your own instinct.
Do we want to cater to market forces and do the simplest thing that people would put down money for so we could get rich, or do we take up the moral imperative to make the world a better place?
I rejoice at the opportunity to bump ideas up against Ilija
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
James Coplein wrote: "I've come to the conclusion over the past two weeks that XP has finally reached the stage of RUP: it can be anything you want it to be."
Ilja: What exactly is bothering you about this? (Not that I fully agree, but let's put that aside for now.)
Originally posted by Don Stadler:
I cannot speak for James, Ilja, but I've worked at several projects which purported to follow RUP. Most of them were thin wrappers on some other process - often waterfall or at best COCOMO (waterfall with iterative wrapper). Some time in bars with some Rational people convinced me that the intent of RUP is rather more agile than that. What I saw in those projects was a degenerative case. But the degenerative case seems to be the norm with RUP.
I suspect James was making the same point about xP, that he suspects something like that is happening with projects purporting to be xP.
But if 9 out of 10 xP projects are actually a degenerative form of xP, that is what people will identify as xP.
I think real xP can be very good - but a degenerate form of xP can easily turn into a tyranny when run by a control freak. SCRUM can turn into a regular morning inquisition rather than the brief informational meeting it is intended for.
I can't guarantee that my PM won't be a power-drunk sadist, so unless I knew them very well beforehand I would tend to be suspicious of doing xP/SCRUM with a manager I didn't know. Because SCRUM strips away all you're defenses - and that can be taken advantage of.
Another thing to consider. I suspect that you're primo inter pares (first among equals) in your team.
The viewpoint of how well a methodology is working can vary a great deal between team leaders and the foot soldiers. If you have true workplace freedom or democracy they are probably Ok with it. But if you don't they may not tell you about it. How is your turnover rate - that can be a strong indicator of discontent?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
which opens a conversation instead of ending one.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Agreed. Again, I think this is more a matter of a different value system than a matter of doing all the practices.
Originally posted by Don Stadler:
Perhaps one lesson to take from this is that you have to keep a sharp eye on the values - particularly but noy limited to SCRUM?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Definitely!
On the other hand, values are rather hard to communicate; and it's quite easy to pay lip service to them. That's one of the things the practices of XP are good for: teaching the values of XP and how they actually *can* be put into action.
I guess it doesn't work for everyone... <sigh>
SCJP, SCWCD
Originally posted by Don Stadler:
You need to drive out fear
The manager was out to show that xP was a great thing as quickly as was impossible (though he didn't admit it) so he set the goals impossibly high. That is we had the planning meeting - and he stacked the deck. That led to fear, and the morning 2-hour SCUM (sic) grillings engendered more fear. I was the first to speak out and the first to be fired when upper management went headhunting.
The values we're discussing are important to any project - not only xP. I suspect xP may have some of the best outcomes - if you get the values right. Conversely I think xP can be more of a disaster if you get the values wrong.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Hey! You're stepping on my hand! Help me tiny ad!
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|