by kalzekdor, http://arstechnica.com/information-technology/2014/08/how-microsoft-dragged-its-development-practices-into-the-21st-century/?comments=1

Waterfall of sprints
When a company develops custom web applications for clients, and requirements gathering is KING.

A software development process, also known as a software development life-cycle (SDLC), is a structure imposed on the development of a software product. Similar terms include software life cycle and software process.

---------------------------------------------------
Quality Assurance in the Software Life Cycle
---------------------------------------------------
As any other business investment, Quality Assurance must bring value. The value expected from Quality Assurance is making the software processes more efficient while ensuring that the end-product fits customers' needs. Translated to measurable objectives, that means preventing schedule creeps and budgeting problems; reducing re-work in the requirements, design and construction areas; ensuring efficient discovery and elimination of defects before they reach the end user – in short, making the software processes better and thus making the final product better as well.
In order to be efficient, Quality Assurance activities should follow every stage in the Software Life Cycle. Conflair structures it as a concept of QA Support Ring, as shown in the diagram.
For each activity in the Software Life Cycle, there is one or more QA support activities focusing on ensuring the Quality of the process and of the resulting product. To mention a few:
- Project Plan Review – before you start investing time, money and resources in the project, it's worth checking out whether the plan has covered all the bases, if it's feasible in terms of timeline and resources, or even – simple – if it is complete...
- Requirements Review – once the Requirements are written but before more resources are engaged in translating them into design and code, it's useful to review them for correctness, completeness, testability, etc. - and fix the issues while they are still on paper.
- Pre-release Quality Status Evaluation – you've executed your tests. Defects were logged, and now it's time to decide what to do next: to release or not to release... An analysis of application's Quality level in terms of the impact of the defects discovered can help to make a rational decision based on sound data obtained through Quality metrics.

Having Quality Assurance activities for all stages of the Software Life Cycle can bring significant savings. In fact, the earlier QA is applied, the higher is its ROI. Finding a problem in Requirements can cost ten or more times cheaper to fix than fixing the same issues when found in testing: fighting a paper tiger is easier than a live one...

Test Driven Development (TDD) is a design technique that drives the development process through testing. In essence you follow three simple steps repeatedly:
1. Write a test for the next bit of functionality you want to add.
2. Write the functional code until the test passes.
3. Refactor both new and old code to make it well structured.

Our project timelines usually look like:

Design Stage:
-------------------------
Requirements analysis
-------------------------
Requirements analysis is critical to the success of a systems or software project.[3] The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Conceptually, requirements analysis includes three types of activities:
- Eliciting requirements:(e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering.
- Analyzing requirements: determining whether the stated requirements are clear, complete, consistent and unambiguous, and resolving any apparent conflicts.

- Recording requirements: Requirements may be documented in various forms, usually including a summary list and may include natural-language documents, use cases, user stories, or process specifications.

Requirements Gathering (1~2 week) - We talk to the customer, their users, do research, throw questions at the customer, do more research, and eventually determine a few things:
- What problems customer has,
- how they think they should be solved,
- a priority assigned to each problem,
- and the general development roadmap.


Even before a single line of code is written, there is a logical flow within requirements management, from high-level objectives to business requirements, before they are broken out into the functional and non-functional and passed on to design.

---------------------
Core functionality
---------------------
Start small! Iterate with small increments! Define small essential core requirements and everything will be fine. Additional functionality can always go into "the next release," but if you don't deliver the core functionality, there won't be a next release.

Cutting functionality may seem a drastic measure, but an experienced project manager will happily whittle away functionality as if they were peeling a potato.
Scope creep is the almost unstoppable tendency a project has to accumulate new functionality. Some scope creep is inevitable since, early on, your project will be poorly defined and will need to evolve. A large amount of scope creep however can be disastrous.


Problem Assessment (3-5 days)
- The entire dev team sits down, and goes over the data from the requirements gathering. We assess potential difficulties, analyze problem sets for commonalities, and sometimes throw out requirements altogether in favor of a better solution to address their needs.

Solution Architecture (1-2 weeks) - Most of the major design decisions are made here. Database schemas are designed and normalized, data flow paradigms are established, tasks are defined and distributed. By the end of this phase, the project outline is finished. There are a lot of grey areas still, but the broad strokes and important bits are there.

Development Stage:
After about a month for larger projects, when the design aspects are settling down, we begin developing in earnest. Here we take an iterative approach, at the end of the day, the project should run. If it doesn't, well, that's what branches are for.

We follow the basic pattern: Design -> Implement -> Test for each required feature, starting with core backbone code and working our way towards user facing code as the project goes on.

I'm responsible for defining, assigning, and reviewing tasks (in addition to being lead developer). Every Saturday I go over everything committed to the repository during the week (not exactly with a fine tooth comb, just the general idea), and I use that, plus feedback from my team (and my own experiences), to tweak the task assignments for the next week. Sometimes I see two separate development threads attempting to solve the same underlying problem, so I'll design a component that solves both and converge development efforts.

Deployment Stage:
When the team feels the project is ready for user eyeballs, we'll deploy it to server, schedule a meeting with the client, and sit down with them going over it. We ask them to have people start using it, and gather feedback from them.
We then use that feedback to address any problems or shortcomings in the project, and address them. This may take a few iterations, but eventually the client signs off on the software, and we enter Maintenance.

Maintenance Stage:
For the first 30 days after sign-off (longer if they purchased extended support) we provide free bugfixes, feature changes, tweaks, etc. If we did our jobs right during Design, any change they need is usually trivial to implement.
After their complementary support window ends, we offer free major bugfixes (breaking errors, security issues, etc.) for 6 months. During this time we also offer low-cost change requests.
Most of the waterfall horror stories come from teams led by a manager who has no firsthand experience with software development. The view from the trenches is usually enlightening.

I guess you could call our overall approach as a waterfall of sprints.
The key is to be able to anticipate customer requirements, and have the architecture in place to easily implement their requests, or other unforeseen changes.
Agile is NOT a software development methodology. It's just a project management technique. Agile has absolutely nothing to do with building good software; good software designs and code have everything to do with it.