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.
- 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.
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.
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.
- As a power user, I can specify files or folders to backup based on file size, date created and date modified.
- As a team leader, I need to see the performance of use of my team members, so that I can have a conversation with them about their performance.
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)
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.
Thank you!
EDIT: Special thanks to Stéphane Bagnier from Pocket Sensei, for his time reading this article, and advice about value-driven delivery.
