Architectural manifesto: Adopting agile development, Part 6

The buyer's viewpoint

In Part 6 of this series, learn about buying software development services from the customer's point of view. While there's a lot of information for development teams about using agile methodologies, there isn't much material about the customer's viewpoint when buying software development services. Learn how customer incentives, behavior, and the pricing models of a project have a huge effect on the current and future success of a development project.


Mikko Kontio, Partner, Dazid

Mikko Kontio has a background in software development and consulting. Formerly a director with Softera, a software development company focusing on business portals and telecom-billing solutions, Mikko is currently a partner at Dazid.

26 August 2008


Thus far in this series you've learned about the benefits of agile processes and the requirements placed on the organizations that use them. You've also learned how organizations adapt to agile development, about the different types of stakeholders, and how to apply user stories. You walked through a case study and saw how user stories, discussion, and prioritization can lead to quickly developed beta versions.

This article focuses on those who buy software development services. Learn about their points of view and what they need while planning a project (or when planning their own processes for information and communication technology projects).

Improvements in software development processes typically raise a lot of enthusiasm in software development organizations. Quite often, though, the customer's (buyer's) side of the equation is forgotten. The customer might be inexperienced as a buyer of software development services and isn't thinking about process issues. Forgetting to involve customers is a shame, because it can create a situation where the improvement efforts go awry. Especially if your organization is implementing agile methods, you should remember that the methods require a certain type of behavior from the customer. Without agile-wise customers (and agile-wise contracts), the adaptation of agile methods is not likely to work.

The foremost issue on a customer's mind is the business problem that the project is supposed to solve. The developer organization should always keep this in mind.

Customer organizations

From the developer's point of view, there are two typical cases where the relationship between the customer and the development organization is likely to be difficult.

Customer representative is not an experienced buyer of development services
In this situation, the customer is often extremely price-sensitive, and might not understand why requirements analysis, design, and testing are necessary or how much time they usually take. The customer might compare prices and timetables to shrink-wrapped or configurable products. They typically ask for fixed-price offers and don't have written requirements.

From the developer's view, this is a dangerous situation. To fulfill the contract, developers are forced (either by the customer, management, or deadlines) to write code instead of to design. This jeopardizes future projects, quality, and in the end, the reputation of the developer organization.

It is also dangerous for the customer for reasons discussed later in this article. If you're the buyer in a company that does not have experience buying software development services, what can you do to improve matters? First, know the amount that your company has budgeted for development services for this project. Sometimes the budget is enough for configurable products but not for custom-developed software.

If the project is still in the planning phase, it might not be too late to change the scope and the goal. Always remember—and emphasize to other project members—the business problem your project is solving. Get some additional help if you need it by hiring an independent consultant with experience and good communication and reasoning skills. The consultant will know if your budget and plan don't go hand-in-hand. The consultant will also go through your business case (the problem) and help you phrase it in a form that you can later use while selecting your developer.

An experienced buyer of development services has a formal buying process
This customer will either aim for large fixed-price projects, or for long (between three to six months) contracts. If you're willing to use the customer's development process, then this can be an ideal customer for you. However, if you're willing to use only agile methods, you might face difficulties.

No matter which side of the table you are on, keep in mind that fixed-price deals and agile development don't work together well (see Pricing). For people wanting to use agile methods, the real question is: how well do the customer's processes support agile principles?

As you might have realized, a big factor is often the level of trust between the developer organization and the customer. If the customer doesn't trust the developer to be effective and to do quality work, they are more likely to go for fixed-price deals, which will drive away agile developers.

The buying process

This section takes a high-level look at the process of buying development services from the customer's viewpoint.

First, there is the business problem, which needs to be defined in a way that makes it easy to discuss. Some organizations use simple tools, such as e-mail or slides, while others have more formal methods for describing the problem. Depending on the problem and the closeness of the relationship between the customer and developer organization, the developers or outside consultants can help define the scope and requirements of the project. If an agile process is used, requirements can be at a high level of abstraction because they might change anyway before implementation. At this phase, the customer starts talking with one or more developer organizations in order to negotiate a deal.

If the business problem gets solved in a single project, then the customer doesn' need to worry about defining the contents and requirements of the next project. However, quite often the development of custom software continues with new projects, iterations, versions, and so on. In this case, while developers are working on the current project, the customer must work on the contents of the next project. If the new project doesn't continue right after the first, there's a danger that the development team will get assigned to another customer and they won't be available for a while.

It is wise to be open about the continuity and road map of projects, because that will allow the developer organization to plan their resources. It is also in their best interest to use the same developers for the new projects.

A customer's incentives

It is beneficial to understand the typical incentives that the buyers are looking for, and what is important to them. The first and most important issue is that the project offers a solution to the business problem. Without a clearly defined business problem and a calculated return on investment, the project does not have a clear scope and will likely be canceled later on.

The price is always important. The price is more than just the cost of the first project done by the developer organization. The price consists of development costs, testing costs, internal costs, server hosting, support, and maintainability costs as new features are developed. Quite often, buyers (especially inexperienced ones) compare only the initial development costs and forget the rest.

The development team is one of the most important factors in a buying decision. An inexperienced team costs less and is more likely to be available on short notice, but the level of experience of individual developers and the developer organization has a huge effect on the quality of the software. Great developers create good, maintainable software that is easy to support and further develop later. They might cost a little more, but they are certainly worth it.

The continuity of the development project is also important to acknowledge. If the first project is to be followed by another, and then another, the customer should be open with the developer organization and create road maps so developers can plan their other work. If every project is a separate project, preceded by a time-consuming tendering process (proposals, negotiations, and so on), the really good development teams will find other customers with whom they can build trust and lasting customer relationships.

There is also a nonspoken issue for the buyer that is rarely mentioned or even acknowledged. The person who is buying must win something on a personal level, or at least be very sure not to lose anything. This does not refer to money or anything illegal, but to issues such as reputation, career, or saving costs in a tough situation or problem project.

For developers using agile methods, the lesson is clear. If your customer is not agile-wise, you can try to do the convincing. But it might take longer than you think. Imagine it from the customer's point of view: if their organization has no previous experience with agile methods, why would they risk the project?

There are practical ways to convince the new customers. You could, for example, invite them to a seminar you've arranged where your current customers explain the benefits they have experienced.


Pricing is one of the most important factors in making the decision to buy software development services. The pricing model has a huge impact on the quality and nature of the work. The following are brief descriptions of various pricing models.

Fixed price
One of the most typical pricing models. The customer provides a thorough requirement specification, and the developer organization makes a proposal for a fixed price. In this model, the requirements are the contract, and the use of agile methods is not likely to work well.
Time and materials
Another common pricing model. All work is invoiced for an hourly or daily price. Some developers like it and some don't. The ones who like it aim for high utilization rates and high hourly rates. Those who don't like it criticize that added benefits and the responsibility for the complete project are hard to tie in with the hourly price. Customers feel similarly—some like it and others don't.

This pricing model works well with agile methods because all work is invoiced as it is completed, and there can be as many sprints (and changes) as the customer wants.

A combination of the two previous models is sometimes used. The requirement specification can be done with the time and materials, since nobody is really capable of estimating how much work the specification requires. After the requirement specification is ready, it is much easier to estimate the work effort for design and implementation.

Agile methods don't work well with this pricing model because the requirement specification is a contract, and all negotiations must go through change management practices.

Target price
In target pricing, the customer and developer organization agree on a target price and all work is invoiced at an hourly rate. The developer organization aims for the target price. If the total is less than the target, the developer will get a bonus. If the price is more than the target, the difference is invoiced with a lower hourly rate.
This is a less common pricing model. The developer organization will get its share of the savings that the customer gets. It is very effective, and the customer knows that the developer's interest is also the customer's interest. The only potential problem is if defining and measuring the saved costs is not simple. This pricing model requires that the customer and developer organizations trust each other. If the theoretical sum of costs saved is big enough, agile methods can be used.

From the developer's point of view, this pricing is quite close to the target pricing model. From the customer's point of view it is safe, because they will save money no matter how well the project succeeds.

Share-of-winnings is quite similar to the cost-beneficial pricing model, except that the developers get a part of the winnings. Like cost-beneficial, measuring and defining the winnings is important, and both parties should trust each other.


It's always good to consider what the folks on the other side of the negotiating table are thinking. With software process improvement, the customer's point of view is often forgotten, or the customer is not actively involved in the improvement process.

In this article you learned about the buying process from the customer's point of view. The focus was on the customer's main incentives, and the pricing models and their effects on the project. You also learned which pricing models work well with agile development.



Get products and technologies

  • Download IBM product evaluation versions and get your hands on application development tools and middleware products from IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.


  • Read what everyone is talking about in developerWorks blogs and get involved in the developerWorks community.
  • Check out Scott Ambler's blog - Strategies for Scaling Agile Software Development.
  • Participate in the IT architecture forum to exchange tips and techniques and to share other related information about the broad topic of IT architecture.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Architectural manifesto: Adopting agile development, Part 6