How much can managers of software projects learn from software itself? From actual code? Quite a lot. And not just general principles but also particular, actionable advice.
Conway’s Law reminds us that organizations tend to produce designs that mirror their internal communication structures, but what of a corollary? What if we managed projects with a communication structure that mirrored performant and flexible software design? This post is the first in a series that will explore that idea and its consequences.
For the purposes of this series, we will look to Robert Martin’s SOLID design principles as our guide to ideal software design, starting with the Dependency Inversion Principle.
The Dependency Inversion Principle (or DIP) states:
This same principle applies to project management.
We will start with a concrete example: Managers often try to compare sprint points across teams. But, instead of getting a useful read on the organization’s overall performance, they cause anxiety and conflict between teams that should be cooperating with or at least ignoring each other. This attempt to increase performance actually reduces it. Why? The manager engaged in the organizational equivalent of an external module directly comparing the private properties of instance variables instead of entrusting their classes with the task. If one did that in object-oriented software, this would violate the object encapsulation and, in turn, the Dependency Inversion Principle.
Breaking the organizational equivalent of object encapsulation hurts the manager, as well. Doing so burdens them with far too much knowledge of each teams’ inner workings. This makes their own work all that more brittle and cognitively expensive to maintain. The resulting quagmire of minutae makes it impossible to discern the higher-level issues within an organization.
What would an organization that followed sound software design principles in its management practices look like? At this level, managers would focus on the following responsibilities:
Some software equivalents to the issues listed above, respectively:
How would management based on software design principles look in the real world? Some examples:
JIRA, a popular choice of project management software in larger organizations, violates the DIP in its very design. It exposes far too many details of each team’s internal processes (like story points or developer subtasks) to the entire organization, particularly upper management. It purports to facilitate cross-team communication but burdens everyone involved with tracking a cacophony of details. The software binds teams to specific processes without regard to their particular needs. In short, the singular net value of the tool boils down to this:
Any project large enough to warrant JIRA needs to be broken down into smaller, more managerially-isolated projects that are each too small to warrant JIRA.
This problem is hardly unique to JIRA, but that particular software exemplifies it. Other tools, like Trello, purposely refrain from offering detailed reporting because their creators understand that doing so provides only an illusion of control. These alternatives try to avoid violating the DIP.
Over the course of the year, we will explore more of how the SOLID principles can apply to project management. In the meantime, I hope that this first look proves helpful. Feel free to send me your comments and feedback.
Yours in blogging,
1 A common mantra of management is “Don’t make yourself a bottleneck.” However, some bottlenecks are unavoidable and, in those cases, pushing them down the management chain only serves to obscure the constraint without eliminating it. Management needs to own such bottlenecks so that they can prevent the output (e.g. new work requests) from being pushed onto receiving teams before they are ready. That way, the team can focus on delivering the work already in their queue without the cognitive burden of upcoming work.
2 Rather than being lazy, as often assumed, individual developers are frequently too removed from the planning process to have known what to have asked for before receiving new work, never mind empowered to prevent incomplete work assignments from being handed down to them.
3 This might seem to delay work, but this would make negotiations that much more efficient and would free developers to focus on vendor-agnostic work during negotiations.