A few years back, I joined Carbon Five, a small agile consulting company specializing in boot-strapping start-ups. Over my three years there, I learned that the expectations of working with agile consultants are very different than working with other consulting companies. Now that I am five years into agile consulting myself, I’ll share my typical introductory remarks.

What is agile

Agile is a software development process emphasizing:

  • close collaboration between the programmer team and business experts; or in our case, between the client and developers
  • face-to-face communication (as more efficient than written documentation)
  • frequent delivery of new deployable business value
  • ways to craft the code and structure the team so that changing requirements don’t cause a crisis, but excitement. Agile teams strive to collaborate in-person as much as possible. And we deliver software not in just a few key milestones, but continuously: weekly, daily and hourly.

What to expect from us

Working with us is collaborative and iterative. You tell us what you want, we listen, and together we identify the most important features. The goal is to identify the features (or “stories”) that provide the most value to you and your customers. Once we agree, we will build it quickly– not in months or years, but weeks.

We will deliver this early version so you can try it out. It will be just a rough outline of the whole vision. This is the inside of the sausage factory. Once you experience it, you will likely have a reaction– a good one, we hope. But if you don’t like what you see, that’s fine. We haven’t invested much, and we are early in the process. We can easily adjust what we’re building. It may inspire new ideas or a change in direction. Whatever the reaction, we’re not locked in. Hence the term “agile”.

We meet again, and prepare to repeat the cycle. Again, we’ll address the highest-value aspects of the project, deliver them, and we get feedback for the next iteration.

What not to expect : we are different than an “outsourcing” experience. In that engagement, you expect to tell the agency what you want, and they deliver it to you in three or six or 12 months. On the surface, this relationship is simple, but very seldom will what you ask for up front be what you want six months later. We expect you to be engaged in the development process, defining requirements, correcting the course, setting priorities, and providing feedback.

Why agile

Agile, and the related methodologies like scrum, extreme programming, lean/agile, is a response to the failures of “traditional” software development. Even though the “traditional” process has been around for nearly 40 years, it has never worked particularly well. In particular,

  • 64% of features included in projects are rarely or never used
  • The average project exceeds its schedule by 100% and nearly two-thirds of projects significantly overrun their cost estimates

Agile, with its emphasis, addresses these:

The most common reasons for software failure are unrealistic or unarticulated project goals and badly defined requirements. We build working software in collaboration with our customers. By collaborating, we identify missing requirements right away (and resolve them with you.) And our customers see problems right away, and get a chance to respond to them. This tends to reveal right away when our goals aren’t aligned.

The other common problem is communication among customers, developers and users, and poor reporting of the project status. Agile addresses these head-on. At its core, it’s about communication. The team meets daily to identify problems, programmers work together (“pair”), and the customers are involved frequently during the development of features. In addition, software is delivered and reviewed frequently (usually every week), so the team– even if there is some huge misunderstanding– rights the ship before it can get too far off course.

What we expect from you

Collaborate with us! We expect to collectively figure things out, and then build what you want.

Here’s a typical cycle: We will periodically (every couple weeks), have a planning meeting. Here, we talk about what you want: this will be business goals, product features, and perhaps “the color of that button over there.” Once all the ideas are on the table, we will estimate the amount of effort they will take to get done. These are estimates, but help you prioritize the work: a medium priority feature may be worth doing if it’s really easy, but should be shelved if it is a huge undertaking. We involve the developers so you can make informed decisions. We need you to be actively engaged in these meetings and strongly representing your needs. The outcome of these meetings largely shapes what we will do over the next “iteration”.

We will expect a daily engagement. We will need you, or your delegate, to answer product questions throughout the development. By foregoing huge, unmanageable requirements documents and product specifications, we can (and have) saved weeks or months of time. But when we do run into a question, like “This feature is much more difficult than anticipated. Is it worth it?”, we need to get an answer quickly so that we can move forward.

Finally, we expect you to look at the working software we deliver and respond to it– not wait three months until the project is done.

Expect from us: working software.

References:
http://www.agilemanifesto.org/
http://www.agilealliance.org/show/2
http://www.it-cortex.com/Stat_Failure_Rate.htm This article aggregates several studies on software failure rates.
http://spectrum.ieee.org/sep05/1685 Why Software Fails, Rober N. Charette, September 2005. Summarizes why projects fail.