 | Level: Intermediate Mikko Kontio (mikko.kontio@softera.fi), Director, Softera
22 Apr 2008 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.
Introduction
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.
Invoicing
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.
Conclusion
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.
Resources Learn
-
"An Introduction to Agile Methods"
(David Cohen, Mikael Lindvall, Patricia Costa, 2004) discusses what it means to be
agile, the role of management, the more popular agile methods, and guidelines for
deciding where an agile approach is applicable.
- Read Wikipedia's discussion on
agile software development.
- Learn about
Scrum, an agile process that can be
used to manage and control complex software and product development using
iterative, incremental practices.
-
"Why Fixed Bids Are Bad for Clients"
(ScrumAlliance, Sep 2007) discusses agile projects and fixed price bids.
-
"OpenUP In a Nutshell"
(developerWorks, Sep 2007) explores OpenUP, a recently developed process framework
for software development that focuses on agile practices derived from the Rational
Unified Process®.
- Read about
"Effective agile delivery toward globalization"
(developerWorks, Oct 2007) if you have overseas markets that require considerable
planning in the development life cycle to accommodate cultural and language
differences.
-
developerWorks Interviews: Scott Ambler on Agile development
(developerWorks, Apr 2007) explains this iterative and incremental approach to
development, lays out the business case for it, and dispels some myths in the
process.
- Make use of
IBM on demand demos
to learn about various software products and technologies from IBM.
- Stay current with
developerWorks Live! webcasts.
- Check out
developerWorks Live! technical events and briefings.
- Get an
RSS
feed
for Mikko Kontio's Architectural Manifesto column.
- Browse the
technology
bookstore
for books on these and other technical topics.
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®.
Discuss
About the author | | | Mikko Kontio has a background in software development and consulting. He is currently
a director in Softera, a software development company focusing on business portals
and telecom-billing solutions. |
Rate this page
| |
