Jump to content

Is Performance-Based Acquisition Compatible With Agile Principles?


Recommended Posts

The following is an excerpt from the Agile Contracts Primer regarding "Quality Management Plans" and "deliverables lists."

Quote

Traditional contracted outsourced work involves low levels of transparency and trust, and a long delay until some software is done. One (of many) classic contract-responses to this is to mandate a conventional “quality management plan” or “deliverables list” that defines a long checklist of documentation to provide, rather than a focus on delivering real value: working software. One negotiator shared with us the following story:

An agilist involved in contract negotiation needs to be skeptical about extra documentation, and argue for measuring the cost of producing it—but of course be willing to discuss why an organization may require something. My experience [with deliverables lists] has varied, including in the worst case a very long negotiation with a company that had a huge internal chasm between the agile-friendly business people and traditional internal IT. The internal IT group had been “thrown a bone” by the business person who was the primary negotiator with us, by IT gaining agreement that a “Quality Management Plan” would be agreed to. The IT representative tried to reinstitute waterfall thinking and documentation, and traditional command-and-control, through various drafts of the ‘quality’ plan. Fortunately, we finally succeeded in effectively eliminating both the quality plan and the authoritarian non-value producing “quality manager” role that the IT representative was trying to build for himself.

What obviates the (assumed) need for a deliverables list, if anything? In Scrum, it is the Definition of Done that the supplier teams and client-side business-area Product Owner—rather than an IT manager or legal professional—define and evolve each iteration. Contract lawyers need to understand the Definition of Done because it changes how agile contacts are framed, and how projects are done. In short, the Scrum Definition of Done defines the “doneness” of the product increment each iteration in terms of activities and artifacts, and should be such that the product is potentially usable or shippable each iteration. For example, a Definition of Done for a particular product for a particular iteration includes “coded, integrated, functional/performance/usability tested, documented.” (An actual definition is longer, with more detail and less ambiguity.) To reiterate, “done” is redefined by the supplier and customer at the start of each iteration, and it will adaptively evolve as both parties learn what is truly valuable.

Assuming the author's representation of Agile development is correct, acceptance criteria is dynamic--it changes from iteration to iteration based on user feedback. "Quality Management Plans" are relatively useless.

Performance-based acquisition requires planned acceptance criteria ("measurable performance standards") that are comparatively static. The quality assurance surveillance plan is useful in managing contract performance.

It seems that performance-based acquisition is incongruous with, if not antithetical to, Agile principles. 

What's your opinion?

Link to comment
Share on other sites

Agreed.  Agile is not performance based according to the governments definition.  But Agile can use performance based incentives to motivate and reward exceptional performance.  For example a contractor can earn additional work based upon exceeding standards for velocity, satisfaction, features delivered, burn down, defects, etc. This approach can work well with multiple awards and the best performers in terms of these type criteria get more work.

Link to comment
Share on other sites

That may be possible, but is it wise? From the same source I cited before:

Quote

 

Avoid…Incentives and penalties

It is common for those involved in contracts (legal professionals, sales people, procurement agents, …) to spend considerable time inventing, negotiating, and writing incentive and penalty clauses in contracts. There is an unquestioned assumption and belief that incentives (related to performance or target dates) or bonuses are beneficial. However, this is inconsistent with evidence-based management research [PS06, Austin96, Kohn93, Herzberg87], and there is ample evidence incentives lead to increased gaming, a reduction in transparency and quality, and other dysfunctions. Research was summarized in the Organization chapter of our book Scaling Lean & Agile Development.

Penalties (negative incentives) lead to the same problems. 

Incentives and penalties also foster a competitive us-them relationship between customers and suppliers, rather than cooperation.

Alternatives?

- simplicity—no performance-based incentives or penalties

- if the customer is extremely dissatisfied with performance, terminate the engagement at the end of iteration

- shared pain/gain models

 

I'd be interested in nonanecdotal evidence that performance-based incentives or penalties in Federal contracts have a positive effect on agile software development. 

Link to comment
Share on other sites

I’ve been involved on and off with Agile for ten years.   I’ve seen lots of incentives used but don’t have any proof that incentives contributed in either a positive or negative way to performance.  But I do remember in a couple instances companies didn’t transfer some of their best developers to other projects out of fear performance might drop and they lose work. 

Link to comment
Share on other sites

5 hours ago, Don Mansfield said:

The following is an excerpt from the Agile Contracts Primer regarding "Quality Management Plans" and "deliverables lists."

Assuming the author's representation of Agile development is correct, acceptance criteria is dynamic--it changes from iteration to iteration based on user feedback. "Quality Management Plans" are relatively useless.

Performance-based acquisition requires planned acceptance criteria ("measurable performance standards") that are comparatively static. The quality assurance surveillance plan is useful in managing contract performance.

It seems that performance-based acquisition is incongruous with, if not antithetical to, Agile principles. 

What's your opinion?

Now it could be that I do not understand yet here is my opinion.

I believe it depends, with no apologies in using a phrase often used in Federal government contracting.  Depends on what?   The practice of PBSC (or whatever you want to call it) as put forth in the original concept.

As practiced the "comparatively static" is the reality.  But by my read and specific experience in one case the mantra of performance based was actually instituted to be agile.  The mantra as taken from the "7 Steps to Performance Based Service Acquisition" which provides this in part, and I quote, "Include contractual language for negotiated changes to the metrics and measures."  There is further language that plays off of this ideal.  By experience in a large IT infrastructure operation and maintenance contract the agency (me as the CO) did just that.  The contractors selected team and the governments selected team met quarterly, looked at performance, what was being measured, etc. and went through several iterations of changing the measurement metrics and the performance metrics of the contract.  Lots of commitment of all kinds but I felt it worked.

https://www.dau.edu/cop/pm/DAU Sponsored Documents/Seven Steps to Performance Based Acquistion.pdf 

Link to comment
Share on other sites

Quote

“We are not as endlessly manipulatable and predictable as you would think.”

“Once a task called for even rudimentary cognitive skill a larger reward led to poorer performance.”

“The best use of money as a motivator is to pay people enough to take the issue of money off the table.”

3 factors lead to better performance: autonomy, mastery and purpose

“When the profit motive becomes unmoored from the purpose motive, bad things happen.”

“If we start treating people like people… get past this ideology of idea of carrots and sticks and look at the science we can actually build organization and work lives that make us better off, but I also think they have the promise to make our world just a little bit better.”

That's from The W. Edwards Deming Institute, "What really motivates us?" Emphasis added. https://deming.org/what-really-motivates-us/

For those who don't know, Demings was the man behind the application of statistics to quality assurance and continuous process improvement. He was instrumental in helping Japan develop its skill in and devotion to quality and innovation. https://en.wikipedia.org/wiki/W._Edwards_Deming

I have read extensively on incentives in contracting. I do not believe they work. I have seen no persuasive evidence that they work, and neither have those who have researched their use. I think they are just gimmicks.

Link to comment
Share on other sites

My comments above on incentives were in response to Don’s interest on contracts for Agile software.   

I do think incentives can work in general but not for the obvious reasons.  Properly done and assessing the right things, incentives forces interest, measurement, analysis, and communication.  It raises questions about what can be done differently to improve.  But this is all antidotal and there’s no data to really support my statement.  

Link to comment
Share on other sites

I was in LA in the mid-90's when an earthquake destroyed a vital freeway overpass. (Yes, all freeway overpasses in LA are vital, but this one was very vital.) It was rebuilt in 65 days. Here's an article on the subject from some group called the Economic Policy Institute.

Quote

We were rebuilding the roads and bridges within 24 hours of the earthquake. I issued an executive order suspending all statutes and regulations related to state contracting.…My goal was to reopen I-10 within 6 months, and every other road within a year. Each contract included an incentive if the work was late, we charged a fine and if it was completed early, we paid a bonus and the motorists in Los Angeles were happy each time we did. We waived the requirements for lengthy environmental and permitting reviews for strict replacement work cutting 18 to 24 months off the construction schedule.

I cut the rules impeding recovery in other areas as well: Suspended several trucking rules…suspended overtime rules to give employers more flexibility in setting work schedules and reducing congestion during normal commute hours… expedited permitting of reconstruction projects by waiving many of the procedural requirements, and putting staff from all state and local permitting agencies into one building

Another quote from the LA Times (April 1994):

Quote

Spurred by the promise of an extra $200,000 a day for every day work was completed ahead of schedule, the contractor, C. C. Myers Inc., will finish the project 74 days before a June 24 deadline and rack up a $14.5-million bonus for the company.

The high-speed construction was made possible by crews working around the clock, seven days a week, and by state officials cutting through red tape.

As I recall, the company received its multi-million dollar bonus and the workers got a pizza party. The taxpayers got their freeways back ahead of schedule. It was a win-win-win!

But I hope you'll notice that it was not solely the incentives and/or disincentives that led to the extraordinary result. It was the partnership between the multiple government agencies and the contractor. Everybody from the top down was focused on getting the project done. Red tape was waived. Months were cut off from the project's schedule because of the waivers.

If the Federal government wants similar extraordinary results, I assert it needs to start with the notion of partnership, with the notion of a mutuality of interest in the contractual outcome. The notion that the parties must be separated by an arms-length is fatal. 

Link to comment
Share on other sites

On 5/28/2021 at 4:24 PM, here_2_help said:

If the Federal government wants similar extraordinary results, I assert it needs to start with the notion of partnership, with the notion of a mutuality of interest in the contractual outcome. The notion that the parties must be separated by an arms-length is fatal. 

Amen! AMEN!

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...