Mark was familiar with Extreme Programming, another Agile process similar to Scrum but more engineering focused and less management focused. However, he had only heard about Scrum. Throughout the first day, Mark taught me about CMM, and I taught Mark about Scrum. On my side, I was quite surprised and impressed by CMM. Mark related that it was only a framework describing an organization’s maturity for developing software. How an organization satisfied that framework was up to the organization. Assessors were supposed to determine whether the manner in which the organization satisfied the framework was adequate. This enlightened me. Because almost every organization prior to 2001 used defined software development processes, CMM would of course build rigid, prescriptive, and defined methods for fleshing out the framework. These practices would suffer the weaknesses of all defined approaches—they would work only for situations that had been foreseen by those defining the practices. Since software development is a very complex process, there would be very few actual projects to which these practices would be applicable.
Mark then went over KPAs for the various levels with me. We then assessed how Scrum fulfilled the KPAs for each level. Mark was pleasantly surprised. Even though Scrum took an empirical approach, someone employing its practices would satisfy all of the CMM level 2 KPAs and many of the level 3 KPAs. The KPAs that weren’t satisfied at level 3 were those that addressed institutionalizing the practices. These KPAs were addressed in 2003 when the Scrum Methodology, the Certified Scrum Program, and Project Quickstart were made available as products. Figure E-1 shows the degrees to which Scrum addresses the various KPAs in level 2 and level 3. A double check mark means fully compliant, and a single check mark means mostly compliant.
To see how Scrum’s practices implement one of the KPAs, let’s take a look at KPA 2, “Requirements management.” The definition of this KPA is “The purpose of Requirements Management is to establish a common understanding between the customer and the software project of the customer’s requirements that will be addressed by the software project.” The Scrum mechanism for meeting this KPA is the Product Backlog, an openly visible listing of all functional and nonfunctional requirements maintained by the customers that is used to drive development, Sprint by Sprint. The emergent nature of the Product Backlog, with focus on only the top-priority items, maximizes the probability that investment in detailing requirements is of value. Lower-priority Product Backlog that might never be implemented is ignored until and unless it rises to the top of the Product Backlog list.
This KPA is often interpreted as demanding requirements traceability, the ability to show how requirements are fulfilled in the delivered system. The manner in which Scrum addresses this interpretation is by demonstrating within 30 calendar days how every Product Backlog item that has been worked on during the Sprint operates as business functionality. The proof is through an actual demonstration of the functionality. As the customer accepts the functionality as complete, that completed item reduces the Product Backlog.
This completely empirical approach to requirements traceability fully meets the requirements of the KPA without extensive documentation or overhead to the development process. It also provides complete flexibility to manage and trace changes in requirements anytime throughout the project. Scrum addresses the rest of the KPAs for level 2 and 3 similarly, empirically and with a minimum of documentation and overhead.