Why Agile is better for getting your app or website delivered

Adrien Joly
Jan 20, 2016 · 4 min read

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.
  • Understanding of needs: A developer translates his understanding of the client’s specs into a computer program. Two biases are implied: the correctness of the spec provided by the client, and the understanding of this spec by the developer. If you don’t realize and solve these biases before the final delivery of the project, the complete project will NOT be released on time, and a lot of frustration and anger may arise from this situation.
  • Temporal uncertainty: Projects are various, so it’s impossible for a developer to predict the time it will take to implement the project with 100% accuracy, because some technical problems can unpredictably increase the duration of development.

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 , I can .
  • As a , I can
  • As a , I need , so that .

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.

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.
  • It makes it impossible for a development team to comply to a budget in advance, except the cost of a sprint. Indeed, the price of development will depend on how many sprints the client wants to “buy”.
  • It also requires the client to be available to the development team before, during and after each sprint, in order to clarify user stories and take decisions in case of unexpected events. (e.g. a user story is more complex to develop than expected)

But the client gains the following benefits by embracing Agile:

  • No “tunnel effect” (bad surprises after months of development);
  • Value-driven delivery: user stories that bring the most value to the client are developed (or even released) first => “First release in two weeks”Thibault Jouannic);
  • Flexibility towards evolving business objectives and constraints;
  • Control: possibility to interrupt a development team early, while still having something useable developed by the team at the end of the sprint;
  • Conflicts much less likely to happen between client and developer(s);
  • Much less specification, documentation and Q&A has to be done before starting 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.

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

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store