Architectural manifesto: Adopting agile development, Part 2

Understanding the different facets

In Part 2 of this series, learn how agile processes are used in different kinds of companies, in small and large projects, and how agile development can affect the customer experience.


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.

22 April 2008

Also available in Chinese Vietnamese


Part 1 of my agile development series introduced agile processes, the benefits of using them, and the requirements placed on the organization that uses them. In this article, I’ll discuss how different types of organizations, such as start-ups, product companies, and small and large organizations, adapt to agile development. You'll also learn how culture and pricing affect the process and outcomes.

The start-ups

Working in a start-up business can be challenging, but start-ups have some advantages in terms of process. Start-ups get to develop their products from scratch, often with no heavy code base or history. They can choose the tools, technology, processes, people, and purpose of the product they're building more freely than organizations with a history.

A new company can choose the way it works. If the product domain is not heavily regulated, or the product doesn't require approvals before launching or going beta, the company can produce something quickly. Even if the first release is a beta—or just a Web site with screen shots—it's a good idea to start getting the word out. The company process is moving in an agile direction, and for most new organizations this is fine.

In some cases, existing companies can give a new division the feeling of being a start-up by letting them do what they want instead of forcing them to follow company principles. Allowing some latitude is a good way to test the existing processes, or to acknowledge that existing processes are designed for another kind or size of activity.

Without the people, processes are just pieces of paper or diagrams on a computer screen. New companies get to select and train the employees. This is a great advantage, because you can ensure that everyone is given the same rules and instructions. If someone doesn’t work as instructed, and offers no decent explanation, you ask them to go. Just make sure you create the rules before you hire.

An organizational culture is a powerful thing. For example, if your culture highlights bonuses, people might not want to come to trainings or get-togethers if they think that money spent on these events will reduce their bonuses. However, if your organizational culture serves your goals, that culture might be all you need. In a start-up, you can create your culture to support your requirements. A culture that highlights open discussions, high quality, and teamwork, provides a strong foundation for adopting an agile development process.

Start-ups typically have smaller projects, either because their products are fresh, or their customers (often Java™ shops) are smaller than those of a company with a longer history. Small projects with fewer than 20 people are more suitable for agile development.

Start-ups also have new clients (new to the start-up, anyway). With a new client relationship, there's no burden of bad history. Agile development requires a few different processes, or habits, from the client as well. As a new provider, you can start by explaining procedures and the benefits your customer will enjoy.

A start-up or new business unit is fertile ground to adapt an agile development method. But what if that is not possible?

Organizations with a history

More often, you have an ongoing business with its own culture, processes, clients, and people. With existing companies, adopting agile methods must show benefits. If the work doesn’t improve somehow, change just for the sake of change isn't a good idea.

For existing processes, is the process written, or does everybody just develop in their own way? You should have a rationale for change. Is the adaptation about real benefits, or something else? Using the list in Part 1 of this series, try to review the adaptation neutrally, and ask if agile development is a good fit for your company. If it is, you'll have benefits and facts to show your team. Better yet, involve the project managers and developers in the investigation of agile methods. Chances are they will drive the change.

As noted, a corporate culture is a powerful thing. If your organization needs a different development process, yet its organizational culture is strongly against change, don’t try to adopt agile methods before trying to change the culture.

The type of projects you do is an important factor. Do you develop your own products, work on customer projects, offer consulting services, or maintain and support a legacy system? Applications with a history are more difficult to change. The limitations often come from the existing code base or from customer requirements. For example, if each software update causes weeks of work for the customer and requires the work of several people, it isn't good to release a new version every three weeks. To make your customer’s life easier, you could start by offering the software as a service, and plan and implement version updates.

Adapting an agile process in a company with history is more challenging, but it can be done if there are clear benefits to it.

Project size

The project size is important if the agile principles are to work properly. The number of people is more relevant than the length of the project or number of features. You can always prioritize features and use more time to implement them. But if you have to implement many features in a very short time, you need a lot of people to do it. Research and experience show that ideal agile team size is 20 to 30 people—or fewer. Review the agile principles in Part 1 of this series, and analyze how the number of people on the team affects the project.

Most of the principles require face-to-face discussion, which becomes difficult on a large team. The power of agile development is based on communication.

Self-organization can be another problem with large teams. People can lose focus on the real problems, and one team member might think another will take care of any given issue. But if it's just Bob, Eve and you, it will be evident whether a problem is being handled or not.

The customer's view

Often the customer is forgotten in the middle of internal changes, which can lead to difficulties. The customer needs to understand the advantages of the new process and how it differs from the previous one. Some customers are interested in the way you work, and others care only about the outcome.

Ideally, the customer would notice only positive effects without realizing any changes have been made—especially if you deliver a product or on-demand application. The customer might notice that some requests are implemented faster and that the overall quality is better.

If you provide a development service where customers order development work, or features by specification, then the process is more visible. The customer needs to understand the main principles of the agile development process, because it affects how the work is best paid for (as discussed in the next section). With agile development, a team of developers does as much as they can in a certain time frame, which supports a time-based payment model. If the customer is used to buying development with a fixed price model, or has formal guidelines, it can be quite a big—or even impossible—change for the customer.


If you’re developing your own product or service, such as a Web application, your customers probably aren’t interested in how you do the job. They just want it to be a quality application. If you’re providing software development services, the pricing model becomes very important.

Customers use two basic types of pricing models:

Fixed price model
The customer and developer negotiate a fixed price for the project. Naming a fixed price usually requires the scope and requirements of the project to be agreed upon and written down. As you might already guess, this model is not good for agile development.
Time and materials model
The customer hires developers or consultants for a longer time period and pays for the time used. This option is better for agile development, because it leaves the scope and requirements open.

If the customer has a budget, you can agree on a target price, and work toward the goals of the project within the budget.

If your customer likes to use the fixed price model, you might find it difficult to make a sale with a time-based price model. (The customer might resist a situation that they don't believe they can control.) Propose the target pricing and explain why fixed pricing isn’t good for a process with agile development.


In this series, you learned how agile development methods fit start-up companies and companies with a history. Start-ups are in a slightly better position to develop processes and a culture as they wish. Though existing companies might find it harder to adapt agile methods, they can do it if the benefits are sound and obvious.

The size of the project affects the process. Small projects, with a team of fewer than 20 people, are more suitable for agile methods, because face-to-face communication is more difficult with larger teams.

For agile development, time-based pricing is more suitable than fixed pricing. If the customer is buying a development service (and not a product), the customer should also understand the principles and benefits of the agile methods.



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®.



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 2