Chapter 19. Coexisting with Other Approaches

It’s one thing to look at agile software development in a test tube; it’s another to experience it in the real world. In the test tube, agile methodologies like Scrum are easily adopted by all members, and the nasty realities of corporate politics, economics, and such cannot intrude. In the real world, though, all of these unpleasant issues do exist. It is rarely as simple as deciding to use Scrum and then being able to do so with no other constraints. One project might be allowed to try Scrum as long as it doesn’t interfere with the organization’s CMMI Level 3 certification. Another project might be allowed to try it as long as it passes the preliminary architecture review and then has a successful meeting at the design complete checkpoint.

There might be valid reasons for an organization to put these constraints on projects, but they are constraints nonetheless. I’m not using “constraint” here in any significantly pejorative manner; I’m using it to indicate that a degree of freedom has been taken away from the team and how it does its work. Not all constraints are bad things—in the United States (as in much of the world) I am constrained to driving on the right side of the road. I’m happy to do so because I know all the other drivers here are similarly constrained and are therefore much less likely to run into me. Similarly, many Scrum teams must work inside, within, and around the rules and norms of their organization, at least at first.

In this chapter we look at how a Scrum project is affected when it intersects with a sequential (waterfall) process. We next consider the impact of project governance and how Scrum projects can successfully coexist with non-agile governance approaches. Finally, we explore ways Scrum projects can comply with standards such as ISO 9001 or CMMI.

Mixing Scrum and Sequential Development

Few large organizations will enjoy the luxury of doing all of their projects with Scrum. Most will be forced to endure a period in which some projects have moved to Scrum while others have not. This might be because it would be too disruptive to transition the entire company at once, because it would be disruptive to make a mid-course process change to a particular project, or any number of other reasons. Because many organizations will face problems of mixing Scrum and sequential development at some point, we turn our attention to that topic in this section.

Three Scenarios of Interaction

Not every intersection of Scrum and sequential development will be the same. And the problems faced by a project will depend on the points at which Scrum and sequential development meet. Scrum trainer Michele Sliger describes three different scenarios in which Scrum and sequential development might interact (2006).

Waterfall-up-front

The confluence of Scrum and sequential development at the start of the project usually occurs when an organization has project approval hurdles. Clearing these hurdles usually requires the Scrum team to set aside any distaste it has for documents and create a specification, project plan, or other artifact that is required for approval. After a waterfall-up-front project is approved, it runs as a normal Scrum project. Sliger recommends following Alistair Cockburn’s advice and producing documentation that is “barely sufficient” (2000). Sliger describes a team that wrote a barely sufficient specification to gain approval for the project.

They set aside the specification and rarely referenced it during the course of the release. The creation of this specification was not, however, viewed as a waste of time. Rather, team members felt they had benefitted from the shared product vision created from the exercise of compiling the specification. And, of course, the financial managers on the project approval board got the information they needed as well. (2006, 29)

Waterfall-at-end

When Scrum and sequential development meet at the end of the project, it is usually for a testing phase. Sometimes waterfall-at-end occurs because the organization has only tentatively embraced Scrum and has left the testers or quality assurance people as a separate group who swoop in at the end to verify and validate the product. Other times, waterfall-at-end occurs when there is an external group—operations for example requires that some testing to occur at the end. The usual response to a waterfall-at-end requirement is to dedicate one or more sprints to completing this work. By the end of the project, the team has become accustomed to its new agile way of working, so it continues to use as much of Scrum as possible even at the end. In other words, it continues to work in sprints, will hold sprint planning meetings, have daily scrums, and so on.

Waterfall-in-tandem

Perhaps the most difficult way in which Scrum and sequential development interact is waterfall-in-tandem. A common example of this is when two or more teams must work together to create a single product and at least one team is using Scrum and at least one team is using a sequential approach. Coordinating work and communicating frequently are usually the chief sources of problems when waterfall-in-tandem is required. The sequential team will prefer to communicate through meetings and documents that lock down interfaces; the Scrum team will prefer to leave interfaces vague and communicate informally but frequently as interfaces and commitments are progressively defined.

The Scrum team that finds itself in this situation usually finds it helpful to entice the managers of the waterfall projects to attend sprint planning meetings or daily scrums. Sliger wrote about her experience getting sequential team managers to attend sprint planning meetings.

Initially, the waterfall managers grumbled that all these planning sessions were wreaking havoc on their calendars. However, once they had attended a few sessions, the managers began to realize the value of the shared information and the improved ease and coordination of the work. (2006, 30)

Three Areas of Conflict

Sliger describes the intersections between Scrum and sequential development in terms of how to approach the specific instances where two unlike methodologies converge. Barry Boehm and Richard Turner, on the other hand, write more in terms of how to avoid the three types of conflicts that arise when Scrum and a sequential process coexist:

• Development process. A development process conflict originates from the differences between the Scrum and sequential processes.

• Business process. A business process conflict is one created by the different ways in which Scrum and sequential teams interact with the business. An organization used to the plans created by a sequential team will be unfamiliar with the type of planning done by a Scrum team.

• People. Conflicts around people arise from the different and changed roles when using Scrum and from Scrum’s emphasis on self-organization, teamwork, and communication (Boehm and Turner 2005).

Some of these conflicts will occur within a single team—for example, Scrum expects lightweight requirements in the form of user stories or something similar, whereas a sequential process expects more thoroughly documented up-front requirements. Problems can result when an up-front agile activity feeds a downstream sequential activity but does so with less detail than expected.

The remainder of the conflicts are those that arise between two teams that are using different types of processes. We see this, for example, in the need to synchronize work between teams. Boehm and Turner write about the challenge of a Scrum team and a sequential team who must combine their work.

If the Scrum team evolves its own interfaces, it might leave other parts of the team at risk for developing against a changing standard. However, the traditional [sequential] approach of locking the interface specification early could encumber the Scrum team’s need to refactor some part of their design. (2005, 31)

As remedies for these problems, Boehm and Turner offer the following suggestions:

• Do more analysis than Scrum would usually call for. If a Scrum team is to work successfully with a sequential team, one compromise it will need to make will be to do more up-front analysis than it would usually prefer. This is necessary so that work can be partitioned among the teams involved and the large interfaces can ideally be identified.

• Build up a process that is barely sufficient rather than strip a large process down. Experience shows that when a large process is stripped down, it is rarely stripped far enough. The problems this causes are best avoided by starting with an empty process and then adding only that which is necessary.

• Define an architecture that compartmentalizes Scrum and sequential approaches. During project initiation and the first few sprints, focus on identifying areas of the system most suited for Scrum and sequential approaches. Those areas with stable, well-known requirements can be built by the sequential teams; those areas with uncertain requirements or where multiple design approaches are valid should be built by the Scrum teams.

• Adopt the agile practices that work well regardless of the process. Some of the agile practices are good ideas no matter what process is used. Continuous integration, heavy reliance on automated testing, pair programming, and refactoring are practices that can be as at home on a sequential project as they are on a Scrum project.

• Educate stakeholders. Because some stakeholders will interact with both Scrum and sequential teams, educating them is critical. These stakeholders will need to understand enough about each process to participate in it or understand it as their roles dictate.

Can Scrum and Sequential Coexist Forever?

Opinions are split on whether Scrum and sequential development approaches can coexist forever. Certainly there are organizations doing this today, and organizations have successfully supported multiple, non-agile development processes in the past. But is there something fundamentally different about Scrum that would prevent it from coexisting forever with a sequential process? Michele Sliger believes there is.

I used to say that companies could mix agile and traditional approaches indefinitely, as they might not wish to move every project to an agile environment. But after what I’ve seen in the past year, I no longer believe that to be true. I think that companies must eventually make a choice to go one way or the other, and I’ve been calling this tipping point “high-centering.” High-centering is a term used in four-wheeling. It happens when your Jeep climbs over a rock or pile of dirt only to end up balancing on its chassis, with none of its wheels able to make any purchase to move either forward or backward. When these companies get to a certain point of driving their Jeep up that agile mountain, they have to make a conscious and public decision to push forward when they get stuck—otherwise their teams will slide back down into the waterfall at the bottom.

I am inclined to agree with Sliger. Having Scrum temporarily coexist with a sequential process is often necessary in a large organization. But it is important to remember that agile is not a destination; being agile involves continuous improvement. As an organization attempts to become more and more agile, the conflicts between Scrum and sequential development will become more painful. If the sources of these conflicts are not removed, organizational gravity will pull the organization back to whatever software development process was in place before adopting Scrum. A few nonthreatening agile practices such as daily scrums or continuous integration might remain, but the organization will have been unable to achieve the compelling benefits of becoming agile.

Governance

One of the reasons why many organizations adopt a sequential approach to software development is the natural fit between a defined sequence of development phases and the need for project oversight. The purpose of project oversight, commonly called governance, is to make sure that a project does not go astray. Effective project governance can, for example, identify a project that will exceed its budget, leading to conversations about whether the project should be canceled. Governance can also identify a product that is drifting too far from its original goals, a project that is deviating from an architectural standard, or any number of similar high-level considerations important to the organization.

Project governance is not a new concept, but it finds its most natural home in the stage-gate process invented by Dr. Robert Cooper and shown in Figure 19.1. The central idea is that after each stage of a development process, the project is forced through a gate. Each gate acts as a formal review checkpoint on the project; the project might be approved to move forward, sent back for rework in the previous stage, or canceled (2001).

Figure 19.1 Stage-gate approaches are the source of many challenges. Stage-Gate^® is a registered trademark of the Product Development Institute.

A software team might encounter gates or governance checkpoints at a variety of times: an early review of their plans for scope, budget, and schedule; a review of architectural and design decisions; a review that the application is ready for system or customer acceptance testing; a review that the product can be handed off to a support organization; and so on. These checkpoints often wreak havoc on a software team’s desire to use Scrum as they are not suitable to work done in an iterative manner. For example, a Scrum team that allows the design of the system to emerge will have a difficult time clearing an early checkpoint that considers the appropriateness and correctness of the system’s architecture.

The first step in reconciling the need for project governance and the desire to use Scrum is to realize that project governance and project management are not the same thing. It is OK to separate project governance from project management. But in separating them we would like to achieve the ability to have high-level checkpoints to provide the necessary oversight, while still allowing the team the freedom of managing itself and the project in an agile manner.

As evidence that governance is not inherently evil, suppose that you are suddenly promoted to president or CEO of your company. As the new boss, you are going to want some visibility into the company’s major projects. Maybe you establish a rule that you personally need to approve the start of any project expected to cost over a certain amount. And, while you plan to attend as many sprint reviews as you can, you want any project that lasts over three months to give you a two-page summary of key information every three months. This would be a lightweight governance model and a reasonable one to put in place. So it is not the existence of governance that is objectionable; it is when governance starts to affect how we run the projects that we object.

Running Scrum Projects with Non-Agile Governance

Because few organizations will go so far initially as to completely revamp their current approaches to governance, teams will need ways to work with their organization’s non-agile governance. Taking the following actions should help.

Negotiate and set expectations up front

Undoubtedly, the first Scrum project to go through the governance process in your company will have challenges. There will almost certainly be some things they cannot do; for example, a Scrum team cannot provide a thorough design before getting permission to start coding, because design and coding will be done concurrently. The only solution to this is for the team to negotiate with the necessary governance groups in advance. The more support a team has for this and the higher up in the organization that this support reaches, the better. The team does not need to solicit a permanent change in governance policies. The change can be pitched as a one-time experiment.

Fit your reporting to current expectations

The project review boards or oversight committees that provide project governance have existing expectations for what information each project is to provide at each checkpoint. Don’t fight these expectations. If they expect a Gantt chart, provide a Gantt chart. When you can, however, try to slowly shift expectations by providing additional, more agile-friendly information. If burndown charts are suitable to show, do so. Or perhaps you want to include a report showing the number of times the build server kicked off continuously integrated builds and the thousands (or perhaps tens or hundreds of thousands) of test runs that were executed.

Invite them into your process

Scrum teams can supplement less-detailed formal governance checkpoints by inviting governance committee members to participate in the regular meetings they will hold. Teams at Yahoo! undergo a review by an architectural review committee. Gabrielle Benefield, former director of agile product development at Yahoo!, recalls how its early agile teams handled this.

Agile teams...invited people from the architectural review committee to their sprint reviews early on. They then still had one formal checkpoint, but by then most major questions had been resolved. This was a lot less painful, and trust and collaboration [were] built earlier.

I like to extend the well-known technique of management by walking around into management by standing around. Encourage managers and executives involved in the governance of a project to attend the daily scrums, where they can stand and listen to what is occurring on the project. The same shift from documents to discussions that is created by working with user stories needs to occur with project reporting. Encourage people to visit the team or join its meetings to see for themselves what is being built.

Reference a success

Nothing convinces like success. Do whatever you can to get a first project or two through lightened or reduced governance checkpoints. Then point to the success of those projects as evidence that future projects should also be allowed through. Gabrielle Benefield points out that “once you get a few agile teams showing favorable results, you build trust. And you can then work on the larger overall governance process.”

The concepts of agility and project governance are not fundamentally opposed. Each is an attempt to improve the finished product. Scrum strives to do this through close collaboration and the short inspect-and-adapt cycles of the time-boxed sprints. Project governance strives to do it by what we might call inspect-and-approve (or reject) checkpoints in which the product or project is compared to a set of desirable attributes. However, while pursuing similar goals, Scrum and project governance take entirely different routes to achieving those goals. It is in these different routes where problems will arise in mixing the two. Fortunately, a few compromises on each side, combined with the advice in this section, can lead to a successful combination of agility and oversight.

Compliance

Not every team or even software development department has the luxury of having complete control over its development process. For example, in outsourced, contract development, customers often mandate that suppliers be CMMI Level 5 certified, which requires those software developers to follow certain established best practices. Additionally, some software-intensive products are delivered into regulated industries and must comply with standards such as ISO 9001. Companies producing medically regulated devices must comply with ISO 13458. Publicly traded companies in the United States must comply with Sarbanes-Oxley. The list goes on.

None of these standards prescribes a life cycle that is completely at odds with Scrum. Some of them, however, come close, as they assume that a sequential process will be used. Because complying with standards such as these is rarely optional, Scrum teams must concern themselves with how best to comply, starting in some cases with the question of whether doing so will even be possible with a Scrum process. In this section we will look at how Scrum teams comply with ISO 9001 and CMMI, two of the more common standards with which Scrum teams have learned to coexist. From examining ISO 9001 and the CMMI, we can generalize some coping strategies useful in other compliance situations.

ISO 9001

The International Organization for Standardization (ISO) maintains standard 9001, which is usually fully designated as ISO 9001:2000 or ISO 9001:2008, both of which indicate the year of a specific version of the standard. ISO 9001 certification is not intended to guarantee that an organization’s products achieve a specific quality level. Rather, ISO 9001 certification indicates that the organization follows a set of formal practices in developing its products. A large part of the effort in complying with ISO 9001 is the creation of a quality management system, which is usually a lengthy document or set of web pages that describes the quality practices followed by the organization.

Primavera Systems, developer of project and portfolio management systems, created its quality management system over a ten-month period. The company conducted 30 workshops to document its existing processes, and each workshop included a cross-functional representation of developers.

Primavera already had substantial experience with agile practices at the time it initiated its ISO 9001 effort. In such an environment it would be natural for employees to be concerned about a loss of agility with the introduction of ISO 9001. Bill McMichael, of Primavera, and Marc Lombardi, a consultant with expertise in ISO 9001, worked together on the initiative and found that the documentation did not diminish their agility.

There were concerns about violating the principle of “working software over comprehensive documentation.” Our mantra was to provide just enough documentation to be a useful reference and to help with enforcement of existing processes. (2007, 264)

Corroborating Primavera’s experience of taking nearly a year to get to the point where it could pass an ISO 9001 certification audit is Graham Wright. A coach at Workshare in London, Wright was involved in his organization’s successful ISO 9001 certification, which took a little over a year and began 13 months after Workshare adopted Extreme Programming. Wright reports that “in achieving certification no changes were made to our existing XP practices” (2003, 47).

My Experience with ISO 9001

These experiences with ISO 9001 match my own. In 2002 I managed a team of developers whose organization had decided to become ISO 9001 certified. Because my team was newer to Scrum than Primavera was at the time of its effort, I took a different approach and wrote the majority of our quality management system myself.

A few months before the official audit, we met with our auditor to familiarize him with how we built software and to learn his specific expectations of us. This being early 2002, he had never heard of Scrum, and none of us had prior experience with ISO 9001. As a result of that meeting we made a few process changes. The first was that he was adamant that he would not let us pass an audit with user stories written on index cards. The user story format was fine, but he insisted we produce a “document.” We agreed to photocopy the user stories onto notebook-sized paper and store them in a binder with a sequence number on each user story. The second change was that while our informal design processes were fine, we would need to produce more design documentation. Our auditor suggested we take photos of the whiteboard after every design discussion and file these along with copies of any handwritten notes anyone had taken. We put a locking file cabinet in the team room and stored all design documentation there.

When our auditor returned, we passed his audit. What was most interesting about that visit was how impressed he was with our automated test processes. In addition to a build server doing continuous integration, we did an official nightly build that included thousands of tests, mostly written in JUnit. We showed the results of the last month of nightly builds; every night the build and all tests had completed successfully. As great as this team was, it was a bit fortunate to have not had a single failed test during that period. The auditor took one look at all those claims of successful tests and asked, “How do you know the tests aren’t broken? Maybe they aren’t running at all and your test harness just reports success.” Well, we knew because inevitably there were test failures during the day. There just had not been any failures at night. But that wasn’t good enough for our auditor, who insisted we include a failing test in every night’s build. We added

assertTrue(false);

That test fails because false isn’t true. Once we added our failing test we passed our ISO 9001 audit.

Although I don’t think any of these steps helped us produce better software, they did not add significant ongoing overhead. Documenting everything about our process took time, but that was a one-time effort (with planned annual updates), and I bore the brunt of that for the team. Juan Gabardini, who has worked with Scrum in two ISO 9001-certified companies, concurs.

There was overhead for the company, but for the team it wasn’t so bad. I don’t say it is painless! And you will need the help of an open-minded ISO consultant to help you keep everything as lean as possible but no leaner. (2008)

Capability Maturity Model Integration (CMMI)

Almost since the first agile project emerged from the primordial ooze, companies have been asking whether agile methodologies are compatible with the Software Engineering Institute’s Capability Maturity Model Integration (CMMI). As a measure in some ways of how much process an organization has (or at least how much of it has been defined), the CMMI and its predecessor, the Software Capability Maturity Model (SW-CMM), are often viewed as heavyweight ways of developing software and the antithesis of agile development. Richard Turner, who was on the original team that wrote the CMMI, and professor Apurva Jain have said that “while there are significant differences, the ‘oil and water’ description of CMMI and agile approaches is somewhat overstated” (2002).

Turner is not the only one of the CMM authors to have considered its applicability on agile projects. Mark Paulk, lead author of the initial SW-CMM, assessed Extreme Programming against the 18 key process areas of the original SW-CMM. Paulk’s opinion was that XP partially or largely addressed 10 of the 13 areas necessary to reach Level 3 and was not an obstacle to the other three.

We can thus consider CMM and XP complementary. The SWCMM tells organizations what to do in general terms but does not say how to do it. XP is a set of best practices that contains fairly specific how-to information—an implementation model—for a particular type of environment. XP practices can be compatible with CMM practices (goals or KPAs), even if they do not completely address them. (2001, 26)

Experience combining agile practices with CMMI is not only theoretical though. There are now many companies who have successfully combined agile development with the SW-CMM or the CMMI. Erik Bos and Christ Vriens of Philips Research led one of the first agile projects to be documented as undergoing a CMM audit. They say that their “assessors were especially impressed with the transparent, easily accessible, and uniform project information” (2004).

Joe Fecarotta, whose agile project was assessed as CMMI Level 3, also found CMMI and agile compatible. He says that “CMMI and the associated audits were not forcing a particular methodology but attempting to help the group follow best practices” (2008).

Agile methodologies like Scrum have also been introduced into organizations already assessed as CMMI Level 5. Systematic, an independent software developer in Denmark and the UK, employs over 400 people and develops software in the defense, healthcare, manufacturing, and services industries. After approximately two years at Level 5, it decided to also adopt Scrum. It reports that the two complemented each other well.

Scrum now reduces every category of work (defects, rework, total work required, and process overhead) by almost 50% compared to our previous CMMI Level 5 implementation while maintaining the same level of process discipline. (Sutherland, Jakobsen, and Johnson 2007, 273)

The incorporation of Scrum into Systematic’s CMMI Level 5 process shows a solution to a common problem with CMMI implementations. In pursuing a particular CMMI level, many organizations forget that the ultimate goal is to improve how they build software (and presumably, therefore, the products they deliver). They instead become focused on filling in supposed deficiencies according to CMMI documentation without concern for whether the changes will improve the process or its products. This problem can be eliminated when CMMI goals are combined with the value-focused, “what-have-you-done-for-me-lately” mind-set inherent in Scrum. Jeff Sutherland, Carsten Jakobsen, and Kent Johnson, who were all involved in Systematics’ adoption of Scrum, refer to the combination of Scrum and CMMI as a “magic potion.”

When mixing the two, a magic potion emerges, where...Scrum ensures that the processes are implemented efficiently while embracing change, and CMMI ensures that all relevant processes are considered. (2007, 272)

Achieving Compliance

We’ve firmly established that Scrum is compatible with at least ISO 9001 and CMMI, on both theoretical and empirical grounds. Let’s turn our attention to specific things that you can do to successfully combine them with Scrum in your organization:

• Put enough effort into your product backlog. A common thread running through projects with compliance requirements is that they all benefitted from putting effort into their product backlogs. They didn’t feel the need to fully elaborate all product requirements up front, but teams that invested in a well-formed product backlog that could be progressively refined with more detail, as described in Chapter 13, “The Product Backlog,” found that doing so contributed to meeting their compliance goals.

• Put compliance work on the product backlog. If a document or other artifact needs to be produced to achieve compliance, put the work to produce it on the product backlog. Not only does this ensure the work isn’t forgotten, but it also keeps the cost of compliance visible.

• Consider the use of checklists. A number of projects reported that the use of checklists was helpful. It is important that checklists not introduce new mandatory steps. Instead, checklists should include steps the team already does and should exist only to prove to an auditor or appraiser that the activities are being performed. As an example, Systematic, the CMMI Level 5 company mentioned earlier, used a one-page story completion checklist that started with whether the story had been estimated and ended with the story being integrated into the system. A team’s definition of done, as described in Chapter 14, “Sprints,” could easily be turned into a checklist.

• Automate. Build and test automation are important to the success of any Scrum project. They are doubly so for projects with compliance requirements.

• Use an agile project management tool. Traceability is an important consideration for most compliance standards. As much as I prefer tangible artifacts—handwritten index cards and big, visible charts hanging on walls—an agile project management tool should at least be considered by teams with compliance requirements.

• Move slowly but steadily. You probably cannot overhaul a significant process element, such as an ISO 9001 quality systems manual, overnight. So, do what Scrum teams do best: Do it incrementally. Gradually revise the quality systems manual to be more agile. Because much of ISO 9001 is about making sure a company follows its own quality system, the company can revise its quality system to support Scrum.

• Work with your auditor. Whenever possible, meet your auditor in advance. Have an informal discussion about how you develop software, and ask the auditor to point out any red flags. When possible, work with experienced auditors who understand that just because the process might be strikingly different does not mean it cannot achieve the goals of the standard.

• Bring in outside help. If you have not been through a certification attempt of the type you are after, bring in an outside consultant who has. If you are not yet adept at Scrum, bring in an experienced ScrumMaster. Having or bringing in expertise on both fronts is critical.

Onward

Scrum will rarely be implemented in a pristine environment with no intrusions from the outside real world. In this chapter we looked at three different types of intrusions: the need to work with another sequentially managed project (or to run part of the Scrum project in a sequential manner); the need to work within a corporate governance system; and the need to comply with laws, regulations, or standards. In the next chapter, we continue looking at challenges to succeeding with Scrum. We look at some of the ways Scrum teams and projects can be affected by other groups or departments in the organization, including facilities, human resources, and the project management office.

Additional Reading

Boehm, Barry, and Richard Turner. 2005. Management challenges to implementing agile processes in traditional development organizations. IEEE Software, September/October, 30–39.

In 1988, Boehm presented the spiral model, one of the first valid alternatives to a waterfall process. In this book, along with coauthor Turner, he presents the view that agile and “disciplined” processes exist along a continuum and may be mixed as needed based on the specific risk factors of a project.

Glazer, Hillel, Jeff Dalton, David Anderson, Mike Konrad, and Sandy Shrum. 2008. CMMI or agile: Why not embrace both! Software Engineering Institute at Carnegie Mellon, November. http://www.sei.cmu.edu/pub/documents/08.reports/08tn003.pdf.

This white paper presents the opinion that CMMI best practices and agile methodologies are not at odds with one another and that the approaches can be successfully combined.

McMichael, Bill, and Marc Lombardi. 2007. ISO 9001 and agile development. In Proceedings of the Agile 2007 Conference, ed. Jutta Eckstein, Frank Maurer, Rachel Davies, Grigori Melnik, and Gary Pollice, 262–265. IEEE Computer Society.

This short experience report provides specific advice on how Primavera added ISO 9001 to its existing Scrum process.

Paulk, Mark. 2001. Extreme programming from a CMM perspective. IEEE Software, November, 19–26.

This 2001 article is a bit dated, as it compares Extreme Programming to the now-replaced CMM. However, as it is by the lead author of the CMM, his opinions are still well worth reading.

Sliger, Michele. 2006. Bridging the gap: Agile projects in the waterfall enterprise. Better Software, July/August, 26–31.

This article presents the view that agile and waterfall processes can coexist in organizations. It provides specific advice for doing waterfall up front, at the end, or concurrent with an agile process.

Sutherland, Jeff, Carsten Ruseng Jakobsen, and Kent Johnson. 2007. Scrum and CMMI level 5: The magic potion for code warriors. In Proceedings of the Agile 2007 Conference, ed. Jutta Eckstein, Frank Maurer, Rachel Davies, Grigori Melnik, and Gary Pollice, 272–278. IEEE Computer Society.

This report about a highly productive project presents the claim that the combination of Scrum and CMMI is more powerful than either is alone, and includes guidelines for mixing Scrum and CMMI.