Read this excellent post of Jesse Fewelll, a leader of the PMI-Agile Community of Practice. In the article, he discusses a presentation by Don Johnson, entitled “IT Acquisition Centered on Agile Processes.”

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 ]

This article from mid-2008 describes the kind of contract that has great potential in supporting Agile teams that provide services to federal government agencies:

“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 ]

Part of the objective in musing out loud on con struction of AgileAgreements.org is to encourage people who might be shy to come on in and help get ‘er done!

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.

You are invited to a conversation about “Agile Agreements.org” in the form of a Project Advisory Panel.

#WOOHOO! …EH…WHAT IS IT?!

Vision: an interactive repository and community around the question of how to draft and negotiate legal contracts for Agile (iterative deliverables, emerging requirements, etc) projects.

#WOOHOO! …BUT, I MEANT ‘WHAT IS THE PANEL GOING TO DO’?!

The panel is going to help me make this a killer resource for the rest of the Agile community.

They will suggest places to grab content, submit content of their own, snark, praise, bury, do whatever it takes to make this thing work.

#WOOHOO! …DO PANEL MEMBERS GET FREE 125×125 BANNERS?

Who told you? Why, yes! Yes, they do.

Well have to figure out The Threshold for people who contribute content, but basically, people who contribute a lot, get to advertise for free.

They won’t be co-owners, because this is a Dialexica project, but, it WILL be creative commons-y, so that anyone who wants to build an API is welcome to do so once we’re rolling, so that the content is more fully accessible!

Executive decision : free banners include non-profit Agile organizations. Yeah, it’s like that.

Simple, like dot org sunshine!

#WOOHOO! …SO, WHERE’S THE MONEY?!

T’ain’t none. Think Twitter without the valuation. But, with lots of inherent value.

My company is the first sponsor, so my 125×125 logo will always be visible.

Like the voodoo that I do? Then, by all means hire my company for something…But, not for this.

If you just feel dirty using such a great resource without paying $10 or a pound, yen, ruble, peso or pfennig, then buy swag when the store goes live.

#JUST SOFTWARE?

Thank you for asking!

No, this effort is not limited to software development, although the most likely early content will focus there.

Think any project where deliverables are created iteratively, requirements emerge over time,–or your clients make you NUTS with change orders that could have been prevented.

No way is this site pushing religion OR putting one Agile aspect over another, but by way of example, The Sutherlands and James Higginbotham are already applying Agile to church, and The Starrs apply Agile to family dynamics, –so use your imagination!

#WHY YOU?

You found this site, but still need to ask…Hmmmm! OK, I’ll bite!

Because of your considerable

• expertise and commitment to the Agile community
• interest and/or expertise in the drafting, negotiating or implementation of Agile process contracts.

Regina Mullen cordially invites you to participate on the AgileAgreements.org Project Advisory Panel!

We definitely need you, if you suspect that you might be one of the 50 or so Agile and legal folks who will find a creepy level of fulfillment through an occasional “5 minute conversation” via mailing list.

If you’re in denial, or just have one-off type suggestions, feel free to send a note or forward this on. Pocket protectors welcome here!

Keep it clean and respectful, because the revolution WILL be televised.

#NOOOO! Not WHY ME, WHY YOU?

Oh. I thought you were having a Nancy Kerrigan moment. Sorry ’bout that!

Why me?

Because I’ve been gestating this type of project over in my head since working in Japan (1991-1993). It has germinated long enough and I need to get it out and lose some psychic weight.

Shut up about the implied parenthesis!

Anyway, back in 1991, I was negotiating software contract, employment agreements, wrangling with IP pirates, trying to make workable agreements for my firm’s Japanese clients, so they’d never have to see another American lawyer.

Unless they really, really wanted to.

Like any good horder, I put scores of contract provisions on my craptop (aka “The Brick”) to avoid having to lug the huge Japanese contract provision book around.

Given that Windows hadn’t been shipped to Japan yet, you won’t be surprised to learn that I didn’t have the vocabulary for conceptualizing this project back then.

Worse, I lost 2 years of work because the Japanese OS we used had no time of day for English DOS or Windows, and I wasn’t about to buy an unserviceable Japanese laptop OR print everything out.

#DO YOU NOW?

Oh yes! Thank you for asking!

But, more importantly, YOU have thevocabulary and the smarts and the drive to make this thing work.

#SUCCESS TEST

If I am successful in *my* work (and I intend to be!) the Agile community will soon include a LOT of lawyers and legal professionals who are committed to providing better service in their own professional practice through implementation of Agile technologies (methods, practices, principles, processes, patterns, etc).

If I am VERY successful in *my* work, the lawyers who join the Agile community will be really fun folks with lots of wisdom to contribute and we will learn a lot together.

#WHAT DOES ‘FAIL’ LOOK LIKE?

Puppies and kittens lined up at a methadone clinic, with unicorns in raincoats across the street trying to sell them pictures of  “Waterfall Week” and pin-ups of monkeys looking at blue screens of death.

It ain’t pretty. Do not take us there.

#FEED ME BACK!

I know you’re busy, so this note is just to find out whether you’re interested. Send an email with one of these in the header. Easy peasy: just click one!

• INTERESTED
• NOT INTERESTED
• HIT ME UP AGAIN WHEN IT”S LIVE
• LET ME LURK…HEH, HEH, HEH!

so my spaminator can only get rid of the wankers. This would be very helpful!

All the Best,

Regina Mullen

I’m glad you found this blog!

It’s dusty, possibly quite ugly and full of unopened boxes, but the site should be rolling along smoothly in a few weeks.

This post will briefly describe the categories, which correspond to those in use at the Agile Agreements site, and explain why they appear to make sense. Commentary is very, very welcome and if you can help build a better mousetrap, please let me know!

Further, community is exceedingly important, so suggestions on how to do this better as a whole are also welcome. No guarantee it’ll get done, but there is NO harm in asking!

The paradigm that I believe works for agile contracts was strongly suggested by Thorup & Jensen as one that focuses on values and trust, rather than rights and obligations. I would add, in addition to my 5 takeaways, that the objective of an Agile contract is that it is neither put in the cabinet never to be seen again nor a manifesto used to beat down the other party in the case of conflict.

Rather, it is a living, breathing working document that retains flexibility while at the same time fixing the commitments and values each party brings to the bargaining table.

Nothing here or published at Agile Agreements.com is to be taken s legal advice, and please recognize that parties to a contract are always expected to do appropriate due diligence and bargain in their own self-interest.

Categories in no particular order:

Sempai

Who can you turn to for big brotherly or sisterly advice? This category is for people who are good resources for informal Q & A coaching. We all need just one more Japanese term, and this one means “one who has gone before you on the path.”

Values

“This contract needs to be agile because it makes me feel good.” But why?

Risk

When does risk pass? These are key questions lawyers ask when drafting contracts. iterative contracts may make it easier to talk about that,–lets work on it!

Resources

Cash, bodies, time all of these are brought to the table. It’s not just about price.

Scope

How big is it? How does scope,–and scope change work in the agile environment? Do you need a kanban or kaizen kicker?

Vision

What is the shared vision that causes the parties to negotiate an agreement? How can that vision be protected in the event of disagreement?

Objectives

What do you hope to achieve? It’s rarely just “we want to get paid for work done.” Dig a little deeper!

Parties & Roles

Who is involved and what is the knock-on effect of this agreement?

Methods

Agile, lean, kanban, scrum…which agreements around methodology makes sense?

Experts

Celebrating all who can make contracts more agile. No ads, information.

Strategy

Fixed price, fixed scope, time-limited, requirements, test…