Why Agile is better for getting your app or website delivered

After months of freelance software development, I realize that some of my clients and prospects use the Agile/SCRUM terminology (e.g. “sprints”), while expecting a process that looks more like the “waterfall” methodology: having to release a full product at a fixed date, given a specification of how the final product should look like (i.e. wireframes, designs).

I have worked on several waterfall projects. Sometimes, it’s great. E.g. for small, simple projects without technical uncertainty. Other times, it implied frustration on both sides: my client was frustrated because I could not deliver on time, I was frustrated because some of the required specs were not provided on time or the client changed his mind… In both cases, I ended up working twice the expected time, for the same price, because I did not make my process clear with my clients at the beginning.

I totally get that it’s reassuring for a client to think that a development team can transform a spec into a perfect product in a given time, and for a given amount of money. But, let’s face it, the story is rarely that simple:

  • Planning: The clients’ objectives usually change over time. If the developer(s) already implemented parts of the solution that need to be changed, the client will often refuse to pay more for applying this change.

That’s why Agile methodologies propose to specify, design, implement and release iteratively.

Waterfall VS Agile (2m45)

In order to prevent the problems I listed above, the Agile methodology advocates to define “Sprints”: 2–to-4-week bursts of development.

The goal of each sprint is to deliver a part of the product that implements a set of “user stories” (i.e. a subset of the specs defined with the client at the beginning of the sprint), and that can be tested, or even released publicly in some cases.

Waterfall VS Agile (1m30)

In Agile, user stories are the unit of development. A user story is a small piece of functionality, a very small subset of the client’s needs that converts into a feature of the software to be developed.

A user story defines who can do what, and why. Examples:

  • As a user, I can backup my entire hard drive.

Those stories are discussed with the client before being turned into development tasks.

They make a great description of what functionality should work at the end of the sprint they’re part of, and hence to test the implementation delivered by the development team.

EDIT: Another important benefit of defining user stories that are self-contained and independent from each other: the client can decide which user stories are to be developed first. The recommendation of Agile methodology is simple: users stories that bring the most value to the client should be done first. (value-driven delivery / pilotage par la valeur)

Sprints and User Stories (3m30)

Disturbing effects of the Agile methodology for clients include:

  • It makes it impossible for a development team to comply to the delivery of a final product for a given deadline. Indeed, there is no such concept as “final” or “complete” in the Agile methodology; if not talking about one single particular sprint.

But the client gains the following benefits by embracing Agile:

  • No “tunnel effect” (bad surprises after months of development);

I still consider myself a young freelancer and Agile practitioner. So I’m very open and grateful towards any experience feedback, different point of view, advice, or correction you may give, by commenting or replying to this post.

Thank you!

EDIT: Special thanks to Stéphane Bagnier from Pocket Sensei, for his time reading this article, and advice about value-driven delivery.

Web software development × personal development. https://adrienjoly.com/now 🚀

Web software development × personal development. https://adrienjoly.com/now 🚀