In normal English, that means the United States is working on a law to reform procurement from the cold-war big-bang approach to an iterative incremental approach…Furthermore, the DSB has a relationship with the council of Federal CIOs, allowing the new procurement approach to be socialized among officials from all parts of the entire United States government.

Jesse identifies a team of 4 Agile Project Leadership network (APLN) DC [ link ] leaders working to create Agility in government procurement. There are some excellent materials on the APLN DC website, so go take a look!

I look forward to bringing samples of contracts that come out of this process! While the focus is on IT, it won’t take long before other procurement agencies and departments catch on.

Who are the legal, business and IT minds involved in drafting these agreements?

[Thanks to @MCottmeyer for RT @darylkulak ]

“The real philosophy behind this is the government was driving up the price of work by mandating that people do it in a certain way, when, in fact, [contractors] may have known a better way to get it done,” says Jon Desenberg of the Washington-based Performance Institute, a think tank dedicated to improving government performance. The idea “is to let the contracted group come up with the best possible solution and only pay them based on solving the problem . . . not on the individual steps and minutia that we have for so many years required.”

Apparently, this program was begun under Bush II and it’s not all rosy, but there’s lot’s of food for thought here. Since there are now several years of history, here’s hoping that a report has been issued. Will try to find.

It’s interesting, but not surprising, that contractors themselves are foot-dragging. Anyone using language of “nailing jello to a tree” is clearly NOT of an Agile mindset. Agilists love jello! We must know it has a better use than being nailed to plants!

“I think small and midtier businesses would see it as a great opportunity to be innovative, to propose and generate innovation rather than be contained in a predesigned box,” he says. “It gives them an opportunity to demonstrate agility.” Soloway says such companies should carefully assess risks before entering into performance-based contracts.

Source : NextGov Blog [ link ]

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“).

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]

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:

• Project Charter – Agile Project
• Conveying Agile Processes Concisely to Clients
• Team Charters
• Meeting Acceptance Criteria Implies Customer Satisfaction

Tonight, spent a little while collecting resources.

One resource which deserves particular note is the InfoQ Working Group page. It has a great collection and can now be considered as related site to this one (although there is no formal connection), because our objectives are the same.

The main difference is that this site (Agile Agreements) is not limited to software development. To begin, all of our links are related to software, but I expect to have construction contracts as well. many of these already bear the hallmarks of “agility” because of the way contractors and subcontractors must work to, for example, wire and office building. There are resources in the “library” for this, thanks to the Turner School, in which I participated in…2006.

Found a tool which ought to help called BananaScrum. It’s pretty much what I was looking for, in that it’s a straight forward user story-based scrum tool that auto-generates a burn-down chart.

We’ll see how far we get in terms of commentary on user stories, now that I’ve found a commenting/rating script that can run through WordPress as well.

Still some work to do.

The idea for Agile Agreements is that the more an advertiser contributes, the more meaningful it is to the community.

It is a matter of integrity to keep this site open for access while encouraging significant contribution ONLY by advertisers who have a vested interest in the subject area.

So, how to build that in fairly in a way that does NOT have to be monitored manually? Enter the “barter algorithm”!

The idea is that AgileAgreements.org will function for ADVERTISERS as a pure barter system. There is no “credit” or “debt” involved: advertisers get increased exposure either by contributing content or by adding functionality.

Points are relative

Content can be anything from actual contract provisions to interesting commentary and non-spam reference links. I think this is the right hierarchy, but, of course, the priorities might change over time.

To start, the levels will look something like

• User story-level functionality : 50 points
• Task-level functionality : 25 points
• Complete contract with commentary : 10 points
• Complete contract: 8 points
• Contract provision with commentary: 6 points
• Contract provision : 4 points
• Useful commentary : 2 points
• Useful link : 1 point

I think they should roll-over monthly, don’t you? Maybe wipe the slate clean every year? Something like that.

This makes me think that the site can be up and running fairly quickly using an open source content management system. So, this afternoon I will pull something off the shelf and see how it looks on a demo site.

The trick is going to be to aggregate points among people who belong to the same firm.

Any suggestions are welcome.

Oh, and here’s a recent article where Bob Schatz explains about software requirements as “commitments.”

So, this post is about how I plan to handle writing use cases for this site.

To be honest, the V1 of this site is going to be VERY simple. My goal is to run the data collection and display off of existing open source software. Once content is in the database, we can play all sorts of reindeer games.

V2, therefore, will probably get gnarly, because the idea is to build out all sorts of cool ways to slice the data that gets input by the community on V1. If I can find a vendor willing to DONATE space to do the development planning, we’ll move to that platform. But, for now, I’m going to spend a few minutes re-working an index card graphic for and then upload my note cards for comment.

Of course, use cases are widely used outside of Scrum, but over the years, I realized that my learning mode requires a bit of human contact in a well-defined context. Since most books that spoke to this issue confused me, there wasn’t much point trying to rely upon an afternoon in Borders to answer my questions,–because I didn’t understand the context.

So, I attended the Certified Scrum Product Owner® training given by Mike Cohn to learn how to do this, and hope that the ideas put forward inspire enough people that I can stop generating code and simply come up with ideas (which is what I do best).

Yeah, I know: I just noticed the IP symbol!

So, the model is simple:

“As a { user role/name/type }
I want to { objective }
so that I can { value/benefit }.”

Note the period at the end. Whatever it is, it needs to be able to fit within this context. Everything else goes somewhere else.

Priorities

Were this site being developed by a well-oiled Scrum team, I would probably give them a 2-week sprint with little more guidance than: “My priority order is: add, view, edit, share, integrate, re-engineer.

So, as an admin, I want to be able to add editorial content and see it when I go to the live website. Then, I want other people to be able to comment, then I want them to be able to add editorial content themselves. Then, let’s prettify it so that people are delighted while using it.”

Add: content [user info, system info, editorial content] has to get into the system securely. Which means we need a database and data.
View: added content has to be visible. Which means connectivity between the database and the user interface.
Edit: viewable content has to be correctable. Which means administrative tools to ensure things work correctly
Share: viewable content wants to be free. Which means social networking, printables, copy/paste, etc.
Integrate: hidden content [unapparent connections, API data] needs to be brought forward. Which means finding ways tack hidden content to viewable content
Re-engineer: rinse and repeat.

Since Scrum allows me to do a little bit more every 2 weeks, I would give them my cell number and go do something else, leaving them with the question “Do you think we can get the functionality needed for V1 by refactoring {WordPress}?” and any inconsistencies that might arise from the brief prioritization attempt above.