At Agile 2006, Ken Schwaber gave a talk about Agile Quality. Ken starts by describing the way product owners and teams should work. He mentions some statistics showing that on average, 35% of requirements change and 65% of what is delivered is rarely or never used. So product owners have to be skilled in requirements management and make sure the product backlog focuses on the highest value, importance, and risk stories 1st.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.
Ken mentions that a major problem most organization face is how to add new functionality tied to legacy system or to synchronize new functionality to core functionality. The main problem is that the core functionality has no test harness, is very fragile (a simple change breaks something else), and usually only few people still know and are willing to work on it. Thus, the velocity of core functionality team is a lot less than velocity of new functionality team.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.
Ken finishes by giving an example of SCRUM being used at Primavera and concludes that one should have the courage to do the right thing and that it is a professional responsibility that makes you feel better and is for the good of the company.This presentation is available on InfoQ at http://www.infoq.com/presentations/agile-quality-canary-coalmine
