When Does Traditional Software Development Make Sense?

We’re often asked by our customers when it makes sense for a team to take a traditional approach to software development. Sometimes people are honestly trying to identify when each potential lifecycle, including the traditional lifecycle, makes sense to follow. In many cases this request is coming from people who are desperate to continue working in the same old way that they’re comfortable with. They often hope that the context of the situation that they’re in puts them in a position where they don’t need to adopt new ways of working. Some people get “lucky”, although how lucky it is to forgo an opportunity to gain new skills that are currently in demand is questionable at best, but most find that they need to join their colleagues in adopting agile.

Traditional development was prevalent in the 70s through 90s, but starting in the mid-90s organizations started to adopt iterative approaches such as the Unified Process (UP) as well as agile approaches such as Scrum or Extreme Programming (XP). Having said all this, the majority of organizations still have a few teams following traditional lifecycles and will often have people who believe that traditional software development is a good idea. And, as I argue in this blog, in a few situations they’re right about that.

This blog explores several issues surrounding traditional software development:

  1. What is traditional development?
  2. When does it make sense to take a traditional approach?
  3. What factors have no bearing on when traditional makes sense?
  4. But isn’t traditional better at scale?
  5. Does Disciplined Agile (DA) support a traditional lifecycle?
  6. Doesn’t Disciplined Agile Delivery (DAD) have a serial lifecycle?
  7. Why should you listen to me?


What is Traditional Development?

Traditional development, also called serial or waterfall, is based on the idea that the delivery lifecycle should be organized into phases or stages. Figure 1 depicts a classic waterfall lifecycle, similar to what Winston Royce originally proposed (and recommended against) in his 1970 paper. In a pure waterfall the flow is unidirectional (from Requirements to Architecture to…) whereas Figure 1 depicts a “modified waterfall” using bi-directional flow that indicates feedback from a phase may go back to the previous phase.

Figure 1. The Waterfall lifecycle.

Figure 2 depicts a gated waterfall where you need to pass through a “quality gate” to move between phases. The “quality gate” tends to be based on the review and acceptance of artifacts – for example a Software Requirements Specification (SRS) coming out of Requirements, a Software Architecture Design (SAD) coming out of Architecture, and so on. It also shows how feedback can go back to any phase via a Change Control process, which on most traditional teams proves to be a change prevention process in practice. I used quotes around “quality gate” because “quality gates” tend to have very little to do with quality in practice and have a lot to do with promoting questionable bureaucracy. My point is that traditional rhetoric may be blinding you to serious deficiencies in this approach.

Figure 2. The Gated Waterfall lifecycle.

Gated Waterfall lifecycle 

Figure 3 depicts the V-model version of the traditional approach where the test phase is depicted as multiple stages and there are clear indications of what each testing activity validates (for example, Integration Test validates your architecture).

Figure 3. The V-model lifecycle.

V lifecycle

The governance strategy with traditional development tends to be artifact based (i.e. someone reviews and signs off on your architecture document) rather than risk based (i.e. we proved that the architecture works by building a vertical slice of the solution that implements high-risk requirements). Each phase tends to be staffed with specialists (i.e. requirements are captured by requirements analysts, the design is created by designers, and so on) which tends to motivate a quality gate approach, the development and maintenance of traceability information, and significant management effort to coordinate everything. This in turn increases cost, overall cycle time and decreases ability to support changing requirements (traditionalists typically fear “scope creep” whereas agilists embrace evolving requirements) which in turn decreases stakeholder satisfaction with the end product.


When Does Traditional/Waterfall Make Sense?

There are several situations when the traditional approach makes sense:

  1. Your team has a traditional culture and skillset. Some teams haven’t adopted an agile mindset nor gained agile skills yet, for whatever reason. Teams are more likely to succeed following a strategy that they understand as opposed to one that they don’t.
  2. The project is low risk. The serial nature of the traditional lifecycle makes it poorly suited to address risk, regardless of what adherents of traditional claim. It’s interesting to note that in the original whitepaper describing the traditional lifecycle that Winston Royce pointed out that it wasn’t appropriate for high-risk endeavors, an important tidbit of advice that many organizations have unfortunately ignored over the decades.
  3. You’ve done this sort of thing before. One category of project where traditional seems to thrive are “repeat projects” – you’ve done it before and you know what you’re doing so it’s unlikely that you’ll run into unpleasant surprises. An example of this type of project is the installation of a software package by a company that specializes in doing exactly this. This in effect is a type of low-risk project.
  4. The requirements are unlikely to evolve. There are some projects where the requirements typically don’t change, such as the deployment of a new version of an operating system across many machines (think Windows upgrade) or a straightforward regulatory project (note that some regulatory requirements do evolve in practice, in particular regulations that are “politically charged”). This is also a type of low-risk project.
  5. Transparency isn’t important. Regardless of all the documentation that is generated by a traditional team, the fact is that it’s difficult for senior management to ensure that they have true insight into what is happening on traditional project teams. Another way of saying this is that it’s relatively easy for traditional project managers to mislead you with fanciful status reports and for team members to generate documentation that they believe reviewers are looking for. This lack of transparency is one of the many reasons why traditional teams have a lower success rate on average than agile teams – traditional teams will be in trouble and management won’t know and therefore be unable to guide them out of trouble early on when it is still easy and inexpensive to do so.


What Factors Have No Bearing on When Traditional Makes Sense?

My experience is that the following issues do not have an impact, or when they do have very little impact, on the deciding if a traditional strategy is appropriate for your team:

  1. The domain you’re working in. I don’t know of a single domain where agile and lean techniques are not being successfully applied in practice. Not one. We often run into people that say “Sure, agile is fine for e-commerce, but we work in bank so we need to be traditional” or “Sure, agile is fine for banks, but we work in a retailer so we need to be traditional” or “Sure, agile is fine for retailers, but we work for an automobile manufacturer so we need to be traditional” or “Sure, agile is fine for automobile companies but we work for an e-commerce company so we need to be traditional.” But please, don’t take my word for this. Instead do a quick web search on “Agile software development in X” where X is the domain that you think requires a traditional approach – you’ll soon find that many people have figured out how to move beyond traditional in that domain.
  2. The desire to “get it right” the first time. When getting it right the first time the quality focused, tight feedback cycle approaches taken by Disciplined Agilists are far more effective in practice than the heavyweight traditional approaches. When someone tells you that they require a traditional approach to get it right, chances are exceptionally good they know every little about enterprise-class agile development strategies such as DA.
  3. A desire for “predictability.” Agile approaches, due to their greater transparency, are far more predictable than traditional approaches. The heavy documentation and “quality gates” of traditional provide a false sense of predictability to stakeholders who then get frustrated when traditionalists go over budget, are late, drop significant scope to come in on-time and on-budget, or force stakeholders to accept something built to specification instead of something that meets their real needs. You may find the article Examining the Big Requirements Up Front (BRUF) Approach to be an enlightening read.
  4. You’re working at scale. See next section.


But Isn’t Traditional Better at Scale?

Not really. Agile and lean are as good or better when applied by large teams, geographically distributed teams, teams in regulatory situations, teams facing domain complexity, teams facing technical complexity, and teams facing organizational distribution. Figure 4 depicts a radar chart of potential tactical scaling factors.

Figure 4. Scaling factors faced by software development teams.

Software Development Tactical Scaling Factors

So how does traditional fair in comparison with agile and lean strategies in practice? If you poke around at the IT Surveys page you’ll see that the 2014 Software Development at Scale study found that agile teams outperformed non-agile teams across a range of success factors. Similar results can also be found in the 2006, 2008, 2010, 2011, and 2013 Project Success Surveys. The Dr. Dobb’s Journal 2008 Project Success study found that when comparing agile and traditional approaches based on level of geographic distribution that agile teams were at least as successful and often more so, on average, than traditional teams. In other words, agile was less risky. In 2006 DDJ found that agile was as good or better than traditional regardless of team size, but unfortunately I can no longer find those results online.

To be clear, some of these surveys are a bit long in the tooth. Having said that, in the past few years organizations have figured out how to successfully apply agile and lean approaches at scale.   I suspect that agile and lean will both have pulled ahead even further compared with traditional at scale. We’re actively looking into these sorts of issues so stayed tuned to this blog for future research results. And, we’re not the only ones who are getting these sorts of results. Go poking around on the web and find out for yourself.


Does Disciplined Agile (DA) Support the Traditional Lifecycle?

No, the DA toolkit does not support a traditional lifecycle. We have purposefully left traditional out of scope for DA.

Having said that, we do recognize that in the vast majority of organizations you will have a multi-modal approach where some teams are following an agile approach, some are lean, some are taking a continuous delivery approach, and some are still following traditional. The more disciplined your organization, the more skilled your people, the less likely it is to have traditional teams in practice.


Doesn’t DA Support a Serial Lifecycle?

Yes, but it’s risk-based, not artifact nor activity based as you see with traditional approaches. The two project lifecycles supported by DAD, the Scrum-based Agile lifecycle and the Kanban-based Lean lifecycle, have three phases: Inception, Construction, and Transition. These phases, overviewed in Figure 5, capture the ideas that a project team needs to be initiated somehow (Inception), the solution must be developed (Construction), and then released into Production (Transition).

Figure 5. The phases and milestones of DAD project teams.

When you have stable (long-lived) product teams Inception tends to disappear (with the exception of the need for occasional modeling and planning sessions to think things through) and Transition evolves from a multi-day or multi-week phase into a multi-minute or multi-hour activity. Furthermore, the lifecycle evolves over time as you improve, moving from a phased agile/lean project lifecycle into a continuous delivery lifecycle. More on this in future blogs.

Why Should You Listen to Me?

Here is a brief description of my background in traditional software development:

  1. I spent the late 80s to mid-90s doing traditional development. In fact, two of my books, Process Patterns and More Process Patterns that I wrote in the mid-1990s, describe a CMMI-compliant traditional approach to software development using object-oriented technologies. These books captured my experiences on a range of traditional and quasi-traditional software development projects.
  2. I have significant Unified Process (UP) experience. I have many years of experience with teams following the Unified Process, albeit an iterative methodology rather than traditional one. However, I’ve worked with many organizations that unfortunately instantiated the Unified Process in a traditional manner and then afterwards helped them to recover and evolve their approach into an iterative one and sometimes even an agile one.
  3. Disciplined Agile (DA) leverages traditional strategies. In the DA toolkit we purposefully leverage strategies from traditional, iterative, agile, and lean sources in recognition that great ideas come from a variety of sources, including traditional ones. In other words, Disciplined Agile is a hybrid framework.
  4. I work with customers still doing traditional today. Almost every client of Scott Ambler + Associates (SA+A) is a multi-modal organization that has some agile teams, some lean teams, some continuous delivery teams, and yes, even some traditional teams. Most of these organizations are looking to improve their overall productivity, which typically means they adopt even more agile and lean strategies and reduce their overall investment in traditional ways of working.
  5. I explicitly research the applicability of various approaches to software development. I have been actively surveying, and sharing all of the results of those surveys publicly in a completely open manner, since the mid-2000s. Several of these research efforts focused on comparing agile, lean, iterative, and traditional approaches to software development in an effort to identify where each approach works well and where they don’t work so well. More on this later as well.

The point is that I believe I have sufficient experience with traditional approaches to speak about where it does and doesn’t work. I hope this blog has provided some valuable insights for you.


Have any Question or Comment?

10 comments on “When Does Traditional Software Development Make Sense?

Maybe not relevant to this discussion, but what I have come to understand is that agile methods based on sprints tend to be time-driven rather than scope-driven. I gather that works when you continuously building a product and that features delivered in a sprint can be released. What I wonder about is incomplete functionality in a delivery. I think of an ATM or any banking system where a user defines an amount of money to deposit, picks an account to use, and submits; after that the bank system has to actually update the account balance. You can’t divide this into features and deliver them separately over sprints, you need the whole process. If that takes longer than one sprint to deliver, is it an issue that it takes more than one sprint to deliver usable software?


Very valid comment, David! What I suspect is – Agile is a cop out to lower the pressure on schedule/cost commitments. (As a developer, I would be happy to work in Agile compared to traditional :)). As you said in your example, the Agile team would respond – “Oh, we came across this issue/new task. We will take it up in the next sprint”, and so, sprints keep coming and going with the complete functionality seeming close yet not reached….where as, in traditional, it becomes the responsibility of the architecture/design/BA team to ensure stuff is very well planned out and thought out. Because, you are making them commit to a particular date/effort. As a result, there is added pressure and seriousness on the team. And if something new comes up in spite of careful planning or detailing, team is forced to put extra effort to ensure the timelines are met.


Madhu, interesting points. Sadly the numbers don’t actually bear out your claims. On average agile teams are more likely to provide better value for the money, produce something that stakeholders actually want, deliver in a timely manner, and produce good quality as compared to traditional. These of course are averages, so some traditional teams will do better than some agile teams, but in general agile produces better results.

In Disciplined Agile we explicitly including Agile Modelling practices around architecture, analysis, and design to help increase the effectiveness of agile teams. You generally don’t see that level of maturity in your typical Scrum team, so many people don’t get the opportunity to see how a really effective agile team works in practice.

Thomas Owens

I think it’s very important to remember one thing: the “traditional” waterfall is wrong. The article mentions this, but I don’t think there’s enough weight. In Managing the Development of Large Software Systems, Winston Royce described what is today called waterfall. Figure 2 is a perfect graphical representation of waterfall. Then, comes the line immediately below this figure:

“I believe in this concept, but the implementation described above is risky and invites failure.”

By the time Figure 10 rolls around at the end of the paper, Royce has a pretty good description of iterative and incremental software development. It’s still heavier in documentation and process than what we would consider Agile today. But it’s still iterative and incremental. I think that’s just inherent in the way that software development was understood in the 1960s and 1970s (at least from what I’ve heard – it’s very much before my time so I only know what I’ve been told or have read).

As an aside, I do think that Royce also made one other mistake: he separated design and coding. I think that Jack Reeves, in his articles in the C++ Journal lay out a good case for why code is design. Other people have picked up on this – Glenn Vanderberg gave a series of talks about “Real Software Engineering” where this idea of code is design is a central role.

I think this is one of the strengths of DA. I’m just grabbed the book off my shelf and flipped to a random section – Table 8.1, Comparing Levels of Initial Requirements Details. There’s acknowledgement that your initial requirements can range from “no modeling at all” to “BRUF (detailed specification)”. Different organizations are going to have different needs. But even investing lots of time up front to elicit, analyze, model, and specify requirements doesn’t mean that the requirements are firm and fixed (they probably will change to some degree and evolve over the life of the software component).

I think the arguments for a traditional methodology seem sound, but when you start digging, I think they begin to degrade a little. How do you know that your project is low risk? You may learn in later phases that there is more risk than identified in the project inception activities. Or how do you know that requirements are unlikely to evolve, or that the up-front requirements are actually representative of what the customer wants until they have software? I don’t think that you can be sure that the good conditions for a traditional methodology will be met, so it’s better to set yourself up for success by preparing for iterative and incremental development.

I definitely do agree with the list of factors that have no bearing on if traditional makes sense. I’ve personally seen iterative and incremental work in aerospace and defense, a historically plan-driven environment. It’s a shift in thinking, in project management, in the mindset of developers. But it works. And, as you noted, you get things right sooner and have more insight and ability to understand and adapt to changing schedules.

In the end, I don’t think that we should be considering these traditional sequential methodologies for software development projects. I think that it’s OK to invest more time in some up-front activities – defining a vision, specifying a large set of requirements in great detail, system level architecture. But treating these as immutable is inviting failure. The serial DA lifecycle is one example of a far more appropriate life cycle. I believe that we should all be pushing toward some kind of iterative and incremental approach, at least during the construction activities and have opportunities for feedback into requirements, even in a serial lifecycle model.

Bhawani Singh Jaswal

Couldnt agree more with what has been stated in the blog.


David, there’s a difference between working software every iteration and having sufficient functionality (a minimally marketable release) that makes sense to ship into production. So you, it make take you several iterations/sprints to get to the point where what you’ve built is sufficient.

David Wright

Of course, I have indeed heard of MMR or MMP, thanks for the reminder. … which means I have not actually worked in any agile context, just the types of projects or teams I have worked on/with have not been adopters.

Bryce Reid

One concept that I’ve really embraced from Disciplined Agile is that “context counts”. And with that in mind, I struggle any time I read a comment that is absolute. For example, “Traditional or waterfall doesn’t work”. Sure it does. I’ve been delivering software projects for 15 years and I’ve seen traditional be very effective and efficient. Thomas asked/commented “How do you know your project low risk”. No punn intended, but that’s where we need to be disciplined and critically assess the situation. The way I’ve framed it in the past is that we need to have solid experience in the domain and do the work routinely. For lack of better words, we’ve literally done this before. In the end though, it’s pretty rare that I’d actually suggest BUFP because the ideal situation doesn’t come up.

‘Just enough’ up front work is needed. But, there isn’t a framework or methodology that will tell you how much that is. So, I’ll finish by saying I keep all options on the table and rule them out as I learn more about the context. Because, it counts. 😉

Valentin Tudor Mocanu

In fact, traditional Waterfall it is a kind of accident. Just after the famous picture, Walker Royce said
More: later in the document he said <>, that mean to build a basic pilot, prototype of the system first: <>
So, Winston Royce has never recommended traditional Waterfall with one late feedback. Traditional Waterfall is just copy paste from other industries, domains and works, indeed, only when software development has similar traits with those domains .

Valentin Tudor Mocanu

(my previous comment was cut by text editor)
In fact, traditional Waterfall it is a kind of accident. Just after the famous picture, Winston Royce said “I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. ”
More: later in the document he said “Do it Twice!”, that mean to build a basic pilot, prototype of the system first: “it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort.”
So, Royce has never recommended traditional Waterfall with one late feedback. Traditional Waterfall is just copy paste from other industries, domains and works, indeed, only when software development has similar traits with those domains .


Leave a Reply

Your email address will not be published. Required fields are marked *