Buy Software Development: Agile vs Traditional

Software development is intellectual services.

Unless you only need little hands to code straight forward what you have precisely (very precisely) specified, you need at some point some intelligence, some expertise, and you'll choose a contractor not only because he is cheaper, but also because you will benefit from its expertise.

Say you are a buyer of a big company, and you have in mind a set of features. Maybe you have a specifications document (given by your technical team). Maybe you also have a rough idea of how it can be implemented, technically speaking.

Say that your goal is to provide your company with the best solution at the best price.

Now, let's compare two very different approaches:

1. Buy traditionally made software

In this approach, you have to specify precisely what you want. Then, you can easily ask several companies the price and the delay for implementing your software. And you can easily negotiate prices because all proposals will contain nearly the same commitment. And if you specify an architecture, you'll have similar solutions proposed.

That's the more comfortable position for you, the buyer. You buy intellectual services (software development) like you buy a product.

Then, the realization will start. And the contractor, if he is professional, will have to deliver you with the minimum software that fits with your specifications and its commitment. The same way you negotiated the price to minimize your expense, he will deliver the bear minimum he has to in order to maximize his revenue.

More than that, if for some reasons, your needs turn out to be a bit different than what you expected first (because it appears that you are not the expert in the field, or/and because your contractor has hidden some lack of your specifications, etc.) you'll have to ask your contractor for a amendment to the contract.
And because your contractor made a price very low on the first package in order to gain the contract and because he is a professional that needs to maximize its profit (like you), you will have to pay a lot for this amendment (and all upcoming ones). Especially if (it happens in most cases) you are stuck to this subcontractor -- because he developed too many things now to replace him with another company.

Obviously, it always happens. Because it is so hard to precisely define what you need. Even, often, what you need is different of what you first wanted (and sometimes also different from what you specified).

Meaning that if you wish to buy software this way, you'll have to engage technical experts first, to precisely define what you need, and then charge a standard IT company (little hands) to execute the exact plan at the lower price. And then, the question is still asked: how to buy expertise?

In the traditional way, the contractor is not exactly playing with you because its goal is not aligned on yours.


2. Buy agile made software

You have needs. And maybe rough ideas on what and how it can be realized. But you know you are not the expert, and you are confident your contractor will come up with a solution you would never have thought about, way better than what you expected first.

Meaning, you'll choose your contractor for its expertise, not for its ability to execute word by word a plan you have written.

A contractor comfortable with agile development methods will answer your RFI or RFP with:

• an architecture and technologies that fit well with your needs;
• an estimate of the work and the global cost of the project, without committing on it yet;
  
• development plan split into several iterations of the same size of 2 to 4 weeks (called sprints in Scrum method), with maybe a first special iteration to study deeper your needs, and build up a mock up to validate the solution. Each iteration will end with a delivery you'll be able to use. And this delivery will be tested as it was a final product;
  
• the price for each iteration planned on the project and the price for extra iterations;
  
• the opportunity to stop the contract after each iteration and will offer you to pay each iteration one by one, once completed and accepted by you (the acceptance of the previous iteration being mandatory before starting a new one)

Here's how Scrum method used in my company looks like (features are broken down into a backlog who are managed with Jira):

Each week, you'll have a report on the estimated remaining time to achieve the product that fits your needs, the estimation of the implementation of each feature, and you'll be able to give feedbacks, change priorities of features to implement.
Each sprint, you'll be able to change the features to implement... that is to say to figure out that your needs are slightly different, and change the route of the project.

In one word: you are at the helm. You are part of the team. You are able to see with your eyes if the guys are really working hard or not. You can precisely follow the development and decide the direction to take. You can stop when you want or decide to continue. You will trust and be trusted in return.

In this way of contracting software development, the contractor is playing with you. He will show you everything he sees, and let you take the decisions.

Now, because you are the buyer, you are not very comfortable here, because you simply cannot negotiate the same way you would have done for a traditionally made software: if you lower the price, you will only get less iterations.

The only thing you can negotiate here is the price of each working days depending on the experience, the specialization and the reputation of your contractor.

Meaning that you have to:

• make the contractor talk and write about the solution he proposes in term of architecture and technologies, project organization and development process, so that you'll be able to get a good idea on his experience and skills
  
• interview people who have worked previously with the company (and preferably people who had same needs than you, people who are happy with the job they made and people who are less happy, and understand why)

3. Software services: expertise or simple outsourcing?

Depending on what you want to buy, expertise or little hands, choose how you buy, and to which company.

If you have experts at home (do you really have experts at home in all required fields?) maybe you can first spend a couple of weeks/months/years (depending on the project size) to produce extremely detailed specifications and buy man power (little hands) to standard IT companies, and build a project management/QA team to follow the outsourced team.

In all other cases, you may have to consider the "agile way" and benefit from an expert company which has built its reputation on its technical skills, its creativity, its ability to deliver in an agile manner.

What are you able to do for an iPhone?

You know it: I've one of the first generation of iPhones in my pocket, a colleague of mine at Joost brought me back from the US. Of course, it has been unlocked so that I'm able to use it without giving 50€ to Orange each month during 2 years (+ several hundreds of euros to buy the device), that is to say without giving an arm for it!



Coucou to friends who are still working on Joost!