Agile gloss

Freshness Warning
This article is over 16 years old. It's possible that the information you read below isn't current.

New Architect’s October issue has an article called Scaling Agile Methods about using aglile development methods like Extreme Programming (XP) in large development teams. The commonly held belief is that agile methods only work well when a project has a small (less than 12 or so) development team, and this article attempts to refute that.

It wold be interesting to see a case study of a project where agile methods were successfully employed on a large project, but this isn’t it.

The author used XP on a development project, but he only provides three paragraphs about the success of the project, an one of those is a simple rehash of the goals of XP.

In order to prove that XP works, the author relies on anectdotes. "Based on my experience, agile methodologies do work. In fact, I’ve found them to be just as effective as traditional ones." Why would a development team try a new methodology that is unproven in large projects if it is only "just as effective" as the one they are already using?

He also presents arguements as fact with no supporting eveidence. "If you’re moving to a new technology platform or your project calls for fluid requirements, these older [traditional development] methods aren’t suitable." That may come as a surprise to development teams that have successfully performed these tasks using traditional methods.

Has anyone seen a case study or paper on the use of a particilar agile methodology on a large project?

Eric Snowdeal
September 15, 2002 7:22 PM

while iit's a little tangential to your main interest, there are a few public papers available that compare xp with the capability maturity model which is a methology that is often, for better or worse, used to manage large software projects [1-2]. [1] http://www.xprogramming.com/xpmag/xp_and_cmm.htm [2] http://www.sei.cmu.edu/cmm/papers/xp-cmm-paper.pdf

Adam Kalsey
September 15, 2002 9:44 PM

CMM isn't a development methodology per se. It is a means of rating the quality of a development organization. Using the CMM, you have a standard by which to judge yourself and a measuring stick to use in comparing yourself to others. One of the problems I have with CMM isn't the concept itself, but the way it is applied in many organizations. Just as with ISO 9000, TQM, or other quality benchmarks, organizations tend to get bogged down in the specifics of the process rather than the results. A project that delivers on time, under budget, and exceeds client expectations is considered a failure if the Process wasn't followed to the letter. If a project isn't a success, it is blamed on not following the Process. The other thing that happens in companies that worship the CMM is they often treat programmers as interchangable resources. It is a mistake to treat your programmers as blocks of time instead of skilled thinkers. If you don't pay attention to the individual talents of your developers you will have consistently late projects. You need to match your developers to the problem being solved. All that said, I really enjoyed those two articles. It's interesting to read how XP practitioners see themselves fitting into the CMM.

Eric Snowdeal
September 16, 2002 9:31 AM

you're spot on with your comments. i was a little loose with my language. as you correctly point out, cmm is, stricly speaking, a model for "modeling, defining and measuring" the maturity of software processes. i tend to think of it as being interwoven with a set of management practices that dictate how to manage software projects for a given sei level, including the selection of the appropriate software development methodology for the project at hand - be it RUP, RUP-lite, waterfall, or xp. the point, which was admittedly tangential to your initial question of whether or not xp was being used for large projects, was that for most large companies that develop large projects, agile methods will likely be wedged into existing management structures like the cmm and it's interesting to see how that "evolution" is taking place. to directly answer your question, from my own experience, companies are still getting their feet wet with figuring out how/when agile methods are appropriate. and most companies will do something like look at the size of the required team and the number of sites to dictate the appropriate development methodology [i.e. see figure 2 http://www-106.ibm.com/developerworks/library/j-j1preview/index.html?dwzone=wireless ]. so, most big companies that are developing large projects are already on the path to making up their minds that xp isn't appropriate for large projects anyway. since i work for a large software development organization within an even larger technology congomerate that adheres to the tenets of the cmm, and has dabbled with agile development processes, i'd also be interested in finding out if anyone is using xp [ or related disciplines ] for large projects.

Adam Kalsey
September 16, 2002 9:56 AM

That's a good point. The larger the organization, the more likely they are to follow (or attempt to follow) the guidelines of something like CMM. So how likely is it that a large team would even be given the chance to try out an agile methodology? CMM-centric organizations tend to resist anything that might be perceived as risk. So that's another thing I'd like to see adressed in an article on using XP on large projects. How did the project leaders convince their superiors to try an agile methodology. What are some good organizational and project indicators that can be used to identify whether the use of a lightweight development method will be successful?

Trackback from Thinking Out Loud: Thought Leadership from an Enterprise Architect
October 9, 2004 10:40 AM

Antipatterns

Excerpt: An antipattern is a pattern that tells how to go from a problem to a bad solution. Listed below are links to some of my favorites....


Your comments:

Text only, no HTML. URLs will automatically be converted to links. Your email address is required, but it will not be displayed on the site.

Name:

Not your company or your SEO link. Comments without a real name will be deleted as spam.

Email: (not displayed)

If you don't feel comfortable giving me your real email address, don't expect me to feel comfortable publishing your comment.

Website (optional):

Follow me on Twitter

Best Of

  • How not to apply for a job Applying for a job isn't that hard, but it does take some minimal effort and common sense.
  • Movie marketing on a budget Mark Cuban's looking for more cost effective ways to market movies.
  • California State Fair The California State Fair lets you buy tickets in advance from their Web site. That's good. But the site is a horror house of usability problems.
  • Customer reference questions. Sample questions to ask customer references when choosing a software vendor.
  • Comment Spam Manifesto Spammers are hereby put on notice. Your comments are not welcome. If the purpose behind your comment is to advertise yourself, your Web site, or a product that you are affiliated with, that comment is spam and will not be tolerated. We will hit you where it hurts by attacking your source of income.
  • More of the best »

Recently Read

Get More

Subscribe | Archives

Recently

Assumptions and project planning (Feb 18)
When your assumptions change, it's reasonable that your project plans and needs change as well. But too many managers are afraid to go back and re-work a plan that they've already agreed to.
Feature voting is harmful to your product (Feb 7)
There's a lot of problems with using feature voting to drive your product.
Encouraging 1:1s from other managers in your organization (Jan 4)
If you’re managing other managers, encourage them to hold their own 1:1s. It’s such an important tool for managing and leading that everyone needs to be holding them.
One on One Meetings - a collection of posts about 1:1s (Jan 2)
A collection of all my writing on 1:1s
Are 1:1s confidential? (Jan 2)
Is the discussion that occurs in a 1:1 confidential, even if no agreed in the meeting to keep it so?
Skip-level 1:1s are your hidden superpower (Jan 1)
Holding 1:1s with peers and with people far below you on the reporting chain will open your eyes up to what’s really going on in your business.
Do you need a 1:1 if you’re regularly communicating with your team? (Dec 28)
You’re simply not having deep meaningful conversation about the process of work in hallway conversations or in your chat apps.
What agenda items should a manager bring to a 1:1? (Dec 23)
At least 80% of a 1:1 agenda should be driven by your report, but if you also to use this time to work on things with them, then you’ll have better meetings.

Subscribe to this site's feed.

Contact

Adam Kalsey

Mobile: 916.600.2497

Email: adam AT kalsey.com

Twitter, etc: akalsey

Resume

PGP Key

©1999-2019 Adam Kalsey.