Agile Architecture | Agile Transformation
Lean Architecture Principles: Wrap up! Sander van den Berg 11 Aug, 2010
Yes of course. Why do you think you only have to focus on the prioritized list of requirements? As a professional programmer you should always keep thinking ahead (not too far ahead though…), keep the big picture in mind see the coherence between the User Stories. If it is not clear to you make sure you ask your teammates or the PO. There is nothing in TDD or Scrum that says “Forget about the big picture”. Practicing TDD in my opinion doesn’t mean you don’t do any design at all.
Customers are just about to see importance of good architecture and role of an architect. Most of the projects I've been working on, architecture was done by developer as a secondary task and it was always a mess. Although they didn't use Scrum, I don't believe Scrum would solves this problem. Saying to developers "keep the big picture in mind" does not solve the problem. In my experience, it only creates inefficient discussions because of the lack of knowledge about all kinds of stuff (business & IT strategy, standardization, politics, and so on). The discussions are about their believes which technology is the best and they hardly see for example the complexity of conflicting requirements. By the way, architecture in this context is not only technical. All this does not mean that programmers shouldn't be involved in design and architecture. In contrary, as much as possible. Besides, defining architecture is a very dynamic process and fits well in Scrum and Agile principles.
I don’t think that people working with Agile hate UML. I don’t at least. What I don’t like, however, is creating upfront sequence diagrams, which is also part of UML (mainly for the reason that I usually come up with all kinds of unnecessary abstractions which just look great, but are not needed at all). Upfront, and afterfront class diagrams help a lot to understand the system and the relations in the domain model, and also a deployment or other kind of overview diagram helps greatly in understanding the system.
In the design-to-help-you-think category I also use diagrams to understand code during audits. Sequence diagrams really shine here since they give me a quick overview of how one component uses another, which I find useful. If you're going to create diagrams for documentation I think UML is the standard. For sketching on white boards however you might as well draw rectangles.
For a while now I've come to value "good documentation" in a different way. I don't believe UML is better or worse than sketches. With Robert vL I've been doing lots of stuff with multimedia in our work. So my answer to "good documentation" is not UML vs. sketches, it's using multimedia for the stories, writing and diagrams for reference. I have found it to be very much more effective than the best document ever written.Please leave your comments about this topic and what you think in general about Agility in practice.