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.
📅 Join the 25th Hands-on Agile meetup on August 20, 2020, to explore the virtual Ecocycle Planning.
Do you want to get this article in your inbox? You can sign up here and join 26k other subscribers.
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.
📺 Remote Agile: Practices and Tools [Replay of a Live Virtual Class]
At the end of March, we ran a Remote Agile Practices & Tools live virtual class with about 30 participants from all over Europe, the Eastern Seaboard, and Canada. The participants agreed on recording it and make it available to the agile community. We edited the recording slightly; for example, we removed the waiting time during the exercise time-boxes. Otherwise, the video accurately reflects how one way of collaborating with a distributed team using Zoom breakout rooms may work.
Except for three teaching blocks of about 20 minutes in total, the whole Remote Agile Practices & Tools class of 2:45 hours comprised of interactive work:
If you have any questions regarding the class, please let me know via the comments, or contact me in the Hands-on Agile Slack community.
If the video snippet does not play, please watch the video on Youtube: Remote Agile (1) Replay: Practices and Tools for Scrum Masters, Agile Coaches, and Product Owners.
✋ Do Not Miss Out and Learn more about the Virtual Strategy Session: Join the 7,800-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
Agile Laws — Related Content
Remote Agile Transitions — The Top-Ten Challenges.
Will the Tech Workplace Ever Be the Same Again?
Agile Failure Patterns in Organizations 2.0.
Agile (Part 4): Anti-Patterns — Pitfalls Successful Distributed Teams Avoid.
Remote Agile (Part 1): Practices & Tools for Scrum Masters & Agile Coaches.