My company is going full steam with the agile process, with multiple agile projects in work. The first agile team, the proof of concept, carried the product through release and the first post production release.

After this successful effort, the team was quickly disbanded, sent off to help other projects on their agile way. My disillusionment with agile comes from third and later release stage of the software life cycle.

Agile is good at pulling expert and building moment, getting all excited for a project, but how do you wind down a project and move it stage where existing customers must be kept happy, to keep paying for all that early agile fun? If you will, the party is over, and this light on documentation, don’t design it till you need it, and keep racing to the next sprint leaves little documentation, little vision, and poor records of why design decisions were made. This stage of life also has little interest in the initial agile developers, as they are done with that project and are off looking for new exciting teams to start.

I understand, and have lived through waterfall of the problems with long term planning, schedules being missed, and requirements being out of date, but for part that was usable and accepted by the customer, there is information and distributed knowledge of why decisions were made, what steps were taken, and something more supportable in the end.

Basically, what does an agile team need to be doing, what must it do, what must be deliverable, for an agile project to be successful, with success being defined as a sustainable, maintainable, and hopefully revenue generating product?

If the agile software we build cannot be maintained, in a couple years agile will just be another broken promise, which business managers will not pay for, allowing them to go back to the old, micro-manageable waterfall process.

  • 4
    There is no silver bullet!
    – Peter K.
    Aug 20, 2013 at 1:22
  • possible duplicate of How do you balance documentation requirements with Agile developments
    – gnat
    Aug 20, 2013 at 2:43
  • Success being defined as a "sustainable, maintainable" product seems too narrow. What if you discovered that your goals could be achieved with a quick hack that needs very little maintenance? What if your goals could be achieved with no product at all? I'd call those great successes. Aug 20, 2013 at 6:28
  • Just curious, why is it a completely different group of programmers working on the later stage of the project?
    – Owen
    Aug 25, 2013 at 1:42
  • It had been planned, but not explained to the whole project, that the development would be reassigned when the project was over. That plan was carried out, so a new programmer (me) was brought in with a little overlap with the last developer on the project. Again, as others have pointed out, this was a mistake.
    – Scott S
    Aug 26, 2013 at 15:43

3 Answers 3


I think what you are experiencing is very similar to many other teams who first transitioned to Agile. In my last company when we were told to be agile, almost same thing happened. This article about Cargo Cult Agile Methodology might resonate with some of the things you've probably experienced in your pre-1.1 era. The point is that you cannot simply follow rules/guidelines written down without taking a step back and considering what is really important for your team and your specific situation.

The key is that Agile methodology never said that you cannot have documentation. It just seems that way because it eliminated 90% (if not more) of documentation when compared with waterfall. And that's a good thing, but some teams, take "no documentation" a bit too literally and go too far, eliminating 99.9% of documentation. Then they turn on agile as the cause of undocumented product.

I just did a google search to find this article on agile/lean documentation and ended up finding another question with my answer from a year ago that touches upon this same topic. The bottom line from whatever I wrote there is that I believe design docs are important, but for organizational memory and only when kept at a high enough level. They are almost completely useless when written prior to code.

Same goes for vision and long term direction. Agile methodology suggested that big upfront design is bad. And what they meant is that don't attempt to "sketch out" every nut and bolt of your application using words and then try to code all that up. That doesn't work. But many teams, my own included, took that a bit too literally and when starting new projects they would jump right into coding without defining overall architecture or coming up with overall rough picture of what final product should look like. Bottom line is that in Agile you should have just enough documentation so that it helps you to go forward and makes you more efficient (i.e. come up with a vision so the team can work towards a common goal and not have to go back and redo work) but don't create documentation just for the same of producing volume upon volume of design specs that a) no one will ever read and b) will become completely obsolete even before software ships.

At it's very core Agile is incredibly simple. It's about short iterations, eliminating waste and continuous improvement. You should constantly review what wastes your time and makes you less efficient and fix it. If the team sees that they just spent 2 weeks producing documents and those documents are not needed by anyone, that's a waste. However, if the team sees that they are being slowed down by customer calls and their own inability to understand the code that was written, then possibly lack of documentation is the waste.

  • Very good answer (+1). Regarding upfront design: For some agile enthusiasts "less upfront design" means "no design". So agile is just a way to justify their inability to do any design and let them just sit at the computer and start coding.
    – Giorgio
    Aug 22, 2013 at 8:34
  • Good point: lack of documentation is not a goal of agile -- the goal is eliminating waste, and less documentation tends to follows as a consequence.
    – Owen
    Aug 25, 2013 at 1:49

What you were doing was not agile, lets go over your points :

  • light on documentation - Agile is not about "no documentation". It is about creating code that doesn't need documentation and only creating documentation that is necessary.
  • don’t design it till you need it - In agile, this doesn't mean anything. Just because you are designing later, doesn't mean you aren't designing at all.
  • keep racing to the next sprint - Agile is not about racing to the next sprint. Major point of agile is to create steady and sustainable development pace. So no matter how big or complex the software gets, the team can add new features and improve quality at same rate as year ago.
  • leaves little documentation - Again, agile is about having team decide what documentation they need for their work. Major problem with other methodologies is that it is someone else who decides what documents are needed, thus quite often documents give more problems than they solve.
  • little vision - Which is wrong. The developers themselves don't really need long-term vision. But at least product owner should look year or two into the future and imagine what kind of software they want. There is no need to burden developers with so many what-ifs.
  • poor records of why design decisions were made - In agile, these records exist in code, developer's memory and documents team created, because the decision was so complex that team decided to record it.

So to answer your question : You cannot be disillusioned with agile, when you never did agile.

  • "The developers themselves don't really need long-term vision.": In my experience long-term vision avoids so many problems later.
    – Giorgio
    Aug 22, 2013 at 7:34
  • @Giorgio This "vision" can be double-edged sword. It can help somehow, but if developers try to implement every what-if scenario they will end up with codebase that is needlessly complex. YAGNI is what agile should be about.
    – Euphoric
    Aug 22, 2013 at 8:43
  • I agree with you (and I am a big supporter of YAGNI and KISS): too much upfront analysis is not good; no upfront analysis at all can be as bad. I think with experience you can find a reasonable compromise.
    – Giorgio
    Aug 22, 2013 at 9:22

Disillusionment comes from having illusions :-)

My take (wearing Scrum glasses) on these issues are that they are

  1. Mainly caused by a poor "definition of done". If a later sprint needs to clean up after the current sprint, then to me that says that the sprint did not finish it's work.

  2. Contributed to by breaking up a successful team. This is one of the classic methods of stuffing up a product.

To me, a key feature of agile is to maintain a sustainable pace. This comes from knowing the team's velocity, what they can achieve in each sprint. Big changes to the team means big changes in the reliability of past velocity as a predictor of the future. That sustainable pace includes maintenance, and also implies that there is no sudden cut-over.

Teams will, of course evolve, as people come and go, and skill requirements change. But disbanding the whole team makes me shudder.

  • +1 for the disbanding part. You can't just tell the entire team to move along and go about other businesses and still expect the project to continue as if nothing happened. Aug 20, 2013 at 10:11

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