Part of day job is currently taking the lead architect role for a largish development project, which is organized according to SCRUM. With all the advantages an agile approach has, there is no built-in role for an architect in the model, and a lot of potential for conflict between the iterative approach and the need to have a planned and predictable architecture.
The SCRUM teams are obliged to take responsibility in the design of the product. They are held accountable for the success of their sprints, for which they need the ability to deliver reliable estimations. This becomes somewhat of a challenge when the product’s framework is still work in progress, and changes are factored into the architecture. I strongly believe that having an evolving architecture and requirements-driven framework development is the best way to cope with a complex product and an agile environment, but still, the approach creates a problem when teams have to factor changes into their sprints. Even if improved framework capabilities solve workarounds an clumsy details better, there’s code to change, and the teams may not have full visibility of what’s coming (yes, and there’s the question who decides when to push architecture and framework changes into the sprints – that’s yet another story).
The approach I take to have the teams better prepared to coming changes is to make the architecture process transparent. When the creation of code is an open process that can be monitored by visiting the daily SCRUMs, the creation of architecture should also be an open box.
The main means for opening the process is a weekly public presentation in which each member of the architecture/framework team presents her or his work in progress. The meeting has a fixed length, depending on the number of people presenting: everyone gets ten minutes, followed by five minutes of open discussion. The presentation form is non-formal; you can bring a code walk-through, a slide show, or just speak. In order to simplify matters, everyone who’s interested can come in. It takes place each Wednesday afternoon, no exceptions. We have a meeting room for about 15 people (or 25 when you don’t mind the air).
Going on for some months now, I’d consider the format of the meeting quite a success, yet not flawless:
• I find it valuable for myself to demo each week. It helps gathering up my own thoughts, and keeps the demonstration skills fresh and practiced.
• The discussions following the demos have more than once led to early corrections. They act as a small and regular peer review.
• Feedback from visitors is that they can much better predict the direction that we’re going, and appreciate the involvement in the process.
• I would have expected more feedback from the SCRUM teams in order to exercise a stronger influence on the direction that the architecture is taking. The major part of the discussion after the presentations comes from the architecture/framework group itself. Maybe we need to be more disciplined in keeping our mouths shut for one or two minutes so that others have the chance to form their thoughts and speak up.
• Participation is somewhat inconsistent: while the room is full one week, it’s only the architecture team the next. In addition, there are SCRUM teams that are represented almost every week, and sometimes with three people or more, while another only rarely shows up.
• The meeting is quite expensive. With everyone present, there are six people presenting, making it a ninety minute time slot with uncertain return of investment for visitors.