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 ]
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”!
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.
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]
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?
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:
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!):
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!
Here are 4 Posts on “Agreements : Charter” found recently:
It hs been a few days.
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.
This may work out, if people want to contribute to the site structure and functionality. It’s difficult todo with a team, so it’s entirely likely I’ll have to build this out FIRST, then bring people on board to makeit better.
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.
I’ve seen two terms that sort of work form how I want AgileAgreements to function, “karma system” or “credit system” come readily to mind.
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
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.”
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!
Because of your considerable
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!
so my spaminator can only get rid of the wankers. This would be very helpful!
All the Best,
Regina Mullen
