RE: [epf-dev] Some comments on the OpenUP collaborative practices fortom

["Steve Adolph" <steve@xxxxxxxxxxxxxxxxx>]

Jim

 

Good point. We will have to ensure this aspect of collaboration is dealt with in the white papers that will accompany OpenUP.

 

Best regards,

Steve

 

---

From: Jim Ruehlin [mailto:jruehlin@xxxxxxxxxx]
Sent: Thursday, May 25, 2006 3:43 PM
To: steve@xxxxxxxxxxxxxxxxx; epf-dev@xxxxxxxxxxx
Subject: RE: [epf-dev] Some comments on the OpenUP collaborative practices fortomorrow's telecon

 

One thing it seems like we haven’t explained is the advantages of collaboration over other management practices (directing, ordering, following prescriptions, etc). A lot of people are talking about collaboration, but it’s a lot of work. Why should people go through the effort?

 

Here’re some motivators to think about:

• Collaboration focuses on solving a problem rather than “doing some work” or pursuing personal agendas
• More potential solutions are investigated
• Errors are revealed and addressed early instead of being hidden or ignored
• Responsibility is shared so issues are addressed rather than waiting for someone else to solve them
• Communication bottlenecks are reduced
• Teams become self motivated and self regulating rather than needing to be pushed by management

 

We also want to communicate that collaborative practices are something you do rather than something you get after being collaborative. I’m concerned we may give the impression that a customer can say “OK, now that we’re collaborative we’ve got ourselves a high-trust environment!” What we want is someone saying “I want the advantages of a collaborative environment. I better start building a high-trust environment in my team.”

 

- Jim

 

____________________

Jim Ruehlin, IBM Rational

RUP Content Developer

Eclipse Process Framework (EPF) Committer

email:   jruehlin@xxxxxxxxxx

phone:  760.505.3232

fax:      949.369.0720

 

---

From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of "Steve Adolph" <steve@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 25, 2006 11:24 AM
To: <epf-dev@xxxxxxxxxxx>
Subject: [epf-dev] Some comments on the OpenUP collaborative practices for tomorrow's telecon

 

Hello everyone

 

Just some thoughts regarding our collaborative practices…..

 

In general I would like to keep the number of practices to a minimum, about 5 to 6 per area – that still leaves us with 20 to 24 practices. Ouch! You can just imagine the fun some of the agile fundamentalists will have with that!

 

Collaborate:

 

Previous Practices:	Practices Today	Comment
Share the Dream		- became an architectural practice as part of focus.
Tear Down the Walls	Create a high trust environment	- I’m not sure I like the name for this practice. The previous name “Tear down the walls” stated what action we must take to build trust.
Manage by Intent	Manage By Intent
Buddy Up	Buddy Up
Confession is Good for the Soul		I forget, where did we put retrospectives?
Continuous Learning	Continuous Learning
	Organize Around the Architecture	I really like this as a collaborative practice. Because it  highlights the importance and role of architecture and distinguishes OpenUP from other Agile processes.
	Follow Standards	Important, but is it important enough to be a practice?
	Manage Versions	Really hard to argue as a collaborative practice.
	Everyone Owns the Product
	Take responsibility for your work.
		Take Ownership may be a good name for a practice that covers both Everyone owns the product and Take responsibility for your work.

 

 

From the above may I suggest we have the following collaborative practices….

1. Create a high trust environment
2. Manage by intent
3. Buddy up
4. Continuous Learning
5. Organize around the architecture
6. Take ownership (?)
7. Reflect (?) – was confession is good for the soul – could be absorbed into continuous learning – after all we learn from reflection right?

 

If I were to try and shorten this list, then this is what I would come up with for the collaborative principles:

1. Create a high trust environment
2. Manage by intent
3. Buddy up
4. Continuous Learning
5. Organize around the architecture

 

A different variation of this may be:

1. Create a high trust environment
2. Manage by intent
3. Skill
4. Continuous Learning
5. Organize around the architecture

 

In this list I have replaced buddy up with Skill. The issue of skill contributes to trust in that we have respect and trust in our colleague’s skills. We could cover buddy up in Create a High Trust Environment (in a high trust environment we do not leave our people behind).

 

 

Best regards,

Steve

_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev