Find a way to anchor user requirements to practical building blocks.
It is important to understand what a user wants and why, through the gathering of user stories. However, requirements can quickly become unrealistic wishlists unless they are kept in check by architects who understand how the building blocks fit together. If you are leading an Agile environment, make sure both the aspirational and the practical voices are kept in balance.
A user can describe what they want to see on the screens and how the features should work. They are unlikely to understand much of an architect’s jargon but you have to bridge this gap so the user understands something of how the user interface is delivered to her screen. She knows the result she wants when a certain button is clicked but it’s advisable to explain what happens behind the screens to deliver that.
This accomplishes two things; first it keeps the conversation real and second the ongoing education of your customer improves the quality of future requirements. Reality is crucial; “I want this to happen here, what happens when I click this, why can’t I get that result not this result.” Expectations are best managed in small doses rather than with big disappointments.
Once a customer understands the basic workings of what happens behind the scenes not only do they approach their user stories with a sense of reality but the quality of their requirements improves. Less time is wasted in explanations and more time is spent understanding. Test if you are making progress by asking your customers to draw basic diagrams of how the software works.
Typically the role of Architecture Owner ensures that the architecture is developed and evolves with the solution. They perform a vital function on an Agile team and should hold their ground on key principles but adjust style and engagement with the rest of the team when it matters. The architect doesn’t build the house but they make sure it’s a house you actually can build before you spend time finding out the hard way.