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