RESOURCES
Abstract/Description
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.
You must be a Member to view this post and you are currently not logged in.
You can either log in below or sign up here.