TL; DR: Agile Laws in Software Development
On many occasions, working with agile teams has amplified existing organizational, technical, and cultural challenges in many organizations. Starting to change always requires the acceptance that there is a problem that needs attention. The following article addresses some of the most prevailing impediments to achieving agility by revisiting several agile laws that are particularly relevant to any team’s effectiveness in solving customer problems.
The most popular discussion on LinkedIn last week was: The MinimumViableLibrary — #ProductOwner v2.0 edition!
📖 Your single best investment to improve your professional standing; order the Scrum Anti-Patterns Guide book now!
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 49,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
🇩🇪 Zur deutschsprachigen Version des Artikels: Agile Gesetze: Von Conway über Goodhart bis Occam’s Razor.
Agile Laws: Applying Conway, Brooks, Hackman, Goodhart, Larman, and Parkinson in Practice
From the long list of observation, heuristics, and mental models in psychology, organizational design, or software engineering, I pick eight “agile laws” that seem to be particularly relevant in software development:
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 build 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 water cooler. With distributed teams, this approach has become less of an opportunity, given the additional communication overhead and the inherent formality of organizing yet another 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.)
Cannot see the form? Please click here.
Brooks’ 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.”
And yet, the typical reaction of 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 idea to agile teams, we need to return to the middle management and the real or perceived pressures an organization imposes. A perceived loss of control, particularly in remote settings with 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 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 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 people’s behavior to change, the system must first change. Attempting to change the culture of an organization without changing the underlying system will fail. Any need to change to respond to a 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 creating 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 agile teams is that the shipping routine sometimes tends to be valued higher than the learning part of the equation. 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.
Little’s Law
Little’s Law is a critical guide, as it concisely frames a core principle: the tasks in progress are a product of the arrival rate of tasks and the time they take to complete: Work in Progress = Throughput × Lead Time.
This relationship balances the workload and enhances delivery predictability, ensuring teams operate efficiently without overburdening themselves. Applying this flow principle makes it an essential tool for managing workflow and maintaining a sustainable pace in software development. It also advocates a step in case of lacking team effectiveness that many managers find controversial: To improve the flow and output of struggling teams, reduce the input. (That is the origin of the point of limiting Work in Progress.)
Learn more about Little’s Law in this free whitepaper from Scrum.org.
Occam’s Razor
In software development, Occam’s Razor promotes simplicity in designing and building software systems. It advises choosing the most uncomplicated solution among equally effective alternatives, reducing unnecessary complexity, which aligns well with agile principles, like minimizing over-engineering. This principle is akin to the KISS (Keep It Simple, Stupid) approach, which also advocates for straightforward problem-solving.
Violating Occam’s Razor manifests through various anti-patterns. Over-engineering and gold plating add unnecessary complexity and features, while Big Design Up Front contradicts Agile’s iterative nature with excessive upfront planning. Feature creep unbalances the project scope with continuous unplanned additions. Misusing design patterns, ignoring the need for regular refactoring, and overlooking technical debt lead to a cluttered, inefficient codebase. Moreover, over-reliance on complex tools and technologies for simple problems further complicates the development process.
Learn more about Occam’s Razor.
Agile Laws — Conclusion
Working with 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.
📖 Agile Laws — Related Content
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.
Download the Scrum Anti-Patterns Guide for free
📅 Scrum Training Classes, Workshops, and Events
Learn more about agile laws by securing your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn more about Agile Laws: Join the 19,000-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.
Learn more about agile laws with the free Scrum Anti-Patterns Guide:
