I just read Balancing Agility and Discipline. Poor title aside, it contrasted a plan-driven project team that was employing PSP/TSP and an agile team using Extreme Programming.

When the authors provided an example of a plan-driven methodology, they used Personal Software Process/Team Software Process. Although, out-of-the-box, these are plan-driven methodologies, they are also designed to be used as process frameworks and ultimately only specify what types of things to do and not how to do them, whi ch makes them potentially useful even in an agile environment. It's possible to be agile and still adhere to the PSP principles, and I'm not familiar enough with the TSP to say for sure, but my understanding is that it is very similar.

At one point in the book, they list a number of methodologies and rank them in terms of agility. Methods like Scrum, Lean, Crystal, and XP are at the top. The bottom (from most to least agile) consists of the Rational Unified Process, the Team Software Process, Feature-Driven Development, CMMI, Software CMM, the Personal Software Process, and Cleanroom.

Watts Humphrey, in PSP: A Self-Improvement Process for Software Engineers, dedicates a chapter to process definition, and specifically modifying the Personal Software Process. The common theme is that processes are prescriptive (they say what to do) and not descriptive (how to do it). I would surmise that the TSP is very much the same way. CMMI has also been used in conjunction with agile methods, and the SEI has a book on it (which I have not yet read).

Feature-Driven Development is often touted as an agile approach to project management, yet the authors choose to rank it as a less agile methodology.

RUP is an iterative framework. Although I'm not incredibly familiar with it, the fact that it's a framework lends me to group it with SW-CMM, CMMI, and PSP/TSP in that it could be implemented either as an agile or as a plan-driven methodology.

The only other example that the book provides that I agree with is Cleanroom Software Engineering. The key components of Cleanroom are the use of formal methods, statistical quality control, and statistically-sound testing. I don't see why these couldn't be used in an agile (iterative/incremental) method, with added the time and cost overhead.

Just to clarify what I'm looking for, the family of agile methods includes specific implementations of an abstract idea in the form of Scrum and Extreme Programming. These realize the concepts of iterative and incremental development, responding to change, people (individuals and teams), frequent delivery of working software, collaborating with the customer, and so forth. They clearly specify roles, artifacts, meetings, timeboxes, and other practices and to "do Scrum" or "do Extreme Programming" means to take the package. Even so, they allow for tailorability and the creation of new processes (but then you aren't "doing Scrum" or "doing XP"). However, I haven't found the "do X" of plan-driven methodologies - most of the work appears to be toward frameworks that could be agile or plan-driven.

So, my question: What are examples of more plan-driven software development methodologies? A number of the process frameworks (PSP/TSP, SW-CMM, CMMI, RUP) allow for plan-driven or agile development, as well, but none are descriptive. But are there any truly plan-driven methodologies, that are, for example, direct counterparts to Scrum and Extreme Programming?

  • You write that the book "contrasted a plan-driven project team that was employing PSP/TSP and an agile team using Extreme Programming". I'm pretty sure we use a lot of planning for our implementation of XP. I'm a little puzzled to assume that XP'ers don't plan. My experience is different. My two cents.
    – Manfred
    Commented Oct 25, 2011 at 8:30
  • @John Plan-driven methodologies are centered on applying traditional engineering techniques and moving systematically from requirements through, ultimately, a delivery product, while performing verification and validation at step. They are characterized by strong documentation and traceability through the life of the system. There are detailed plans, workflows, and work products (that are things other than working software).
    – Thomas Owens
    Commented Oct 25, 2011 at 9:58

1 Answer 1


Honestly, I have doubts about the validity of any claim made in a book which sets Agility and Discipline off against each other. Agile methodologies require much more discipline, in my experience, than other kinds of development.

That is, if you're going to exploit the benefits of Agile processes, you must follow the enabling practices that come with them (see Martin Fowler's Is Design Dead article; he is mostly talking about XP, but it applies to all Agility, in my opinion). That takes a lot of discipline.

But, to answer your question, I think that all truly plan-driven methodologies are variations of Waterfall, such as Spiral, which takes development through multiple levels of prototyping before switching to a Waterfall approach, and Cap Gemini SDM, which is Waterfall with very distinct phases where each ends before another starts.

  • 1
    I agree - I don't like the comparison between "agile" and "disciplined". "Agile" versus "plan-driven" is much better, and I've read in several sources (although I can't name any off the top of my head) that being agile requires dedicated, knowledgeable, and even more experienced teams, even more than any plan-based methods. As for your last paragraph - those are still frameworks. There are many plan-driven frameworks, but nothing that as explicit on "this is {insert name here}" in the same manner that you can say "this is Scrum" or "this is Extreme Programming".
    – Thomas Owens
    Commented Oct 25, 2011 at 1:17
  • 1
    @ThomasOwens: Spiral is a methodology, not a framework. You might have a point about V-model though. Maybe Cap Gemini SDM is a better example, though it always looks a lot like Spiral to me. en.wikipedia.org/wiki/System_Development_Methodology
    – pdr
    Commented Oct 25, 2011 at 1:29
  • 1
    Spiral is much closer - it clearly defines phases and some documents (requirements, conops, development plans, test plans and procedures) and technical outputs (prototypes, a final product). I would say that and Cap Gemini SDM are much closer to what I'm looking for (could you add SDM to your post?). +1.
    – Thomas Owens
    Commented Oct 25, 2011 at 1:36
  • 1
    @ThomasOwens: Done and replaced V-model.
    – pdr
    Commented Oct 25, 2011 at 1:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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