I recently joined Carbon Five, a small agile consulting company specializing in boot-strapping start-ups. I got a chance to work with C5 over the last year (as a client), and I learned that the expectations of working with us are very different than working with other consulting companies.

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 the team such that changing requirements is not a crisis.

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 or 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. 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. (Easy? Yes. But it seldom works easily.) We expect you to be engaged in the development process, defining requirements, 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.

  • 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 different 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 it’s 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 two weeks), 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 be collectively figuring out, and then building, 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 shelfed if it is a huge undertaking. We keep the developers involved so you can make informed decisions. We need to 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 business cycle. By foregoing huge, unmanageable requirements documents and product specifications, we have saved weeks or months of time. But when we do run into a question, like (insert example here), we need the ability to get an answer fairly quickly so that we can move forward.

Finally, we expect you to make time 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.

Notes:

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.