Using Agile in less-than-perfect situations since Y2K
A mailing list pointed me to a recent post by Jeremy Miller on Agile design and an older one by Joe Ocampo. Both discuss how design happens in an Agile project. Both are great posts. Jeremy’s post sticks largely to what is considered the Agile “party line”: design is done all the time rather than up front. Joe’s post talks about using Domain-Driven Design to develop the “ubiquitous language” that teams need for communication. Jeremy admits in the comments that a bit of up-front establishment of a domain is useful as context, but distinguishes it from design. Presumably he is equating it with analysis. Having written a book that, in part, shows how use of consistent domain modeling patterns can inform design and implementation, I would say it’s both. But that’s not what I want to talk about….
Reading these posts and exploring a bit further, I began to relate the establishing of a domain context for stories with establishing an architectural context.
One of the main challenges I have faced and hear others describe is how to maintain agility when there is a scope of multiple Agile projects (what the PMBOK would call a program) or an enterprise portfolio that really needs consistent architecture. I am generally a believer in simple, evolutionary design. However, as Jeremy points out in his post, it requires people with the proper skills to maintain an open design/architecture and who know how to tell when they have reached the last responsible moment. What I have discovered is that as the scope of systems under development scale, the last responsible moment for certain architectural decisions tends to shift earlier.
As such, a reasonable step would be to include a (short) architectural analysis session for each release that would mirror the domain modeling exercises Joe mentions late in his post. In that way, those with architectural knowledge could get involved and discuss what architectures support the features required and which decisions need to be agreed up front. Provided this is timeboxed and the group puts appropriate emphasis on postponing that which can be, this is in line with Agile values as well.
I should also note that I would only add this practice if the team found it necessary. As a coach, I might recommend it upon seeing the following things either in a retrospective or during planning or other working sessions:
- multiple components, libraries, and/or frameworks in use that accomplish the same goals
- “not invented here” syndrome
- lack of integration testing between project teams’ output
- failure of or difficulty with coordinated deployment (usually preceded by the lack of integration testing)
- no or limited consideration of nonfunctional requirements (performance, stability, etc.)
- failure to meet nonfunctional requirements
I’m sure there are other smells that would indicate a need for architectural planning. If you think of others, let me know in the comments.