AGILE AND WATERFALL

I want to talk about Agile as early as possible because it is foundational knowledge. You need it to understand what the work process looks like; you only really understand it once you have joined an Agile project.

The diagram above is an Agile diagram. If you see it for the first time, you probably will not understand what it is. Agile diagrams need an explanation alongside them—usually someone standing there talking through the process. Today I will be that person.

The concept

Waterfall

To understand Agile properly, let us first say a little about Waterfall. Waterfall is a development model that was used extensively in the past. At its heart, it is the original application of SDLC—or, more precisely, a way of putting SDLC into practice with very few design changes.

Here is a comparison between SDLC and Waterfall:

You can see the difference at a glance: one is a theoretical chain of activities, while the other is a chain of activities to be carried out in practice.

They are the same thing, then?

You don't say.

Exactly. That is why I said Waterfall is the original application of SDLC: it takes SDLC's theoretical basis and changes as little as possible in the technical design.

Waterfall has these characteristics:

1. It goes from top to bottom, one step at a time, skipping no step.
2. Each phase normally has to be completed and approved before moving on. Going back is possible; the later you go back, the more painful the cost.
3. Waterfall fits better when scope and requirements are relatively stable and the output of each phase needs tight control.
4. Project size does not decide whether to use Waterfall or Agile. Context, contract, risk and organisation do.
5. A Waterfall product can still be upgraded after handover. The difference is how change is organised, not a ban on adding features.

Typical question: What is the Waterfall model?

How Agile differs

It would be too much to say Agile was created simply to patch Waterfall's weaknesses. It is fair to say that Agile emerged from the needs of modern software product development.

Agile is also a way of applying SDLC in practice, but with a particular design. Instead of going through SDLC once, Agile does it many times:

Agile splits the product into many small parts and the development process into small iterations, or sprints, to build those parts. Each iteration is a complete process:

1. Planning
2. Developing
3. Testing
4. Demonstrating to the customer
5. Deploying to the customer (possibly)

Each iteration develops one or a few features. Over many iterations, the product gradually becomes complete.

Agile therefore has these characteristics:

1. Each iteration is a complete development process for one or more features of the final product.
2. Agile allows later changes to features and code by adding requirements and handling them in a future sprint.
3. Agile accepts changing requirements and uses feedback on each small part to adjust.
4. Small and large projects can both use Agile if the team genuinely works iteratively and incrementally; a large project does not become Agile automatically.
5. Each iteration should create a usable increment. Whether to release it immediately is a separate decision.

Typical question: What is the Agile model?

Typical question: What are the differences between Agile and Waterfall?

Typical question: What are the advantages of Agile? What makes it special?

Agile in more detail

Back to the diagram, but with the ideas filled in:

The full idea of an Agile process is:

1. The Product Owner maximises product value and manages the Product Backlog. The PO may write backlog items or work on them with the BA and team.
2. A Business Analyst may analyse and clarify requirements and business rules, but Scrum does not require a BA role.
3. The Product Backlog is an ordered list of product work. It is not merely a place to throw “technicalised” requirements and leave them there.

Then the iterations begin:

1. In Sprint Planning, the Scrum Team discusses the sprint goal and selects suitable Product Backlog items. Developers plan how to turn those items into an increment.
2. Scrum does not reserve planning for a “higher level” position. If a manager or lead attends, they still should not turn Sprint Planning into a top-down task-allocation meeting.
3. The project team works on the requirements: developers code, testers test, and so on.
4. At the deadline, or when a stop-testing condition is met, the product is shown to the customer.
5. After the final steps, the product is handed over to the customer.
6. The project team meets and learns from the work.

The Scrum Master helps the team understand and apply Scrum, removes impediments and improves the way the team works. Sometimes they really do schedule meetings or book rooms, but that is secondary; a Scrum Master is not a meeting secretary or a supervisor watching every person.

For more on stop-testing conditions, read Test Plan.

For more on how a tester takes part in Agile, read Test Process.

Some events in an Agile process deserve a note:

1. Planning phase: the planning described above.
2. Daily Scrum: a 15-minute event for Developers to inspect progress towards the Sprint Goal and adjust the plan. The team can talk more afterwards, but do not count a one-hour follow-up as the Daily Scrum.
3. Review phase: the customer demonstration described above.
4. Retrospective: at the end of the sprint, the team reviews what it did well and what it did poorly so it can improve later.

In my experience, Retrospectives are often skipped or happen in a very brief, informal way—people exchange messages by email or team chat.

Typical question: What are the events in Agile?

Typical question: What is the role of a Scrum Master?

Typical question: What is the role of a Product Owner?

References

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1