Randy (Granville) Miller is an architect for Microsoft. He has a Microsoft blog. Last week i attended his session, "Agile Architecture" at the Dr. Dobb's Architecture and Design World Conference.
His talk started with a quick overview of agile and its benefits. As a side note, i was amazed at how much of that talk was happening at the conference. I assumed (there i go again) that it was so prevalent now that it was roughly a given. Apparently i assumed incorrectly.
After that was out of the way he talked for a bit about the place of architecture in agile methods and the disconnect between engineering practices and an entire business process or system. He used a quote from Kent Beck that is really spot-on:
My bias in writing XP originally was towards the
programmers. That’s my background. That’s
who I identified with on teams. However, the
past five years have taught me that software
development can’t be “the programmers and a
bunch of other people�if the goal is excellence.
Without balance between the concerns of
everyone involved, some people will be unable
to contribute to development, and their views are
important to the team’s success.
My team's nearly 2 year experience with Scrum has certainly proven this out. In fact, Scrum's biggest benefits have materialized in communications and project management benefits over strict engineering benefits. While combining multiple roles on a single team is a fundamental agile tenet, the role of Architect is not often discussed and less so in an Agile Context. XP, Enterprise Scrum and Microsoft's MSF stuff were mentioned as methodologies that discuss the architect and architecture. The notion that architecture was unnecessary in an agile project was brought up as a fundamental myth about agile practices. After nods all around, he made his first suggestion: build stories to verify the architecture in a deployed sense, not on paper. For a client server application, build the client and the server with a really simple interface or a stub, but make it real. Put it in your environment and let it run. The appeal of making a design tangible is pretty interesting, even if it gets difficult for a lot of cases.
The rest of his presentation focused on the concepts of shadows. Working or existing code can cast what he called "Trailing Shadows". Reverse engineering databases into ER diagrams, java code into UML diagrams, etc. In my team, this has been incredibly valuable. It is a common sense task to take stock of what you have and document it, but i really like the term Trailing Shadows as an indicator of architecture. The mixture of a legacy code base and an expanding engineering team makes that particularly necessary for my team.
On the flip side of that, he talked about "Leading Shadows" from a design. Our leading shadows could come from whiteboard sketches, notebook pages, quick visio diagrams, etc. He stressed that these shadows should turn into working code within an iteration and not devolve into Big Design Up Front. Following on this discussion, he stressed building scaffolding for these sketches, writing tests for them and getting them into your continuous integration environment. A chart from his presentation shows the ideal progression of leading and trailing shadows over the course of a project.
As part of a retrospective after an iteration, review the shadows, suggested Miller. If you have leading shadows still, you need more development. If you have trailing shadows, then you are done with this architectural change.
The final interesting part of the talk was a focus on the inverse relationship between project size and the length of iterations/integrations. He gave an anecdote about the size of the team for the last Visual Studio release (~4-500 developers) and the 2 month iteration size. They found that they spent a ton of time doing integration testing and conflict resolution. This seems like a no-brainer, but is often hard to put into practice.
The shadow architecture concept is part of the Microsoft System Foundation for Agile Software Development. On that basis, i am going to do a little reading on that system. I don't develop for windows or use Visual Studio, so we'll see what is applicable.
Miller's talk was one of my favorites at the conference and helped me get some perspective on the "What is my sprint to sprint role as an architect?" question. His speaking style was great, the presentation flowed well between his material and the audience questions.
and have been reading through it every once and a while. I decided today to try to work through that book and translate the examples to python along the way so i can learn nodebox a bit better and get through some more hands on processing work.
