»
S
I
D
E
B
A
R
«
Comment Repost: EDENHub Code of Conduct PT2
Dec 4th, 2009 by RMullen

I always feel a little guilty when I have a virulent reaction to something I read and write about on the Internet.

So, I decided to leave a frank comment on the EDENHub blog and hopefully we can get to some level of understanding.

I LOVE any business that’s trying to work in this space, and I don’t operate out of scarcity, so let’s engage!

Hi:

I’m sorry, but I really, really find this… troubling, so I thought I’d engage in the interest of helping me see your intentions more clearly.

My interest is the same as yours, I think: working to create better communication and inter-dependence between “The IT Crowd” and the lawyers who rely on them to get work done.

The difference is that I think, by and large, IT folks don’t need this kind of standard. I’m not at all clear on how this brings business value to the companies that agree to be bound by it,–or what happens when they do not uphold that agreement.

I can see most of the 10 points in a company charter or embodiment of values,–but I strongly suspect that most of the tech folks I know would find it insulting to be presented with this as a code of conduct.

Worse, they would wonder whether their evaluation and compensation were being tied to business requirements over which they have no control.

Of course, I will use this as an example on AgileAgreements (because I think there’s alot to discuss there), but I suspect it’s more of an “anti-pattern” for purposes of an “Agile” IT team.

Totally open to the idea of being wrong, so please help me to “get it”!

My objective is to figure out whether this sort of thing can be reconciled with core Agile principles of self-organization, prioritization, rhythm, empiricism and emergence (“SPREE“).

Introducing : EDENHub’s Information Technology Code of Conduct
Dec 4th, 2009 by RMullen

Information Technology Code of Conduct

1. Put Client’s interests and welfare above his/her own interests and act in ways that bring honor to the IT profession.
2. Provide competent service to Client.
3. Exercise objective professional judgment.
4. Know and obey law, contracts and Client’s policies.
5. Explain matters so Client can make informed decisions.
6. Respect and obey Client’s decisions and instructions.
7. Protect integrity and security of Client’s IT system.
8. Access Client’s IT system only as and to the extent expressly authorized by Client.
9. Keep system information confidential from persons that Client has not expressly authorized for disclosure.
10. Report violations of law, contract, policy or code to Client.

Source: SlackSpace Blog [ link]

The Agreements as Conversations
Dec 4th, 2009 by RMullen

Thanks to R. Dempsey on Twitter (@rdempsey), here’s an excerpt from an excellent article from Silver Stripe Blog discussing Agreement #2: the labor exchange agreement:

As much as thirty years ago, Deming listed as Deadly Disease #3 – Evaluation by performance, merit rating, or annual review of performance

This is because performance evaluation kills cooperation, morale and intrinsic motivation. Individual performance appraisal in particular can kill team cooperation. Why should I share knowledge if it would improve other team members appraisals relative to mine?

Structurally, then, we can begin to categorize AgileAgreement types as follows:

Agreement : Charter
“Why are we here?”
company commitments [ values, mission, incorporation, Quality standards ]
Agreement : Labor
“Who will do the work?”
labor compensation [ W-2, 1099, etc ]
Agreement : Workflow
“How is are organizational units bound together to do the work?”
team and business unit working agreements [ workflow agreements, Scrum, Kanban, Lean ]
Agreement : Partnering
“How does the organization fit within a business network?”
company/firm partnering compensation agreements [ IP exchange, software development, consulting ]
Agreement : Financial
“How does the organization use money?”
financial [ venture capital, insurance, compensation ]

The focus is on commitments that have a significant effect upon a team’s ability to implement Agile principles.

At least in the beginning, there is an intent NOT to categorize agreements with respect to organizational hierarchy or departmental concerns, but rather in such as way that we can identify features of agreements and provisions within agreements (provisions) by impact on an organizations charter (WE’LL REFINE & UPPERCASE THIS CONCEPT LATER!):

  • Vision
  • Values
  • Parties & Roles
  • Objectives
  • Resources
  • Risk
  • Strategies
  • Methods
  • Outcomes

Recently, III remarked that he was not a fan of “scope,” and there is a strong suspicion he’s right. But, we may be able to eke out some meaning, so it is included, –we can always drop it from the list!

Also, you’ll note the inclusion of “Outcomes.” In Agile, we are very concerned with reality and empiricism. Granted, it’s not always possible to get the data we need to support an idea (for example, most IP exchange agreements contain highly proprietary information), but an organization can look at outcomes internally and square them with the public and organizational commitments designed to achieve that outcome.

Lawyers might want to add these aspects to their deal, litigation and contract review checklists.

Just as user stories and persona are used as “invitations to a conversation,” we hope that you will see this blog as a place to discuss the structure of AgileAgreements and contribute when so moved!

4 Posts

Here are 4 Posts on “Agreements : Charter” found recently:

»  Substance: WordPress   »  Style: Ahren Ahimsa