I've been working for a year now in an agile project to redesign an insurance application. I really like working in an agile environment, although management and analysts I work with still have waterfall thinking ingrained and makes it a little complicated to embrace the new paradigm shift to agile.

From a developer standpoint sometimes I feel like since we're doing "agile" we don't over-think or think enough our designs and just go with the flow and refactor later. Many times that ends up in rework because we never put enough though to certain pieces of the application. As far as I understand, agile is like having small waterfalls and deliver small pieces at a time (iterations), but sometimes we lose the big picture and end up paying for it later with rework.

Are agile methodologies encouraging or tolerating procrastination more than traditional waterfall? Is this constant rework for pieces of software with defined requirements acceptable?

Is anyone else experiencing something similar in their projects?

  • 1
    As a developer, I have been told by business folks that I should not do any design, requirements spec, or documentation at all because it's not agile. Somehow, agile has gained a reputation of being a "get it done" cowboy methodology. Business managers love that because from their perspective, they get more functionality sooner for less cost.
    – Brandon
    Jun 26, 2014 at 12:42
  • Waterfall is the name of the methodology used before methodologies even existed. While agile is by no means perfect, waterfall continues to embrace the idea that if you concentrate hard enough, you can really and truly write a program right the first time, which is complete bs. It might as well be the mythical man-month we're talking about for all the accuracy it upholds. Yet you still see it, and I believe this is primarily due to the ignorance of those who think the old way must be the best way.
    – Neil
    Jun 26, 2014 at 12:45
  • 1
    Related(not dup) question: programmers.stackexchange.com/questions/119006/… Jun 26, 2014 at 14:13
  • 1
    Thanks everyone, very interesting points of view. I liked the term AgileFall @Chad agile-fall.blogspot.com/2010/03/what-is-agilefall.html Jun 26, 2014 at 14:31
  • For what it is worth I found that following agile actually lead to more efficient solutions because rather than rework dramatically you look for solutions to solve the problem given what you have. What seemed like the best solution from a distance turned out to not be the best solution when it is time to deliver. Jun 26, 2014 at 14:43

5 Answers 5


Part of this is expected and good, part of this is not, and we can't really tell you which is which.

The main focus of agile is delivering what is important now, based on what you know today. Take a little bit of time, implement this important bit and ship it so that you can get feedback on it sooner rather than later. Some of that feedback will be "ugh, this actually kinda sucks in practice!". This is the good sort of rework that agile promotes. Since you caught this early, you can fix it early.

The other side of this is that what is important to business people is rarely important to developers. As developers, you need someone to advocate for technically important things like infrastructure, training, and technical debt. This can help eliminate some of the "gaps" missed by most agile environments. But in the end, the discipline to do a good job rather than just slapping together a solution will fall on you the developer - agile or not.

  • "important to business people is rarely important to developers" don't you mean the opposite? What is important to developers (technical excellence) is rarely important to the business
    – Pete
    Jun 27, 2014 at 7:51

Although agile is based on a minimum viable product and only delivering what you need, it is also based on making the best decisions you can with the information you currently have.

This means not only considering the user story you are working on, but what you know is coming, or likely to come. The correct time for design is whenever you need it - considering dedicating time to design when you think something you are doing might cause a problem in the future.

To me agile does not encourage procrastination or delay of design decisions, it allows you to remove the huge overhead of system design at the start (which is never right anyway), and integrate it into the project as and when it is necessary.

There is always going to be a degree of re-work in software and there will always be unexpected things cropping up, but if as you say the requirements are well defined and truly unlikely to change, you can consider them in design relatively early on and may still spend a reasonable amount of time on design work at the start of the project. This can be considered as part of 'sprint zero' as well - basically planning a framework for the project.


In the agile setup I am working with,It is what the team wants.The definition of team here does not include managers and business folks.I agree this may not be possible if you are working in a place where business people have a more say at technical issues.

In our case if the team feels that some feature needs a design discussion, we do come up with design documents and nice block diagrams.But this is sometimes an overkill for certain features and makes more sense to get it over with as quickly as possible.

It might help to have a tech person experienced with agile workflows to steer demos and retrospective where the respective business person can also participate and understand what working in agile actually means.

Every team is different so It is up to your team to figure out what is best for you,And I feel agile lets you do that more easily than other models open communication opportunities with demos,retrospectives which sparks discussions and improvements.


Agile its not about not designing, agile its about designing all the time!

In waterfall design is constrained to one phase, then programming, then testing... in agile you are designing/programming/testing all the time. If your problem its that your are taking poor design decisions that compromise the future extensibility or maintainability of the application learn from this mistakes and try to take better decisiones the next time.

but in agile you have a lot of time for designing, in fact, all the time its for design.


All mature engineering disciplines include a design/systems engineering style phase (or multiple iterative phases).

The problem with software is that the design space is not as constrained as most engineering problems, so there is a lot of uncertainty/many ways to accomplish an engineering task, this is why Agile was developed.

Agile is good for some things, like customers who want websites, but don't really have a good idea of exactly what website they want.

Test driven development (TDD) and Agile, are however, poor (or poorly implemented) at other things, especially things which require actual engineering like :

  • Mathematical modeling
  • Algorithms
  • Constrained or task specific systems
  • Mission critical systems

etc. Any engineering solution requires some iteration, this includes disciplines outside of software, but we absolutely cannot disregard design entirely. Design is necessary to achieve efficient, robust, and scalable solutions.

Agile has been useful for the problem spaces where constraints are not defined or are not even known, but even in these situations design still needs to be included in the iterative process. Recently I have encountered what I consider to be too great of a swing to minimize all design, and this is especially prevalent among Agile evangelists in my experience.

A parable of what can go wrong if you swallow too much Agile/TDD koolaid : http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html

  • 2
    You link at the end is total garbage, written by someone taking things out of context (at the end). Also, agile doesn't mean not doing design - it means not doing full design up front. Just to add : I have seen waterfall and v-model implementations done very poorly. Jun 27, 2014 at 8:05
  • Waterfall is just as bad as extreme Agile...but I have never met anyone who does "waterfall." Most good engineers take a hybrid approach...like I said, some people take it too far, i.e. they drink too much of the Agile koolaid, I'm not saying it isn't useful at all, I'm saying you really do need design as well as iteration.
    – daaxix
    Jun 27, 2014 at 19:16
  • @BЈовић, whatever the spin in the blog, TDD utterly failed at the proper implementation of a Sudoku solver, this is not how you write good software, go read Jeffries' TDD code...
    – daaxix
    Jun 27, 2014 at 19:29
  • I do not know python that well to read it, and say whether it is good or not. Anyway it also depends on the developer. Last thing : maybe TDD wasn't right solution for that problem. Jun 28, 2014 at 6:57
  • Exactly my point. Not all problems work well with heavy agile/TDD solutions.
    – daaxix
    Jun 30, 2014 at 3:38

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.