Observations from the Agile Alliance 2009 Conference – Part 1

In my last post, I started a discussion on the relationship between Agile practices and Architecture. Last month I attended the Agile Alliance conference in Chicago to learn more about where the Agile movement is headed and where Architecture fits in.

First of all I want to say that it was a great conference with almost 1400 attendees. A lot of energy and excitement and sense of community. I think that sense of community makes a big difference in the overall conference “experience.” It’s one of the things that I’ve always enjoyed about the SATURN conference. (A little bit of personal disclosure. I currently hold the record for SATURN attendance by a non-SEI person – 5 straight years. Now that I’m working for the SEI, my record is up for grabs – maybe Derek Jeter will decide to go for it.)

Here are a few of my observations and reflections.

Agile is definitely moving more mainstream and being applied to larger projects. A lot of sessions and discussions about scaling up Agile.

There were several presentations on using Agile in government and safety-critical FDA applications, including one DoD project for scheduling satellite tracking stations. The presenter, David Morgan, talked about using an Agile approach to replace an aging system after three previous attempts, costing $20 million, had failed. He made the observation that there was a mismatch between the Agile approach and the DoD contract requirements for waterfall-style deliverables.

A lot of momentum for utilizing Lean, Kanban and the Theory of Constraints within Agile environments. These are all, of course, manufacturing concepts that I was familiar with from my days working on embedded systems. My company was heavily into the concept of Concurrent Engineering so the Engineers got a lot of cross-training on Manufacturing practices.  It was a little surprising to see these ideas turning back up in relation to Agile Software Development.

Regarding the Theory of Constraints, it might be interesting to examine the extent to which an unsuitable architecture could be viewed as a constraint on a team’s ability to deliver customer-facing features.

Alistair Cockburn gave a very entertaining and thought-provoking keynote, complete with a bagpiper and an adaptation of the funeral oration from Julius Caesar.  The keynote was entitled “I Come to Bury Agile, not to Praise It” and addressed the future of Agile in the 21st century as it becomes increasingly utilized on more diverse, distributed, and large-scale projects.  Back to the manufacturing analogy, one of Alistair’s statements was “Software development looks like manufacturing, if the unit of inventory is the unvalidated decision”. I can’t say that I’ve really internalized what that means yet, but I’m keeping it in mind with respect to architectural decisions.

Somewhat related to interest in the above-listed manufacturing process improvement techniques, is an increased interest in Agile metrics.

Definite momentum for moving beyond the developer-centric origins of Agile and exploring the integration of other roles (including Architects and Testers) into the Agile paradigm.

There were a couple of sessions related to non-functional requirements, including one that I attended by Ellen Gottesdeiner entitled “Beyond User Stories: Identifying Missing Links in Your Product Backlog.” Awareness within the Agile community that functional stories are not enough is on the rise.

Two presentations of particular interest were a talk by Mike Dwyer of BigVisible entitled “The Impact of Agile Architect Teams in Scaling Enterprise Efforts” and a talk by Scott Ambler (now at IBM Rational) entitled “Agile by the Numbers: What People are Really Doing in Practice.” I’ll write a little more about these sessions in subsequent posts.

- Nanette Brown, SEI

About these ads

5 responses to “Observations from the Agile Alliance 2009 Conference – Part 1

  1. Very nice summary, Nanette. I too agree that Agile and architecture need to further integrate.

    I posted a blog article on our experiences over the past year with integrating SCRUM and architecture on a language learning courseware product.

    If you are interested, you can find the article at: http://charliealfred.wordpress.com/scrum-and-architecture-partners-or-adversaries/

    Charlie

  2. Agile practices are certainly exciting and hold out great promises for reduced development time and costs.

    We have been using an adaptation of such an approach in our isntallation. The misgivings I had from our experiences relate to the fact that we seem to end up with either none or very little documentation at the end of the concerned projects. Once we have implemented successfully, the system we installed no longer features on the six o’clock news and the need to document gets soon forgotten.

  3. Hi Nanette Brown,
    You mentioned the case of DoD project. Any more detail info or materials on the mismatch between the Agile approach and waterfall-style?

    • Hi Zhou Licheng,

      Thanks for your comment.

      The Agile-Waterfall mismatch can definitely be problematic and can occur in commercial as well as DoD projects. For example, you may have a blended development effort with in-house teams using Agile and a vendor using Waterfall.

      In terms of references, in the Second Edition of his book Agile Software Development, The Cooperative Game, Alistair Cockburn provides an interesting discussion of how to structure contracts to make them more amenable to Agile development and delivery. “Black-box” style contracts tend to encourage vendors to adopt waterfall-style practices. One approach to contracts that Cockburn describes is to structure incremental vendor payments upon the receipt of integrated and tested increments of system functionality. The discussion of contracts is in Chapter 5, starting on page 312.The book is a great read on a number of aspects of Agile development and I highly recommend it.

      You might also want to check out an article that Cockburn cites in his book – “Making Agile Development Work in a Government Contracting Environment” by Glen B. Alleman and Michael Henderson. It’s an interesting fusion of Earned Value with Agile techniques. The link is http://www.niwotridge.com/PDFs/ADC%20Final.pdf

      Regards,
      Nanette

  4. Thanks, Nanette!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s