I'm considering re-reading Steve McConnell's excellent "Software Project Survival Guide" and perhaps applying it verbatim to my next project. However, one thought struck me: the book was written in 1998, before Scrum and other agile methodologies became popular.

Are the teachings of this book still relevant in light of the newer methodologies? Or are they compatible? If the latter, do you have any experience of agile projects run according to McConnell's book(s)?

  • 1
    Related question on SO you might find useful: stackoverflow.com/questions/799334/…
    – yannis
    Oct 29, 2011 at 22:32
  • Which sections, exactly, do you not think could be used in an agile methodology? I've read the book and am flipping through it now, and I'm remembering and seeing mostly general tips that would make any project, plan-driven or agile, successful.
    – Thomas Owens
    Oct 29, 2011 at 22:33
  • @Yannis Not an exact duplicate. That question is asking about the relevance of the tips to a project. This is about applying the book to an agile methodology.
    – Thomas Owens
    Oct 29, 2011 at 22:34
  • @ThomasOwens The whole idea of delivering software in "stages" (each with requirements updates, detailed design, construction etc, see p. 175) sounds antithetical to the (short) iterative delivery proposed by XP and Scrum. I'm not sure how long such a "stage" is supposed to take but it doesn't sound like the 4-6 weeks used on agile projects.
    – lindelof
    Oct 29, 2011 at 22:38
  • @ThomasOwens Yeap, that's why I didn't flag the question, wasn't really sure. I've edited the comment to something more appropriate now.
    – yannis
    Oct 29, 2011 at 22:40

1 Answer 1


In general, yes, the tips in the book are applicable to any software project. In the "Preliminary Survival Briefing" section of the book, Steve McConnell writes:

The plan described in the following chapters has been crafted to address the most common weaknesses that software projects face. It is loosely based on the "key process areas" identified by the Software Engineering Institute (SEI) in Level 2 of the SEI Capability Maturity Model. The SEI has identified these key processes as the critical factors that enable organizations to meet their schedule, budget, quality, and other targets. About 85 percent of all organizations before below Level 2, and this plan will support dramatic improvements in those organizations. The SEI has defined the key process areas of Level 2 as follows:

  • Project planning
  • Requirements management
  • Project tracking and oversight
  • Configuration management
  • Quality assurance
  • Subcontract management

This book addresses all of these areas except subcontract management.

The Capability Maturity Model Integration (CMMI) has superseded the Capability Maturity Model, and with CMMI comes process areas for integrated product development teams, additional requirements engineering and risk management activities, which further enable achieving agile development within the CMMI framework. However, that doesn't mean that adhering to the CMM prevents agile methods.

You specifically mention staged software delivery and that it appears to be counter to the methods used in Extreme Programming and Scrum. In an iteration or sprint, you actually do go through each stage - requirements gathering and prioritization, estimation, work breakdown, design, implementation, testing, and release. In more traditional agile methodologies, those are extremely short iterations of 2 weeks, while in the spiral model, they could be 6 months or longer. The differences are how much you can do in a particular iteration and how you plan and budget that work.

  • Ah so if I understand you right, the XP/Scrum iteration maps naturally to McConnell's "stages", right? So McConnell's method describes all the management activities that happen behind the agile scenes, and which are seldom addressed in books on agile, at least not in those I have read.
    – lindelof
    Oct 30, 2011 at 14:01
  • @lindeloff I don't know what books you've read, but in agile, you need to perform requirements engineering, design/architecture, implementation, and testing in every iteration. It's just that they might happen concurrently, in different orders, or be done by different groups of people.
    – Thomas Owens
    Oct 30, 2011 at 14:03
  • you're right, I guess I was living under the impression that the stages described by McConnell were much more formal and ceremony-laden than in typical agile methods.
    – lindelof
    Oct 30, 2011 at 14:54
  • @lindelof They can be, if that's what your process calls for. Those stages happen, certain things need to be done, and the formality and ceremony involved depends on your process. Some environments require more formality, while others don't need it.
    – Thomas Owens
    Oct 30, 2011 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.