Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Scaling Agile Methods


From literate programming to evolutionary delivery, veteran project managers have seen a variety of shifting development methodologies. Most recently, a family of new methods has emerged united under the umbrella of "agile development." These include eXtreme programming (XP), Scrum, Feature Driven Development, and a few others.

Agile methods have introduced new practices, such as pair programming, while discarding some old ones. Agile development favors delivering working code over complete documentation, for example. Recently, top proponents of these techniques have laid out twelve principles for agile development in the form of the Agile Manifesto (www.agilemanifesto.org).

Trial By Fire

Recently, I had the opportunity to use eXtreme programming (XP) on a large software product release. The team consisted of more than fifty people located in two different development centers. At first, I was skeptical that XP could work for us. I knew that, historically, XP has been most successful with small and very committed teams, and while our team was enthusiastic and committed, we certainly weren't small.

Fortunately, the results of the experiment came as a pleasant surprise. Using XP methods, project teams were more enthusiastic and eager. People enjoyed XP's concept of pair programming and it allowed any member of the team to fix anyone else's bugs. As a manager, this reduced my stress levels when a team member was out sick or on vacation.

By placing importance on regular builds and working systems, we frequently caught problems early. By maintaining good version control, we also had confidence that we could easily roll back to a previous build if things went bad. Unit tests helped ensure that new functionality didn't break the old. Overall, integration became easier and less worrisome. Working with requirements that weren't yet fully defined made it possible to start work faster, fleshing out the requirements as we moved along. Regular demonstrations of the system as it was being built helped satisfy stakeholders that their needs were being met.

Try Something New

Based on my experience, agile methodologies do work. In fact, I've found them to be just as effective as traditional ones, even for larger project teams, so long as you observe their unique requirements.

However, managers still have to weigh several factors before deciding whether to use agile methods. Their success depends on three major factors: the skills and enthusiasm of the people involved; the processes used and level of adherence to them; and lastly, the management and reporting systems in place.

Inadequate communication can disrupt any project and cause any methodology to fail. If teams don't communicate well with each other and with other teams, their skills and level of enthusiasm don't matter. They will end up creating poorly designed or just plain bad solutions.

Similarly, programmers must understand processes and follow them. If management and reporting systems are inadequate or nonexistent, there is no way to reliably track progress. No one will recognize problems until too late and project stakeholders will have no idea whether they're getting what they requested until after it's delivered.

Can It Work?

When should managers consider agile methods, and how should they start using them? Traditional development methodologies can help deliver projects on time and budget, and give management a good handle on project status throughout. However, if you're moving to a new technology platform or your project calls for fluid requirements, these older methods aren't suitable.

Traditional methods assume fairly static requirements and impose high cost burdens because of the high volume of processes and people needed to complete a task. They focus on intermediate deliverables, which can become wasted work should project goals and requirements change.

You can define projects by four factors: scope, time, resources, and risks. Traditional methodologies work well when all of these factors are quantified and understood. If any factors are variable or unknown, however, these methodologies frequently fail. When building new products or solutions, or when rebuilding an existing solution on a new platform with new technologies, agile methods really begin to show their value. See the table below for a comparison of traditional versus agile methods, and when to use them.

Ramping Up

You've bitten the bullet. You've decided to use agile methods. Now what happens? At this stage, decide how big your project is going to be and answer the following questions:

  • How many teams will be involved?
  • Do you plan to convert all development to agile methods?
  • Will you use agile methods for only one special project?
  • Will you do things in parallel and gradually convert the whole system over?

Special projects (and "skunk works" projects) are probably the easiest to set up for agile methodologies. The project teams are smaller, and developers are often eager to get involved. As a result, these projects typically involve an organization's best and brightest.

The problem comes when you try to scale up agile methods to encompass the rest of the organization. As someone in the retail business once told me, it's hard enough to get the formula right for running a single store, but much harder to get the formula to work on two or more stores. The same holds true when trying to apply agile methods successfully to more than one team within an organization. It may help to involve external consultants, who can provide an independent opinion as well as new ideas.

All too often, team members' "soft" skills are ignored. In many organizations, project teams have difficulties with cost estimation, time budgeting, risk identification, and contingency planning. Any number of books describe simple techniques teams can learn to make themselves more successful in these areas.

Getting all of your teams to use similar techniques is important, particularly when it comes to time and cost estimation. Bad estimation can lead to poor distribution of work. I've heard of managers who proudly announce that their teams work over fifty hours a week, week after week. While these may sound like highly productive organizations, the results can be dangerous.

When team members are under stress, communication and cooperation suffer. Employees focus on handling their own caseloads, rather than helping each other out. They ignore potential problems because they are afraid that identifying these problems will create more work. They become very upset about minor problems because they're afraid of missing deadlines. All of this slowly corrodes the organization and drives out the best people.

Staying Agile

Many organizations opt to pick and choose best practices from among the various agile methods. Review your development processes to identify the unique requirements of the different groups involved, and then customize your process based on these needs. You'll find that the twelve principles of the Agile Manifesto can be useful guidelines for this review.

Lastly, consider the management systems necessary to effectively plan, measure, share information, and control the software definition, development, and delivery efforts. These include control process definitions, responsibility definitions, meeting structures and agendas, reporting formats, issue escalation procedures, information sharing tools, and so on. Good management and reporting systems help detect issues before they become serious enough to cause major delays.

Agile software development methods can help organizations deal with situations with uncertain requirements, resources, time, and risks. However, to extend the use of agile methods successfully throughout the development organization requires attention to more than just the methods themselves. You must consider the skills of the people involved, the processes and how well they account for your unique needs, and the management and reporting techniques used to control the project. Above all else, good communication, commitment, and teamwork are essential for success—and this holds true whether a project is completed using agile methods or more traditional ones.

Which Methods Are Best?
If any of these factors for your project are uncertain or subject to change, agile development methods could be the winning formula.
Factor Traditional Methodologies Agile Methodologies
Scope (requirements) Well known
Size well understood
Will not change
Uncertain (Are the requirements correct?)
Unknown (What is the scope?)
Subject to change
Resources (money, infrastructure, people) Approved and available
Has been done before
Budget is sufficent and funded
People familiar with tasks and tools
Not fully approved or available
Need proof of concept
Money is tight
Uncertain budget
New skills needed
Time Clearly defined
Clear milestones
Not well defined/open
Unclear milestones
Subject to change
Risks Well understood
Minor impact
New technologies
Unknown risks
Major impact


As president of SMGlobal, Sanjay helps companies review and improve their software definition, development, and delivery process. You can contact him at [email protected].


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.