Traditionally customers have no visibility into what’s happening until the project is almost done.
In iterative developments, customers have visibility into the project and can control risk
Every sprint, some cumulative business value is delivered. At some point, enough ROI is achieved that the customer can get rid of functionality of lowered earned value.
Ken moves on to describe the place that product owners and teams come from using waterfall and discusses some of the bad techniques for delivering on time and on cost:
1. Reduce quality
2. Change definition of done to somewhat done and add stabilization, user acceptance, alpha and pre-release phases
Next Ken describes how scrum falls apart if these habits persist and how organizations have fallen apart because of these habits.
He starts by listing some of quality reduction techniques:
1. Overtime (studies shows that increasing a working day increases defects)
2. Cut unit testing, acceptance, and performance testing
3. Skip design and code reviews
4. Don’t follow standards
5. Don’t refactor
These techniques lead to a scrum only including analysis, design, coding and some testing. Every sprint something is left behind and not done. Instead it should be optimized so that in every sprint everything is done. Ask the team to define done for every sprint and daily scrum. And done should include everything.
Investigating this problem further reveals that as teams bend to pressure to meet dates, they drop quality and deliver incremental crap, and within 4 or 5 years, the team’s velocity is down all the way to 1 because the software is in such bad shape.
Ken emphasizes that we should have the courage to do the right thing and not drop quality. Dropping quality to meet a date is not a customer or product owner decision. It’s a CFO decision because of the impact on the company. Software is an organizational asset and decision to cut quality must be made by executive management and reflected in financial statements.
To get out of this mess, companies end up rebuilding core functionality into each function, building new stuff and not worrying about core functionality, dropping functionality, or allocating more developers to the core team in an attempt to build up and increase the velocity of core functionality.
To undo these habits, Ken suggests that the ScrumMaster teaches the product owner how to manage by value and that he not allow the team to present anything that is not done. The CEO should be apprised of the root cause of the problem and should provide support.
This presentation is available on InfoQ at http://www.infoq.com/presentations/agile-quality-canary-coalmine