Attended the
2010 Michigan Agile and Beyond "mostly free" conference on Saturday, March 13. There was a strong turnout - close to 400 people showed up on a rainy, blustery Saturday. Turned out to be wonderful day for being indoors.
A lot of attendees were unfamiliar about Agile (with a capital
A - ie. use of any formal agile methodology, separate from
agile the adjective - you can do the former without necessarily achieving the latter) and were there to get a better idea of what it was all about. A lot of questions asked during a panel discussion on "real-world" practice tended to reflect that - "what about large teams", "what about architecture", "is test-driven development realistic", "what about fixed-price bids?" All of these questions are valid, and the answers are often the same regardless of what the development methodology is. Coordination with large teams is always hard, exponentially so with increasing size. Power-point architecture doesn't work very well regardless, and the implementation phase always throws up previously unknown issues. Etc.
This theme continued during a lunch-time conversation with a couple of acquaintances from Ford.
We have complex systems, and work with other teams that may not be agile. It requires longer analysis. The DBA team works with a 5-day SLA. Can't keep changing the database. I adopted the Socratic method, asking a series of questions that allowed them to question some underlying assumptions.
One of the speakers made a great point - to make
it work, where
it is adopting
agile all the way concept to development, you need buy in from the very top and the very bottom. It will not fly unless both are absolutely committed.
There is an engineering aspect related to agile practices. But it is not all about making programmers work faster or just improving the development process. The iterative nature of agile is about enabling better decision-making by allowing course corrections sooner rather than later and by accommodating inevitable change.
