I work for a company that, in my opinion, should be doing all of it's web development work in a fully agile manner. We have vague, competing ideas about the product at any given time. And we have strict deadlines. So, in the web arena it seems to make sense to operate in as agile a manner as possible.

However, I could conceive of projects on the business apps side -- or even a complex sub-project on the web side (integrating with a pre-existent 3rd party app?) that, at least for the sake of argument, isn't at all changeable in scope. The scope of the integration piece would, for all intents and purposes, be fully specifiable up-front with zero chance for change.

In general, is it acceptable to take project X in an organization that is normally attempting to achieve agility and work through it in a waterfall manner? Does it somehow compromise the agility of the organization on a whole? If the organization is truly trying to be agile, should the "rigid" project still be "managed" in an agile manner?

  • How big is the organization? How varied are the projects?
    – SJuan76
    Commented Jul 28, 2014 at 17:12
  • We have 1 developer on the business side, 3.5ish on the web side. The organization as a whole is around 50ish. But ... I'm hoping for an answer that's more generalized -- What's the "best" answer as the organization grows?
    – svidgen
    Commented Jul 28, 2014 at 17:14
  • 1
    Comments should address the post they are attached to, and not be used to carry on a conversation. Please consider taking any extended discussion to our chat room, The Whiteboard.
    – Thomas Owens
    Commented Jul 29, 2014 at 18:31

4 Answers 4


There's a very serious problem with choosing a methodology on a "per-project" basis, which is that most Agile methodologies reject the notion of projects.

A project implies fixed scope and fixed time, and for many of the more dysfunctional organizations, also a fixed budget. This is anathema to every methodology out there.

Every role, every tool and every ritual in a process like Scrum centers around the product - not a "project". You have a product backlog which states what must be done and in what order (but not when or how). You have a product owner who chooses what goes on the backlog. You have product demos or showcases to inform the business of progress. You have product releases and iterations. Even your very first release is called the "Minimum Viable Product", and it's not intended to be the final release.

The closest analogy to a traditional "project" would probably be a single sprint/iteration/cycle, because at the end of a sprint, your team should have come up with one or several meaningful improvements to the product that deliver some measurable business value. If your team isn't doing this, your team isn't Agile in the capital-A sense of the word. If your team isn't dedicated to a single product (or maybe a small suite) then it isn't Agile. If people outside your team dictate requirements or deadlines to your team, then your business isn't Agile.

I am not saying that you have to be Agile. What I am saying, however, is that you can't really pick and choose. Most of the "good" Agile methodologies like Scrum include process improvement as part of the process itself (i.e. retrospectives and post-mortems), thus I am also not saying that your process should be static. To the contrary, unless everything went absolutely perfectly during your last few sprints, you should probably be tweaking the process. But Agile processes are processes for continuous delivery, and if you switch to "project" mode at any point, then you're throwing away the continuous part and you might as well just stick to a more traditional project-management process. Not waterfall, which was broken even according to Royce, but something more formal like the RUP.

In general I would say it's OK to have some Agile teams and some non-Agile teams/projects if they are different teams. I've seen what happens when businesses try to shoehorn waterfall projects into an Agile team/process, and rest assured it's not pretty; at best it seriously hurts the quality and timeline of both goals, at worst it will drive the team members so crazy that half of them quit. Avoid, if possible.

  • Lots of great insight here (+1). But, I'm not sure it answers the question. You start by sort of suggesting that agile methods aren't per-project methods, and eventually say that waterfall projects should be run through an agile team or process ... What's the main point here? That both can be done? But, keep the teams separate? What sort of "steps" occur, in your experience, that lead to the quality + deadline issues?
    – svidgen
    Commented Jul 29, 2014 at 14:02
  • @svidgen: Huh - when did I say that "waterfall projects should be run through an agile team or process"? I thought I said the exact opposite. As far as what causes the quality/deadline issues, that's covered in a number of other questions here, but in brief: (1) Agile estimation methods aren't suitable for L- or XL-sized projects; (2) Agile methods rely on adjustable scope and don't work with fixed-scope projects; (3) Agile requirements management depends on a feedback loop throughout a product's lifetime, not a "requirements phase". There are other issues but they won't fit in a comment.
    – Aaronaught
    Commented Jul 29, 2014 at 15:45
  • Oops -- Typo on my part -- I meant to say that you said they shouldn't be.
    – svidgen
    Commented Jul 29, 2014 at 15:47
  • @svidgen: And, incidentally, genuine waterfall projects shouldn't be run through any team or process - they shouldn't exist, period, because the model is irreparably broken. See my comments in other parts of the question - there are "working" waterfall-like models, such as Spiral and RUP, but true waterfall (AKA "traditional project management" or manufacturing project management) simply doesn't work.
    – Aaronaught
    Commented Jul 29, 2014 at 15:47
  • Sure. I'm using "waterfall" to encompass all waterfall-like methods. Nevermind that the term is generally loaded to describe a process as "broken." There are still projects that are inherently design-up-front-and-come-back-when-its-done projects. Most modern software isn't like that. Some is.
    – svidgen
    Commented Jul 29, 2014 at 15:50

I don't see the benefit of trying to do everything the same unless you're willing to turn-down projects that don't fit your particular model. Otherwise, you get a bad fit and the client isn't going to be happy either way.

If you're so sure you know the specs in one case and are very confident they won't change, you can still run it as an agile project. Just because Agile is better when specs are vague, doesn't mean it is useless when they are solid.

Keep things as consistent as possible so you can have members work on different projects without too much adaptation of the general method. People are better at making adaptations when they fully understand what it is they are adapting; otherwise, it's just chaos. Of course, this assumes all your clients are willing to work under an agile methodology.

  • I might be inclined to agree. I'm not sure that answers the question though. Consider a project that one might consider "inherently waterfall." You have N components with predefined, permanent specifications, and the most efficient way to build the solution is to have N teams stub out the interfaces and build the components in parallel. You could conceivably run each component as an agile project, but that's largely beside the point of the question. The question is ... if this project is done waterfallishly, does that noticeably harm company culture or introduce complications?
    – svidgen
    Commented Jul 28, 2014 at 21:06
  • ... and we're assuming in this scenario that, while the teams are equally capable of running a waterfall project or an agile one. The question is, are there be complications on an organizational level of mixed-method development? ... I know the agile dogmatists would suggest that "the whole organization" needs to be agile. But, given someone who has successfully participated in both an agile team and waterfall team and is not dogmatic either way, what would they say?
    – svidgen
    Commented Jul 28, 2014 at 21:07
  • @svidgen - I'm not sure this question has a single answer, but more of things to consider when finding a solution for a particular company. You're more inclined to find developers who are more agile or waterfall than any particular project. It is better if the entire organization is on the same page regardless of methodology. What percentage of waterfall projects assumed they would never, ever change the specs and did?
    – JeffO
    Commented Jul 29, 2014 at 13:41
  • That lingering question is the reason that my coworkers and I pushed hard for an explicitly agile methodology (which is what our waterfall projects usually in-explicitly turned into by the end). That said, we have internal software projects (usually systems integrations) wherein the specifications are well-confined. Does it make sense for some of those "side-projects" to do our planning up front, go into the cave, and turn around in N to M months with fully functional software? Or ... does that harm the culture in some way? Or risk tainting VP's perception of development or something ..
    – svidgen
    Commented Jul 29, 2014 at 13:54

Agile vs Waterfall its not only about have a set requirements up front. There are other agile values aside from responding to change, for example:

  • People more important than process.
  • Deploy software that works in short iterations.

If your company is agile i cannot see how you can abandon this agility for one project, agile its much more about a mindset and core values than about concrete practiques. If for a project do you have solid requirements that don't change you can still work on this projects with your agile values and mindset. Go in small iterations, empower your team, show software that works frequently... with agile you are prepared to change, if change don't appears you are off course prepared to this too.

  • 1
    I don't see how a waterfall approach is necessarily less people oriented. The agile manifesto explicitly says "we're about people and working software" and so forth; but that's not all it's about. Nor is waterfall explicitly not about people or working software -- you could equate "short iterations" to "milestones" in a waterfall project.
    – svidgen
    Commented Jul 28, 2014 at 21:00
  • ... I don't mean to criticize your answer. But to clarify the question. I'm not talking about aspects of either. I'm talking whether an organization can be "fully committed" to .. say .. Scrum on one project and waterfall on another. Set aside any bias the waterfall doesn't work, doesn't deliver, or isn't about people.
    – svidgen
    Commented Jul 28, 2014 at 21:02

In my experience, most organizations use a mix of the processes that work best for it and its customers (business). While Agility is an organizational goal, that does not mean ALL its software projects need to be run using an Agile method (Scrum or others). Agility means being able to respond to change quickly and still deliver quality products and services that meet the customers' requirements and thus organizational goals. That can be achieved with a variety of methods and approaches by the organization.

I would rather ask the question - what is the problem that you are trying to solve? Is there a problem? Does the solution require changing or examining your software development processes? Is the solution to that problem to get everyone on the same methodology?

Even so, I can assure you that most organizations today have 'agility' as a business goal in some fashion or the other - AND work with a variety of software development methods depending on the needs of the customer, the nature of the project and the skills and maturity of the team involved.

Hope that helps!

  • 2
    "a mix of processes that work best" - ah yes, the good old water-scrum-fall, the conceit of non-technical business managers thinking they can cherry-pick the parts that look good or easy and discard the rest. Don't get me wrong, there are other valid processes (like the RUP), but most companies that do what you're saying haven't even tried to follow the process precisely, and usually the dev team limps along pretending to be agile while still bending over to meet definitively non-agile fixed-scope deadlines.
    – Aaronaught
    Commented Jul 29, 2014 at 2:30
  • @Aaronaught, not at all. The project team picks the process that they think will work best, in consultation and agreement with the customer. Just because you have multiple processes in an organization, does not mean each project is using ALL the processes in the organization. The team should be able to decide what process works best for it's situation. Commented Jul 29, 2014 at 3:37

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.