Understanding the Agile Process from the Client Perspective

The Agile development methodology was formalized in 2001 and has become the leading process for software creation. Developers love the flexibility it gives by not requiring that everything be figured out up-front. But as a client, how can you feel comfortable signing a contract without already knowing exactly what you will get?

First some background

Classic software development involves a sequential process:

• Requirements – define the problem and solution in complete detail.
• Design – create the blueprint to implement the requirements.
• Construction – build the system based on the design.
• Testing – confirm what was built works as specified in the requirements.
• Implementation – launch!

This process is commonly referred to as “waterfall” because the output of each phase flows into the next.

At first glance this seems like a very reasonable approach. The requirements represent a complete description of the work that will be provided, and serve as the contract between the client and the development company. Expectations are clear and both parties are on the same page.

Why wouldn’t we always want to do that?

The problem is that software is intangible and complex. Words on a page don’t always capture and communicate the essence of what is desired. Even a very clearly stated requirement can be interpreted and built 100 different ways, and it is likely that at least 95 of those won’t be satisfactory. The result is a well-repeated (though somewhat mythical) response from the client:

It’s just what I asked for…. But not what I wanted.

How is Agile different?

Agile was created to address shortcomings in the waterfall process that occur when developing a complex software system.

The principle difference with Agile is that it is a very iterative and interactive process. Agile projects are broken down into short mini-phases called “sprints” – At Mercury our sprints are 2 weeks. The entire requirement-design-construct-test-deploy cycle happens within each sprint. The goal is to have demonstrable results to review with our clients every sprint and get feedback.

Imagine with the waterfall process if a fundamental assumption was made during requirements, but during testing was proven to be false. The project is nearly complete and potentially months of work must be revisited. By doing small incremental feature development, we prove out our assumptions quickly and can change direction as needed.

Change Happens!

Change is the enemy of the waterfall project. Imagine we are building you a web application, and 80% through construction an event occurs in your business that suggests changing course would be beneficial. By now you can see the devastation this brings to the project. This ends with a difficult conversation on change requests and costs.

OK I get it… so what’s the answer?

First let me put you at ease, because by now you may be thinking where I am headed is to ask for a blank check with no understanding of where we are going.

With Agile you still need a vision. At the beginning of the project we need clear understanding of some high-level questions:

• What problem are we trying to solve?
• What goals do you want to achieve?
• What approach will we use to solve your problem?
• How will we define success?

With this framework, Mercury can define a solution by creating a set of “user stories” which describe in your language both the functionality desired and the benefit. Here is an example story related to workflow in a hypothetical cash disbursement system.

As an Employee Supervisor
I want to review pending disbursements and approve or deny them
So that I can confirm their accuracy prior to generating payment.

This statement tells us not only what you want to accomplish, but who cares about it and why. What we don’t do is try to define every single field, button, and click in the process at this point – we don’t know enough yet. Doing so is frankly a waste of your money because it is almost guaranteed to require revisiting later when we do know more.

We then take this collection of stories and estimate time and effort, which of course translates into dollars. With your approval, we will begin work towards meeting your goals with a budget to work against.

Every two weeks we review our plan and select the features that will provide you with the most value that can be delivered in the next two weeks. When complete, we demonstrate these features, get feedback from you, and then plan for the next sprint.

The key advantage Agile provides us is the ability to course correct after every sprint. Once we start delivering features you can see and touch, you can quickly see where we are headed. This gives us the opportunity to adjust as we go, instead of getting to the end and realizing we are in the wrong place.

It’s all about value!

Agile also gives you – the client – control over the process. If you want to add something new, we can do that! If you want to do that but not change the budget, you get to pick what we take out. Or maybe the new idea adds so much value you are willing to add it on top, but you get to decide.

You also have the option of eliminating features as we make progress. Maybe you thought we needed to build out some reports, but now that you are seeing the lookup screen come together you realize they won’t be needed. The good news is since those were prioritized lower, we haven’t spent any time (i.e. your money) on those features yet, and you can easily cut them from the project.

Project completion

When we get to the end of this process we may end up with something that looks quite different from what we originally envisioned. Ideas were revised and features were cut in favor of others that were added. But by focusing on the overall goals of the project instead of rigidly holding to a narrowly defined requirements document, we will end up with a superior product that was created collaboratively and truly provides the value you wanted.