InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

The ABCs of Agile for Managers

Posted by Kurt Christensen on Apr 04, 2007

Sections
Process & Practices
Topics
Agile in the Enterprise ,
Agile
Tags
Introducing Agile ,
Industrial XP
In the recent edition of CIO magazine, John Paul Mueller has written a new article, ABC: An Introduction to Agile Programming, targeted at IT managers looking for a brief overview of agile methodologies. For those new to Agile, John concisely answers the following questions:
  • What Are the Business Reasons for Using Agile?
  • What Makes Agile Programming Different?
  • Won't I Have to Do a Lot of Extra Work?
  • What's Different, Besides Working in Iterations?
  • Won't Working Like this Change Our Corporate Culture?
  • When Should I Avoid Using Agile Programming Techniques?
  • Is There Just One Kind of Agile Programming?
The overview speaks well of agile practices, with the possible exception of John's answers to the question "When should I avoid using agile programming techniques?" John gives four situations in which a managers should avoid adopting agile methodologies:
  • Creating a huge application that can't be broken down into small pieces
  • For applications that require a distributed development
  • Building a mission-critical application where every single piece has to work at the outset
  • If the company has a command-and-control management style
Although management fear in these situations is understandable, Joshua Kerievsky responds:
Your section on "When Should I Avoid Using Agile Programming Techniques?" is something I would've expected to see in 2001, not in 2007... the XP/Agile world has utterly shattered ideas that XP/Agile doesn't scale past 20 people or that it doesn't work on distributed projects...

Industrial Logic (my company) does 100% of its programming using distributed XP and we're quite happy with the results. We do distributed planning sessions using real-time planning software (called ProjectCards), we use Skype to have voice and video conferences, we use VNC to do desktop sharing, and we all integrate into a shared repository. It works so well that now we don't think about geography when we hire people, since we know that we can do our distributed agile process with great people from around the globe.

A strong rebuttal. However - Joshua's experiences notwithstanding - any organization adopting agile practices for the first time shouldn't underestimate the difficulties of doing agile with a distributed development team, or applying agile to build a large, mission-critical application. In particular, those seeking the adoption of agile within their organization should pay heed to John's fourth example - the company with a command-and-control management style. This is a subset of a larger problem: trying to foster open and honest communication within an organization where open and honest communication isn't valued. Changing the value system of an organization demands efforts towards community development, which is ordinarily beyond the scope of any but the most ambitious of agile teams.

  • This article is part of a featured topic series on Agile

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

That is a good laugh by Bruce Rennie Posted
4 signs of yours company death by Mikhail Zelenin Posted
Further information on key Agile Development principles by Kelly Waters Posted
  1. Back to top

    That is a good laugh

    by Bruce Rennie

    I do have to admit I laughed when I read the 4 situations listed. Those should be retitled from "4 situations not to use agile" to "4 indications you may already be in a world of hurt and just don't know it yet".

  2. Back to top

    4 signs of yours company death

    by Mikhail Zelenin

    John has been exactly noticed the signs of rotted company. We can say if a company cann't use Agile it wouldn't live any more. It is not perish right now. But wait a litle and you will see the sunset of inflexible structures.

  3. Back to top

    Further information on key Agile Development principles

    by Kelly Waters

    You or your readers may be interested in this blog all about agile development:

    www.allaboutagile.com

    In particular there is a description of 10 key principles of agile development, irrespective of which methodology you may be using:

    kw-agiledevelopment.blogspot.com/2007/02/10-thi...

    And there's also an agile development forum "all about agile" for further discussion with peers:

    www.groups.google.com/group/allaboutagile

    I hope these resources are useful.

    Kelly Waters
    www.allaboutagile.com

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.