In our twenty-third issue of the Architects' Newsletter we are focusing on the topic of technical leadership and teamwork. We believe these topics are vitally important, and in our latest Architecture and Design InfoQ Trends report we've placed "architect as a team leader" in the early adopter phase. Therefore, understanding all the emerging leadership patterns, antipatterns, and techniques is essential for a modern software architect.

News

How Design Systems Support Team Communication and Collaboration

In a recent InfoQ news piece, Ben Linders covered a talk by Stefan Ivanov, a senior UX architect at Infragistics, who spoke about the purpose of design systems, and shared experiences from creating Indigo.Design at ACE! Conference 2019. Ivanov argued that by using design systems, design teams can improve their workflow, reuse their knowledge, and ensure better consistency. They allow teams to fail faster and speed up the iteration cycle, which allows them to spend more time collecting user feedback in the early stages of product design, and reach the sweet spot of a product market fit much faster.

Nick White on the Lessons Software Engineering Can Learn from Multidisciplinary Medical Teams

In this recent InfoQ culture podcast Nick White spoke with Shane Hastie about the collaborative diagnosis approach used by a multidisciplinary team of specialists at the Wellington Regional Hospital Cancer Care Unit. With a complex diagnosis like cancer, the range of treatment options is wide, and their multidisciplinary approach combines the best possible treatments and successful patient outcomes. White argues that as technologists we need to be open to learning from other disciplines in areas such as collaboration approaches, dealing with handoffs and bottlenecks, and customer service.

There are some parallels between White's ideas and the surgery team in Fred Brooks' classic text The Mythical Man-Month. In this book Brooks cites a proposal from Harlan Mills which looks at surgery teams as a way of exploring the problem of building large systems on a meaningful schedule.

Mills proposes that each segment of a large project be undertaken by a team organized like a surgical team with specific roles:

• One "surgeon" doing the work; everyone else in support
• Few minds involved in design
• Highly segmented/independent tasks
• Minimal communication during operations; only 1-on-1

Although many of the ideas Brooks describes in this section have subsequently been questioned there is still something of interest in the core idea; it isn't too far from this to Jeff Bezos' Two-Pizza Team Rule, in which teams within Amazon contain no more than 5-9 people in order to minimize the number of interactions and relationships to be maintained.

Experience Building a QA Team in a Growing Organization

At TestCon Moscow 2019, Neven Matas, a QA team lead at Infinum, argued that "shifting the test team to the left" -i.e. by involving them earlier in the delivery process and pipeline- brought his entire software delivery team closer together, enabled faster learning, and improved collaboration.

Being a software agency, client demands from project to project tended to vary wildly, and one of the challenges Infinum had to deal with was adapting to a growing influx of projects. The one thing all Infinum projects have in common is recognising the benefits of involving testers earlier within the software delivery lifecycle and in all project-related matters, with an emphasis on continuous participation.

Q&A on the Book: Evolvagility: Growing an Agile Leadership Culture from the Inside Out

Michael Hamman's book explains how focusing on inner-agility through sensemaking, communication, and relationship intelligence can increase the outer agility of organizations. It describes sense-and-respond leadership, an approach to catalyzing the creation of outcomes by sensing acutely and deliberately, and responding gracefully. Ben Linders sat down with Hamman for a recent InfoQ Q&A, and explored the concept of agile leadership in more depth.

Case Study

The Evolution of Comcast's Architecture Guild

As Jon Moore, Chief Software Architect at Comcast Cable, recently described within a full-length InfoQ article, "Architecture with 800 of My Closest Friends: The Evolution of Comcast's Architecture Guild", modern software architecture in medium-to-large companies is increasingly a distributed affair. Agile methodologies, DevOps, and the microservices-based architecture pattern have all facilitated greater independence for teams to make their own technical decisions. However, many companies still rely on a tree-structured organizational model for internal communications, often creating silos where it is difficult to discover what choices other teams are making.

Comcast has created an Architecture Guild, with the goal of "threading the needle" between obtaining advantageous critical mass around certain common technologies, and not undermining individual teams' agency. The Architecture Guild is a grassroots framework that has been used to cut across organizational boundaries to identify solid, workable, default recommendations for technologies and practices, and is explicitly modeled on existing successful decentralized groups like the IETF.

A working group (WG) begins with a charter: a brief statement of topics the WG will-and won't-address. Since technical capabilities and practices are so interconnected, specifically defining certain topics to be "out of scope" helps constrain the WG's discussions and allow it to make progress. Once a charter has been defined, engineers create a dedicated chat channel for it, such as "#arch-wg-source-control", as well as a dedicated source code repository for the WG. Their creation is advertised in the main "#architecture" channel as well as on the mailing list, so that interested individuals can join and participate. They then recruit 2-3 co-chairs for the WG to serve as editors and to help the WG continue to make progress. Moore discusses how experience has shown that good facilitation skills are more critical than technical expertise for co-chairs.

The WGs are expected to document their recommendations as Architecture Decision Records (ADRs). These documents capture:

• Context: What information did we consider while making this decision?
• What do we recommend?
• Why did we make that recommendation?
• What are the known drawbacks?

The team found that WGs are tempted to jump straight to the decision point, but they have developed a more structured process to building "rough consensus". They begin by building up the context section of the ADR:

• Allow everyone to bring their relevant use cases; document these in the ADR
• Identify the core requirements a recommended solution MUST have, through discussion
• Allow anyone to propose a particular solution. Document this list in the ADR
• Briefly evaluate each proposed solution against the criteria-how it does or doesn't address each one. Document this information in the ADR as well

The goal - find a solution where the majority of participants rate it "acceptable" via scoring this proposal as a "3" or higher on a scale of 1 to 5. When participants give a solution a "2" rating, they are asked to document their concerns as issues in the ADR repository. From here, the WG is able to do additional research to document how that concern could (or sometimes, could not) be addressed in a particular solution. The Comcast team has found they are able to move some "2" votes to "3" votes through this process; sometimes the concerns arise (understandably) from unfamiliarity with a proposed solution, and commentary from someone with more experience often allays those concerns.

The final (and important) step, after arriving at a solution, is to make sure the participants captures any known issues that could not be resolved in the consequences section of the ADR. Every solution brings tradeoffs, and the Comcast team has found that capturing the legitimate drawbacks WG members identify is also a way to build support around the eventual decision, because those members can see that their input has been considered, valued, and incorporated.

This is an excerpt from a full-length article on InfoQ, "Architecture with 800 of My Closest Friends: The Evolution of Comcast's Architecture Guild".

To get notifications when InfoQ publishes content on these topics follow "Leadership" and "Team Work" on InfoQ.

Missed a newsletter? You can find all of the previous issues on InfoQ.

This edition of The Software Architects' Newsletter is brought to you by:

Nobody Understands DevOps

DevOps has occasionally been a controversial idea, both with people who insist it’s nothing more than a modern label for existing good practice in software development, and with those who reject the need for greater collaboration between development and operations.

There is also widespread misunderstanding about what DevOps actually is: A job title? A team? A methodology? A skill set? The influential DevOps writer John Willis has identified four key pillars of DevOps, which he calls culture, automation, measurement, and sharing (CAMS). Another way to break it down is what Brian Dawson has called the DevOps trinity: people and culture, process and practice, and tools and technology.

InfoQ strives to facilitate the spread of knowledge and innovation within this space, and in this newsletter we aim to curate and summarise key learnings from news items, articles and presentations created by industry peers, both on InfoQ and across the web. We aim to keep readers informed and educated about emerging trends, peer-validated early adoption of technologies, and architectural best practices, and are always keen to receive feedback from our readers. We hope you find it useful, but if not you can unsubscribe using the link below.

Forwarded email? Subscribe and get your own copy.