AGILE IN ACTION

Friday, 9 December 2005

Under-promising and over-delivering is a process smell

Posted by Simon Baker

A short while ago I read a post by Skip Angel that talked about delivering on your promises. It reminded me of a situation a colleague told me about where a scrum team was under-promising and not telling the product owner, so that they had a better chance of delivering or over-delivering. I described the situation on the Scrum Development newsgroup.

In the discussion that followed, Jef Newsom described the act of under-promising and over-delivering as a “process smell”. He said “the intent is good, but the means is deceptive”. It indicates “that you aren’t comfortable being honest with the parties to whom you are committing to deliver”, i.e. to the product owner.

It’s the product owner’s responsibility to decide on the content of a sprint based on business value and cost, given in terms of estimates provided by the scrum team. It’s the scrum team’s responsibility to provide a cap on the amount of work assigned to a sprint based on their velocity. To paraphrase Ron Jeffries - you can’t put 10lbs of shit in a 5lb bag. When the content of a sprint is agreed, the product owner must understand that it’s an estimate and not a promise that it will all be delivered.

When the product owner wants to know what will be done by the release date and what will not be done, Ron Jeffries says “refer him to the burndown chart on the wall”. Given empirical estimates and the tracking information produced by agile teams, the information in the burndown chart should be good enough, in most circumstances, to plan release dates by “drawing a line about there” in the product backlog.

The lessons to learn from this thread are:

  1. Relationships are all about open and honest communication and trust. Keep everything visible and get any hidden feelings out into the open. Talk straight and leave your box of tricks at home.

  2. There’s a big difference between and estimate and a promise. Ensure that the product owner knows that the scrum team’s commitment to deliver the sprint content is an estimate and not a promise. Otherwise, if the team fails to deliver the sprint content, the product owner will see the team as having broken their promise and this degrades the trust in the relationship.

  3. Don’t play the ‘promise’ game with the product owner. As Ron Jeffries says “we have better data to give them than most software organizations ever produce. Let’s give them that, help them to interpret it. Let’s not play a game we can’t possibly win.”

Creative Commons Licence

Recent Posts

  1. System failure is inevitable so design for a fast recovery
  2. Delight comes as a surprise in unexpected places
  3. Help create business agility. Bake quality in
  4. Governance - Friend or Foe?
  5. 70% Forum
  6. Measuring purpose. Measuring customer delight
  7. Stop pushing features and start delighting users
  8. Lost without a goal
  9. Emotion creates the common language
  10. Five sneaky ways to kill an initiative

Archives

  1. 2012 (16)
  2. 2011 (24)
  3. 2010 (31)
  4. 2009 (41)
  5. 2008 (69)
  6. 2007 (152)
  7. 2006 (128)
  8. 2005 (63)
    1. December (22)
      1. Giving trust
      2. Being empowered means being prepared to take a chance
      3. Leading the way
      4. Getting to know people
      5. Slop and slack
      6. What does it mean to be empowered?
      7. Feelings of worth
      8. Martin Fowler has updated The New Methodology
      9. Seeking improvement and receiving feedback
      10. Teamwork and trust
      11. Rules for simplicity
      12. Serenity isn't freedom from the storm, but peace within the storm
      13. How not to do it: Agile development, Microsoft-style
      14. The illusion of fixed price contracts
      15. Effective conversation
      16. Your scrum team needs you
      17. Can trust be restored once it's lost?
      18. Under-promising and over-delivering is a process smell
      19. Daily scrum haiku
      20. Write production-ready code faster with TDD
      21. Kent Beck talks about Extreme Programming and QA
      22. Talking about Selenium with Luke Closs
    2. November (15)
    3. October (11)
    4. August (8)
    5. July (2)
    6. June (1)
    7. May (4)
  9. 2004 (2)

Tags

agile (43) big visible chart (15) conference (40) culture (18) extreme programming (21) leadership (18) lean (47) people (26) planning (17) retrospective (18) scrum (41) story (19) team (30) testing (19) xpday (19)