More on the Agile Architect: Process and Knowledge Transfer

webscrum_2444372bI’ve written about groupthink-related quality challenges on Agile projects, and the architect’s role in preventing groupthink from degrading quality. I’ve seen other risks related to the cohesion and potential insularity of successful Agile teams, and the architect is also well positioned to help prevent these: a tendency to neglect setting up and documenting repeatable processes, and a similar tendency not to share of knowledge and lessons learned outside the Agile team.

Agile Versus Needs Process

In my experience, self organizing Agile teams develop an internal culture featuring strong mutual respect and emergence of natural leaders, which team members might characterize like this: “With all these great people we’ve become a really good team, and we’re so lucky we have Mary Jane, she is so knowledgable and a great leader!” Clearly it is wonderful when a team gels, but the easy communication and close relations among a highly functional Agile team can encourage the team to work informally, and discount the importance of process.

Furthermore, Agile’s sticky-note, verbal-update culture tends to value informality and disparage process (here). As one study puts it, “[to agile practitioners,] agile maturity means fostering more subjective capabilities, such as collaboration, communication, commitment, care, sharing and self-organization.”

However, I’ve always thought that agile and process-orientation are compatible. Perhaps this video says it best: agile doesn’t mean improvisation, and it doesn’t mean that teams need to reinvent the wheel every time they do something. For example, if Juan is the one who always ends up regression testing when there’s a new release and he never writes down how he does it, the next software release can be at risk if Juan suddenly moves on to a new job. Of course, the process and its lightweight documentation should be “just good enough” to ensure it is clear to Juan’s successor and repeatable.

The highly cohesive agile team will be in great shape if the team overall or Mary Jane, the emerged natural leader/architect, understands the need to record and repeat processes for requirements definition, development, test, and deployment. However, if the team lacks the experience to recognize the value of defined process then quality might only last as long as team cohesion.

Sharing Outside the Agile Team

Even after two decades, agile hasn’t yet displaced waterfall in many large organizations, and portfolio-level agile methods like the Scaled Agile Framework (SAFe) are still overcoming resistance to change from planning and budgeting departments, not to mention waterfall advocates.

But every lagging organization seems to have one or two agile projects going on, and to the rest of the organization they are “special”, often a cloistered group of people speaking in their own strange project language and working on a cool new technology, like (in my field) Tableau, Cassandra, or Spark.

Agile jargon and technology differences are often enough for there to be little in common between the agile team and the surrounding organization, and the cohesion/insularity mentioned above contributes as well. But often part of the intent of setting up the team is for the organization to learn agile methods and the new technology being piloted.

Team/architect recognition of this knowledge transfer responsibility can determine the perceived success or failure of the team. Specifics will vary by organization, but the team can improve chances of lasting impact by communicating actively with those outside the “inner circle”. Hosting lunch-and-learn sessions, inviting large groups to sprint end demos, writing a newsletter, and, yes, teaching out team processes, might be just a few knowledge transfer examples.

The Role of the Architect

In the above-referenced post I cited Andrew Johnston’s advice that the Agile Architect be “in but not totally of” the project. In addition to being an outside influence guarding against diminished quality due to groupthink, the architect should help the team define and maintain lightweight, appropriate processes and effectively transfer knowledge to the rest of the organization.

Leave a Reply

Your email address will not be published. Required fields are marked *