A capture and refinement of a Twitter rant from December 2022
I was provoked into this rant by a reference Jim Highsmith’s essay 18 Years Of Agile Manifesto For Software Development #1: History:
This type of situation goes on every day — marketing, or management, or external customers, internal customers, and, yes, even developers — don’t want to make hard trade-off decisions, so they impose irrational demands through the imposition of corporate power structures. This isn’t merely a software development problem, it runs throughout Dilbertesque organizations.
There you have it: Agile is an adaptation to software dev teams getting jerked around by executives and managers: “if y’all cannot give us clear direction then we have to work in a way that makes this less painful”.
Agile accepts this failure by managers and executive as a given, and then in actual Agile practice, it turns out that the need re-surfaces. We see this in Scrum’s dream of a Product Owner role.
Fred Brooks put his finger on this problem in The Mythical Man-Month half a century ago, and what he said then remains true: we need to think very clearly about what we want and need a system to do before we try to build it, which is difficult but possible.
The “hard trade-off decisions” are not fundamentally about feature prioritization, allocation of time and resources, technical architectures, et cetera — looking away from those choices flows from a deeper well, an inability to think clearly about intent and desired results. If the organization could think and talk very clearly at the strategic level, about system intent, then it would be clear how to make those tactical decisions. The decisions would still be hard, but they would be possible, and development organziations would face them rather than avoid them.
In an organization with a clear strategic vision of system intent (what should this thing be?) and tactical planning of development (how shall we create & deliver it?) then the radical flexibility of Agile — implied in the name “Agile”! — would not be necessary.
Since this manifests through Executive And Mangers Jerking The Developers Around — an abdication of responsibility — it is tempting to say simply that executives and managers need different skills / tools / methods. But the root problem is the lack of clarity and I don’t think that executives & managers can get to the needed clarity alone.
This is part of why I am a partisan for the importance of product management and UX design as roles, org functions, and disciplines which enable this needed clarity. I am a UX designer and I believe that UXD Properly Conceived is the carbon in the steel which makes it possible for a software dev org to forge and wield the Blade Of Clarity
Almost everyone in software development assumes that the only way to really see what you are making is to make it. It is as though the construction industry believed that the discipline of architecture were impossible. (This metaphor here has significant limitations; I recognize how dangerous it is to imagine that software construction can directly parallel building a house. But with that caveat, it is still useful.)
If we imagine a world which builds houses like we build software, one would go to a building contractor who would ask for a feature list for your house. How many doors and windows? How many kitchen cabinets? How many stairs? Then they get to work. When the house is half-framed, the future occupant finally gets a look, and has to ask why the bathtub is in the kitchen. The contractor replies, “Well it stands to reason with the plumbing.”
After that angry exchange, the contractor walks away shaking their head thinking there you have it again, “customers” always change their minds about what they want, they cannot name it until it is mostly built, there’s nothing to be done.
The resulting houses all look like they were drawn by Dr. Seuss.
An architect from our universe would be taken for crazy. “You want to draw up ‘plans’ first, before we start construction? You are dangerously naïve! Who can afford that extra expense? Don’t you know how customers’ ideas constantly change?”
There are profound reasons why the industry does not try to visualize a working software system in advance in the way an architect tries to visualize a house in advance. People do not just assume it is impossible; it does not even occur to them as a thing to reject as impossible.
But visualizing a software system in advance is not impossible. It is merely pretty darned hard. That craft is UX Design Properly Conceived.
With UXD as a touchstone, execs & managers can actually engage with strategic and tactical decisions. Do we want to make this? How will we make this? Hey development team, make this!
Now there are at least two big reasons why executives and managers resist the introduction of UXD to enable Clarity.
First, they simply cannot imagine UXD as a thing. Propose it and for good reasons they reject it as impossible.
Second, once UXD is on the table, that Clarity implies scary change to the whole development process. It requires running things differently — different org structure, different processes. And it puts puts executives and managers on the hook for the strategic and tactical decisions which it reveals.
If the organization attempts a clarity-driven development process, then any failure for any reason will be attributed to that attempt. As Archibald Putt will tell you, executive or management failure in the tech industry is rewarded ... if one fails for the right reasons. But seeking clarity is not among those. So why take on risk?
So, bringing all this back to development process on the coding side.
In my long experience as a UX design consultant, programmers are understandably dismissive, skeptical, and resistant about my craft. They cannot conceive of the clear system vision with deep structural implications which UXD produces when done right. They have never seen that. They just expect UXD to just add a thin “good user interface”, to “make it pretty”.
Programmers are rightly skeptical. Any efforts to find the kind of clarity I am talking about which they have seen have probably failed catastrophically. They may have seen UXD efforts that were undertaken without time or expertise or other necessary resources. They have almost certainly seen executives and managers run away from clarity. They expect to continue to get jerked around.
Programmers feel a deep sense of responsibility to deliver a good system. They resist UXD because they initially see it as an incursion on that territory. And sometimes they care about UXD and have taken to programming as the necessary place to stand in order to work on it.
But when I deliver Clarity-enabling UXD, programmers are thrilled by it. At last the crisp vision they have needed in order to plan and work effectively! This has complicated political implications in the org. Developers then say to marketing, management, executives, “Hey, you want to tell me what to do? You ought to give it to me in this form”. And since those folks don’t know how to produce that kind of clarity? Fireworks.
Executives find it threatening when UXD explicitly locates Product Vision in something they do not do. They imagine that Product Vision is their job! As people temperamentally drawn to holding authority, executives cannot conceive of someone with UXDs’ capacity for Vision not making a bid to usurp executive authority. But we don’t! We just want to crack the problem!
(That’s not a knock against executives. I have a temperamental resistance to systems of authority but I recognize that exectuives’ inclination to seek it is not simply a bad thing. Someone needs to own strategic decisions, and there are obvious reasons why it helps if that person wants to, if they make good ones.)
Understand that in this dream, UXDs propose product vision and are custodians of it, but UXDs’ authority & responsibility (“ownership”) is not the product as a whole but more narrowly advocating for users. It should be product managers who own the product vision ... answerable to business goals set by executives and informed by user needs identified by UXDs, customer drives identified by marketing, and technical opportunities & constraints identified by engineering.
UXDs often demand to Own The User Experience because that sounds natural and is the only way many of us can imagine delivering good UX. (And this draws a lot of UXDs to shift implicitly or explicitly toward product management, in hopes of wielding the necessary power.) But that steps outside of what UXDs’ role should be, into what product management should do.
Product management should hold the imperator of product ownership to decide conflicts between the various constituents in the greater development organization — UXD, marketing, programmers, et cetera. But in practice when done well PM is not the exercise of authority to play umpire most of the time.
Product managerment done well is 98% collaboration, with the PM communicating, translating, and facilitating the exchange of thinking & planning among these various constituencies. “Hey, Ms. Programmer: Marketing says customers ask for X. UXD says that is best addressed with Y. I don’t want us to grind on this, so if that turns out to be tricky, I will put you in a room with the UXD to hash out a solution almost as good which you can deliver more quickly.”
Looking in the other direction, up toward executives, PMs need to link product visions to business goals. “We have talked about growth, but there are different product directions. X should get us the most users, Y should get us the most sales revenue, Z should get us the most profit. Which do we want?”
