Abstract: The role of "Architect" is sometimes frowned upon in the Agile community as a central command-and-control authority who bottlenecks decisions and limits team empowerment. Or at least, that is what we thought. Follow the real-life journey of our teams as we discovered how the role of an architect is compatible with Agile principles. We will explore our failures, and eventual discovery on how the role brings can bring an immense amount of value to the organization and the teams, especially on large, multi-team projects.
This talk relates our experiences in integrating an architect role with several teams at IHS Inc. Faced with the challenge of scaling several teams working on the same product, we quickly discovered the need to exchange technical information between the teams. How were we to maintain an appropriate level of technical consistency while remaining true to Agile principles? We explicitly wanted to avoid an authoritative architect role, but struggled to find an alternate model. After initial failures, we eventually learned the important relationship between leadership and architecture. Ultimately, we discovered a successful pattern for an architect role that preserves emergent design and team empowerment while maintaining minimally sufficient technical consistency.
Our organization is comprised of approximately 40 people on 6-7 teams developing 3 separate products. Between 3-5 teams are working simultaneously on the Harmony Enterprise project. The challenges of this project are the focus of the presentation.
Learning Outcomes: - Our initial approach of the architect was to be a “scout” that did investigations and provided a stream of information to the teams. We encountered several issues with this approach:
- - Communication would breakdown. Info would be misunderstood or missed. This often became the "architect's fault" for not communicating enough information.
- - Different teams had different design values, and thus there was friction between the teams who had different expectations of the designs coming out of other teams. We could not yet engage in meaningful, objective design discussions. Again, this became perceived by the teams as "the architect's fault".
- - We learned quickly that we were "wrong" about our architectural approach. This was an agile victory because we discovered it early, but it was not well received by the teams who perceived someone else's mistake as causing them more work.
- We value consitency in several areas (Coding standard, design values, architectural approach), but we failed to engage the teams in decision making process. Through one-on-one conversations with Scrum Masters, we developed a "Design scrum-of-scrums", in which the Architect facilitated a daily 30-minute meeting with representatives from each team ("Design Quarterbacks"). His goal is not necessarily to provide answers, but to guide the conversations so the teams are considering all the right things and reaching a decision that they can buy-into. Previously the Architect would be responsible for doing research and prototyping, but now acts as the role of Coach while the teams take on this responsibility.
- Our experience with this approach as proved very positive.
- - Relationships between teams has improved which has results in much more communication.
- - Problems with designs are discovered much quicker, because the teams have more information
- - A common mental model (“Conceptual Integrity”) exists across teams, which results in reduced rework.
Attachments:
