{{announcement.body}}
{{announcement.title}}

Agile Laws and Distributed Teams: From Conway to Goodhart to Parkinson

DZone 's Guide to

Agile Laws and Distributed Teams: From Conway to Goodhart to Parkinson

The article revists several Agile laws that are particularly relevant to distributed agile teams: from Conway to Goodhart to Parkinson.

· Agile Zone ·
Free Resource

TL; DR: Agile Laws and Remote Agile

On many occasions in the recent past, working with distributed Agile teams has amplified existing organizational, technical, and cultural challenges in many organizations. Starting changing, and I am not referring to the introduction of a new video conferencing tool, always requires the acceptance that there is a problem that needs attention. In that respect, the current issues that many distributed teams face may also act as accelerants to become more Agile. The following article addresses some of the most current impediments to achieving agility by revisiting several Agile laws that are particularly relevant to distributed Agile teams.

Agile Laws: Conway, Brooks, Hackman, Goodhart, Larman, and Parkinson

From the long list of observation, heuristics, and mental models in psychology, organizational design, or software engineering, I pick six “Agile laws” that seem to be particularly relevant in this area of distributed Agile teams:

Conway’s Law

Mel Conway first postulated his thesis in a paper from 1968, stating that:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” ( Source.)

In other words: If two teams are building a part of an application separately, that system will probably have two components, introducing dependencies and additional communication overhead.

That has always been a challenge. When teams are co-located, at least you can negotiate issues informally over a coffee or the watercooler. With distributed teams, this approach has become less of an opportunity, given the additional communication overhead and the inherent formality to organize yet another a Zoom meeting.

One possible way to address the issue is the inverse Conway maneuver: “…you may want to begin by breaking down silos that constrain the team’s ability to collaborate effectively.” (See also: Torbjörn Gyllebring: The Reverse Conway — Organizational Hacking for Techies.)

The idea has been around for several years: design the teams according to the product requirements and give them autonomy to create the best possible solution from both a value proposition and an organizational sustainability perspective.

(Free paper on Conway from HBS: Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis.)

Brooks’s Law

Frederick Brooks stated in his 1975 book The Mythical Man-Month: Essays on Software Engineering that “adding manpower to a late software project makes it later.”

The challenge that we face now is that the productivity of newly distributed teams is likely to suffer, see “Conflicting Reports on Remote Worker Productivity and Contentment.”

The typical reaction of the middle management, driven by a bias for action to show initiative, fight the crisis, and overcome a perceived loss of control, is probably to assign more people to a fledgling project, instead of allowing the teams to adjust and entrust them with more autonomy.

Hackman’s Law

Adding more people to a team or project to accelerate delivery also contradicts another Agile law, Hackman’s law: “The larger a group, the more process problems members encounter in carrying out their collective work […] worse, the vulnerability of a group to such difficulties increases sharply as size increases.”

In a remote working situation, to make matters worse, there is a compound effect due to the increased communication overhead. Hence, an appropriate strategy to counter this effect would be employing small, Agile teams and an organization designed as a team of teams, aligned yet autonomous.

Goodhart’s Law

Back in 1975, the British economist Charles Goodhart first published the idea that would carry his name, when he wrote about monetary policy. The anthropologist Marilyn Strathern later summarized it as: “When a measure becomes a target, it ceases to be a good measure.” (Doc Norton: “And the target therefore no longer means what you think it does.”)

Applying this to distributed Agile teams, we need to come back to the middle management and the real or perceived pressures the crisis, the organization are imposing. A perceived loss of control due to remote and often asynchronous communication, and the urge to ensure being visible in communication artifacts may result in a tendency to run a tighter ship: more reports, more metrics, and more meetings.

Again, reversing course in this manner in the middle of a massive, complex change — imposed from the outside — with an uncertain outcome is the opposite of the appropriate action. Exercising more command & control to counter complexity does not work as any experienced leader will note. (Eli Goldratt: “Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way […] do not complain about illogical behavior.”)

The alternative is creating room for autonomy and putting trust into people: “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.”

(Curtis Carlson: “In a world where so many people now have access to education and cheap tools of innovation. Innovation that happens from the bottom up tends to be chaotic but smart. Innovation that happens from the top down tends to be orderly but dumb.”)

Larman’s Laws

You might now ask how come that organizations so often fail to create organizational structures that are flexible, yet resilient. Craig Larman formulated a reason for that:


“Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.” ( Source.)


This observation reflects the systems-thinking approach to change: If you want the people’s behavior to change, the system needs to change first. Attempting to change the culture of an organization without changing the underlying system will fail. The currently imposed need to change to respond to the crisis will thus have to target the system itself, not merely the operational or tactical procedures.

Parkinson’s Law

The reason why time-boxing is such a valued practice among Agile teams is simple: “Work expands so as to fill the time available for its completion.” (Parkinson’s Law.)

When trying to create valuable, sustainable, and profitable products in complex environments, a rapid feedback loop is essential: Build, measure, learn. Waiting too long before shipping, or pursuing perfection, is not an option. Instead, Sprints, cycles, iterations as well as inspection and adaptation is the name of the game. We aim at iterating fast enough to keep in sync with the market, yet avoid too much overhead with Sprints that are too short.

The issue with distributed Agile teams is that the routine of shipping sometimes tends to be valued higher than the learning part of the equation. Admittedly, “learning” is more difficult in a remote setting, but not impossible. But focusing on the shipping part to comfort our bias for action to tackle uncertainty, we are moving closer to becoming a feature factory—which is the opposite of creating a team of autonomous teams, solving problems on behalf of our customers.

Agile Laws — Conclusion

Working with distributed Agile teams has amplified existing organizational, technical, and cultural challenges in many organizations. In that respect, revisiting ‘Agile laws’ has proven helpful in addressing those impediments. Probably, you may even be able to use these issues to your advantage. As the saying goes: “Every problem is an opportunity.”

Have you experienced any of these Agile laws recently? If so, please share it with us in the comments.

Topics:
conway's law, distributed agile, distributed agile teams, goodharts law, impediments, remote agile

Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}