Category: Agile

Money For Nothing: Deliver More Value For Your Client (And You)

These are notes from Jeff Sutherland‘s Agile 2008 presentation “Money For Nothing and Your Change For Free: Agile Contracts“. Jeff summarized his talk in this way:

“The “Money for Nothing” strategy works when customers want fixed price estimates for the entire contract up front. The Agile contract allows termination of the contract early when the value of features drops below an ROI criteria. The contract allows the customer to save 80% of their remaining funds by giving the Agile vendor 20% of the remaining contract value in return driving the margins of an Agile contractor from 15-20% up to 50-80%.”

From Scrum Butt to High Performing Team

Jeff began his presentation by talking about the Nokia Test For Scrum Certification, which Nokia uses to measure their team’s level of agility (see questions and scoring method in slide show below). Jeff had everyone in the room score their own team. I rated ifPeople in general at a 5 out of 10, which is just above the starting average. Anything 8 and under is in the ScrumButt category.

Why is this important? Teams that score high tend to be the high performing teams. They also generate much higher revenues, based on Jeff’s analysis:

  • Great Scrum: 400% revenue increase
  • Good Scrum: 300%
  • Pretty good Scrum: 150% – 200%
  • ScrumButt: 0 – 35%

Jeff also compared agile to waterfall teams, suggesting high performing agile teams can outperform waterfall teams by a 5-6x margin. The problem is, contracts that are time and materials don’t reward high performance. T&M is low risk and low margin, you only get paid for the hours you put in, even when you take far less time than your competitors. Fixed price contracts aren’t any better, with vendors trying to out-discount each other. Many vendors only making money if the project is late and over budget due to change requests and building functionality that users do not want.

Money For Nothing

What if there was incentive for projects to end early? The Money For Nothing clause does this. Here is how it works:

  1. Use standard fixed price contract, with time and materials for changes.
  2. Insert Money For Nothing clause
    1. Only operational if customer follows Scrum rules
    2. Mutually agreed estimates for all work items, otherwise contract reverts to time and materials (thus incentive to agree)
  3. Customer decides when value of continuing project higher than cost to do so.
  4. Supplier allows termination of contract at any time for 20% of remaining contract value.
  5. Supplier assumes risk of late delivery of mutually agreed work.

Change For Free

Next, add incentive for the customer to follow Scrum process, and to be aware of impacts of changes to the release plan by adding a Change For Free clause:

  1. The customer must execute this option by working with the Scrum Team every Sprint.
  2. Failure to do this voids this clause and the contract reverts to time and materials.
  3. Changes are included with these rules
    1. Changes in priorities are free if total contract work is not changed
    2. New features may be added for free at Sprint boundaries if low priority items of equal work are removed from contract
  4. Requirements of customer:
    1. Features are prioritized by business value and implemented in order of maximum value
    2. Users follows project closely and work with the Product Owner to produce a quality Product Backlog

Embedding Scrum Incentive Into Contract: I Like (A Lot)

One of the reasons I went to Jeff’s session is we’ve struggled with some clients to get them engaged with the Scrum process. Yes, we do need to do a better job of explaining the process up front and what is expected of them. Defining roles and responsibilities right into the contract gives them proper visibility. Having incentives for the client to *want* to work in Scrum style increases the likelihood that they happen.

Extreme Data Point: Abandon Projects

Jeff ended the session by proposing that “projects are bad”. You know, the way most of us organize our work around teams. Apparently, this is a feeling shared by some other agilistas and companies, and more information will be published on this topic, hopefully later this year for further discussion.

Why are projects bad? Mostly because of tremendous start up / tear down costs. The new idea is to keep teams together, and have them all working on a continuous stream of work from a shared backlog. Work is then packaged up somehow into deliverables to clients. One way to do this approach is to productize architecture.

Challenges Distributed Agile Teams Face, and Ways to Overcome Them

Notes taken from Agile 2008 sessions on distributed Agile: “What Makes Distributed Agile Projects Succeed (or Fail)?” workshop by Chris Sims and Panel discussion on troubleshooting distributed agile team projects

Things panel found most surprising about distributed Agile (DA)

  • There are people at the other side!
  • DA can work well once the proper process and tools are in place
  • We can learn from teams in other places
  • Agile helps to ease cultural, time burdens through increased communication

What makes DA harder than co-located teams

  • Planning overhead is higher for distributed teams. May need to stretch out length of iterations, to adjust for the additional overhead needed for distributed communication
  • Standup and meetings in general take more time
  • Don’t act like your project is co-located – pay the tax for distribution
    • Executable requirements may help a lot – Fitness tests
    • Mini-specs for user stories – need to communicate more in writing with remote people
    • Use acceptance tests to drive story clarity
    • Have developers review tasks ahead of time to prevent blocking
    • Involve everyone iteration planning

What is most important to succeeding with DA

  • Unanimous: Need to get people together to build relationships, get more collaboration. Plan for at least 2-3 times / year. This also helps to understand cultural differences. Build in the cost of these trips into rates.
  • Leverage technology to bring people closer together – video top choice for people on panel. Use video to see each other, point to documents being discussed
  • Strong engineering practices – continuous integration, TDD, pairing, refactoring – on some teams, you can’t go home with anything that doesn’t build
  • Invest in coaching. You can improve scrm abilities by going down and training, spending time. Identify leadership within teams, and work with leaders to be a local proxy scrum master
  • Take time to understand cultural differences – inward (your own), outward (other cultures)
  • Need a well defined definition of done for team to follow.
  • The best way to build teams is through work. Succeeding (or failing) together at something draws everyone closer.

Other tips and observations

  • Time box discussions after standup if they tend to run too long.
  • Decide if people are suited to agile. Do they take pride in and ownership of their work? Do they show initiative? Are they technically strong?
  • A local proxy product owner is helpful
  • Take time to share about culture. Do things like share recipes, talk about movies, etc.
  • Get pictures of team members and look at them when collaborating.
  • Use remote pairing – avoid isolation
    • VNC and Skype are one option
    • When pairing isn’t possible then use code reviews to ensure *some* kind of review happens.
  • Ade Miller in his session notes observes that distributed teams are more dysfunctional than co-located teams. The act of distributing a team simply adds to any existing problems it might have.
    • Be prepared to do additional work to negate the impact of team distribution.
    • Articulate this work and cost to the business. It’s all about delivering maximum value to the customer not about hourly rates of individuals. Overall is the team delivering more value?

Agile 2008: Thursday & Friday Session Picks

Okay, round 3 of the Agile 2008 session picks. Agile 2008 is the premier conference of the Agile world. There are about 400 different sessions to attend, which is why I’ve taken about 2 days to wade through all the options. Earlier I posted my faves for Tuesday and Wednesday.


Early Morning

Tough choices. Leaning towards Eric and the panel in the next session, otherwise user story mapping.

Before Lunch

  • From High-performing to Hyper-performing Agile teams, panel discussion. Presentation of 3 unique case studies, by 3 top notch agile guys, each showcasing how to crank up the agile performance.I want to hear “techniques for working with many and varied clients simultaneously: how to maintain consistent and predictable velocity, how to scale teams without losing efficiency,and how to move developers fluidly between multiple teams and multiple products.”

After Lunch

  • From Concept to Product Backlog – What Happens Before Iteration 0? by Gerard Meszaros, Janice Aston. “This tutorial provides an overview of what needs to go on “behind the scenes” between when a project is conceived and when development can start in earnest. It identifies the artifacts that may need to be produced, whether and when they should be produced, which activities can be used to produce them and who should be involved in those activities.” ‘Nuff said.

Late Afternoon


Agile 2008: Wednesday Sessions I’d Like To Attend

My last post covered sessions I’d like to attend at the Agile 2008 conference on Tuesday, the opening day. Here is the short list for Wednesday:

Early Morning

Before Lunch

After Lunch

Late Afternoon

Agile 2008: Tuesday sessions I want to attend

Following Mark’s lead, I am posting sessions I would like to attend at the Agile 2008 conference. There are so many good ones to choose from, it’s hard to decide! If you are planning to go to any of these sessions, post a comment and let’s get in touch. Also check out the Agile 2008 Friendfeed room for others attending.



  • Expanding Agile Horizons: The Five Dimensions of Systems by Mary Poppendick. I’ve read from a few people she is an amazing speaker worth listening to, regardless of topic. I’m interested in learning where Agile may be heading next.
  • Agile Distributed Teams by Douglas Shimp. At ifPeople, all developers work for partner companies in South America, mostly Argentina. I’m based in Canada and the rest are in Atlanta. So yeah, distributed is a big topic for us. 🙂
  • Leadership Success Recipes for Agile in the 21st Century by Jean Tabaka, Chris Louvion. Jean is another amazing speaker. I’m particularly interested in leadership as a project manager trying to become a scrum master. Only down side is talk seems focused on large organizational issues, though not 100% sure about that.

After Lunch

Late Afternoon