Nigar has just joined the Prowid Shop team as a junior developer — an online shop built by a small team of five. On the first call Murad says: “We work in an Agile way, two-week sprints.” Almost everyone has heard the word “Agile”, but not everyone can explain what really stands behind it. In this lesson we look at why Agile appeared, how it differs from “waterfall”, what the Agile Manifesto actually says and which myths to avoid. The next lessons of this section cover Scrum, Kanban and a developer's workflow; for now we build the foundation they all stand on.
Meet the Prowid Shop team
In every lesson of this section we look at work through the eyes of the same team:
- Leyla — Product Owner: responsible for what to build and in which order, so the product brings value.
- Murad — Scrum Master: makes sure the team works well and removes obstacles.
- Aysel and Kamran — developers.
- Nigar — the new junior developer; in our examples “you” is her.
The characters are fictional, while the situations are typical for real teams — including companies in Baku and remote work.
How it used to be: waterfall
For a long time software projects were run like construction: think everything through first, then build. That model is called waterfall, because the work “flows” down through phases:
- Requirements — collect and record everything that has to be built.
- Design — draw the architecture and the screens.
- Implementation — write the code.
- Testing — check that everything works.
- Release — hand the result to users.
Each next phase starts when the previous one is finished, and going back is avoided because it is expensive. For a bridge or a building that really makes sense — once the foundation is poured you cannot rearrange the floors. But a program is not a bridge.
Imagine Prowid Shop built this way. Three months for the specification, four more to build the shop, one month of testing, and only at launch does Leyla show it to customers for the first time. It turns out most customers want to pay in cash on delivery, while the spec only had card payment. Now you have to fix something already woven into dozens of places.
| Problem | What happens |
|---|---|
| Late feedback | A misunderstanding shows up months later, when everything is already built |
| Expensive changes | The later the fix, the more finished work has to be redone |
| Risks pile up | Integration and testing come at the end, together with unpleasant surprises |
| The world changes | Requirements fixed in January may be outdated by autumn |
💡 Waterfall is not “evil”. When requirements are known and stable (for example, strictly set by law or contract) it works. Trouble starts where there is a lot of uncertainty, and product development almost always has plenty.
