Buying from an Agile Development Shop: Here’s What to Expect

If You Think You’ll Ever Consider Hiring an Agile Shop—Read This First

True story: We have a client who started working with one of our development teams a few years ago. She came from a traditional IT background. Before she even engaged us, she decided to scope out exactly what she wanted to have built. And she was very meticulous about it—in fact, she had an entire binder detailing the functionality she wanted, plus timelines, scope agreements, etc.

Our head developer took one look and said, “Oh, that’s OK, we don’t need to use any of that,” and tossed the binder aside.

I think her jaw hit the floor before the binder did.

We only found out much later how frustrated this client was in that moment, because she had literally spent months and months preparing for this engagement. Preparing that binder. 

This is a story about managing expectations. We made the mistake of simply assuming that folks come to us because they already know how an agile development shop works, and how to hire one. Shame on us.

But we also realized that this was an opportunity: Right now, there are countless IT directors and product managers and project leaders and all sorts of other people who are staying up late, trying to finish their own binders. No one has told them about the benefits of smaller teams, limiting work-in-progress, tight feedback loops, and other staples of agile frameworks. We are here to say: There’s a different way.

So this is our introduction to working with (and buying from) an agile development shop. It’s a prologue, telling you how to work with us.

“We don’t sell projects. We sell teams.”

If you’ve ever seen the movie The Social Network, there’s this great scene where Mark Zuckerburg (played by Jesse Eisenberg) compares the budding Facebook platform to fashion:

The money quote is at the 44s mark, when Eduardo Saverin (played by Andrew Garfield) asks “So when will it be finished?” Zuckerberg’s answer: “It won’t be finished. That’s the point. The way fashion’s never finished.”

He’s got the right idea: For technology products like Facebook, there is never a “done.” You have a continually evolving product. Where one product or version ends and another begins is pretty much arbitrary.

That’s why we, and other agile shops, sell teams. More specifically, we sell a given amount of dedicated time with professionals who have a given skill set. Within a given amount of time, that team will produce something useful. If you want to continue to build and develop that thing, that’s easy enough: You purchase more team time. If not, you at least walk away with a useful piece of software.

In fact, our introductory offer is usually a team of three experienced developers, who will work on your project for seven iterations (roughly 14 weeks).

Expect Smaller Teams (to Start)

Let’s be honest: No matter how “big” a project seems from the outset, your development team should start small—and probably stay that way. A smaller team will be more nimble, will communicate and collaborate more easily, and will zero in on what needs to get done (and how) more quickly. Past a certain point, bigger teams just get in the way.

As Frederick Brooks, author of The Mythical Man-Month, was fond of saying: “What one programmer can do in one month, two programmers can do in two months.”

So when you start with an agile shop, don’t be shocked when they say they are putting three people on your large-scale project and not 53. There’s a reason for this. Get to really know, and establish a good working relationship with, those three people.

We’ll All Learn While Building

That sounds scary, right? To learn as you build?

But here’s an open secret: Every good developer out there got to where they are now by solving problems they were unqualified to solve—indeed, no one was yet “qualified” to solve—until they actually solved them.

Think about that. If the product you want to build is just a copy of other products, fine. You can specify exactly what you want, and how and when it gets built. (That said, it would be easier to just buy a copy of the existing product, no?)

But chances are good that the thing you want to build is not just a carbon copy. It is a unique thing that solves a unique problem. So: You and the agile shop you hire will have to learn about the best way to solve the given problem by trying to build a solution.

And it’s amazing what happens when you take that approach. It’s often the case that features you initially thought would be important turn out not to be (and features you never imagined turn out to be critical). Solutions that at first seem trivial take up many resources, while problems that seem insurmountable somehow get solved. What you end up with might not look like what you wanted, but it’s a lot closer to what your organization really needs.

Get Ready for Short Feedback Loops

Do you know who the most impressive fast-food restaurant is? It’s probably SUBWAY sandwiches.

Think about it: Every single order is a custom-built sandwich, which may include any number of dozens of ingredients. Other fast-food chains struggle just to get an order of “five tacos and a soda” right.

Here’s how Subway gets its sandwiches just right: The entire process is done in front of the customer. When you choose your bread, the employee puts it on the counter in front of you. You watch as they place the meat. They ask what kind of cheese you want. You can pick from a few dozen veggies and dressings, and guide the sandwich maker as needed. (“Um, more pickles please? Wait, no lettuce...can I try spinach instead?”) You can see your sandwich come together at every step.

Software that solves a unique problem is just as “custom” as a Subway sandwich, maybe more so. To guarantee that you get an end-product you want, you need transparency into the process at as many steps as possible, as well as the ability to share feedback. So don’t think this engagement will be turnkey—you will need to be at the counter with us, helping us build your software.

The Measurement for Success is Way Different

When you buy from a traditional development shop, they expect that binder: The contract, the scope of work, the budget, the contingencies. They will then measure themselves by that binder. 

Because any vendor is going to have to be held accountable to some measurement for success; and if the entire pre-engagement talks about features, budgets, and deadlines, the vendor is going to measure themselves against that delivery. They are almost never required to measure things like added value or usefulness, or (heaven forbid) customer satisfaction. 

We’ve seen plenty of instances where a vendor prided themselves in on-time and in-budget delivery of a product that was, basically, a flop. They are like surgeons who declare their operation to be a success, even though the patient died.

So don’t be surprised when we choose to measure our performance by things other than what you’re used to (delivery milestones and whatnot). Rather, we want to work with you to establish some real measurements of success, like value delivered, or learning validated.

What There’s None Of

Long contracts. Scope documents. Detailed budgets. Long onboarding periods. Change control. Exit clauses. Other corporate silliness.

“We Can’t Work This Way…”

We get it: This is a different way of doing development. It will not sit well—at least at first—with people who have protected their company and their jobs by doing business the older way. 

And it probably sounds expensive to boot.

But we can tell you from experience: It actually costs more to develop software the traditional way. The ROI is just not there. With an agile software development approach, you at least end up with a piece of working, valuable software that you can implement and bring to market.

And if the product or engagement is not working for you, you have the option of cancelling any time. There is no 3-to-6-month wind-down; you simply finish the iteration you’re on. And at the end, you will at least have something for the money you spent.

(In fact, some of our clients buy just an iteration here or there, as funds become available. Imagine having to get all your funds together for a large project—and then running out halfway through, without anything to show for it!)

So the risk of developing with an agile shop is pretty minimal. It just takes a shift in mindset and a willingness to try a different process.