|
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.
👉 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.
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.”
🎓 🖥 🇬🇧 Professional Scrum Facilitation Skills Class w/ PSFS Certificate — February 15, 2024
The Professional Scrum Facilitation Skills (PSFS) training by Berlin Product People is a one-day official Scrum.org class for advanced Scrum practitioners and agile coaches, including the industry-acknowledged PSFS certification. This PSFS training class is in English.
Enjoy the benefits of a live-virtual immersive class with like-minded agile peers from 09:00 – 17:30 o’clock CET.
Learn more: 🖥 🇬🇧 Professional Scrum Facilitation Skills Class w/ PSFS Certificate — February 15, 2024.
Customer review: “Great experience – “You reap what you saw.” What I really liked about it was the constant usage of facilitation techniques & Liberating Structures to engage all participants & harness the collective knowledge while reaching the goal of the exercises during the workshop. Therefore, my experience was great because I could really leave with some insights from the whole group that I could apply in my daily work starting from the next day. “You reap what you saw” and in this case, it was the collective intelligence of everyone in the training class.” (Link.)
If you have friends or colleagues who might be interested in this article as well, please forward this email—it would mean the world to me!
Have a great day!
Best,
|
