Software orgs are shaped by their source of truth.
If the source of truth is users, Agile is great for helping the team continuously develop understanding of fixed user needs.
If the source of truth is executives, needs are NOT fixed. Execs constantly change their mind.
If the source of truth is users, Agile is great for helping the team continuously develop understanding of fixed user needs.
If the source of truth is executives, needs are NOT fixed. Execs constantly change their mind.
To an outside observer, these may look the same. The team starts out with some understanding of what needs to be built, and that understanding changes over time.
But understanding of users can only improve. Exec-driven development is always at risk of being flipped upside-down.
But understanding of users can only improve. Exec-driven development is always at risk of being flipped upside-down.
When the goal is to understand users, experimentation is the norm. We don't build features - we make bets, manage the risks, and learn.
Exec-driven development is extremely hostile to experiments. The HiPPO told you what to build, just build that. Don't ask questions.
Exec-driven development is extremely hostile to experiments. The HiPPO told you what to build, just build that. Don't ask questions.
So we can't simply say, "let's switch to Agile" without effecting change *outside* the dev team.
Agility under HiPPO rule doesn't look anything like agility for user-facing development. Teams are only thinking about making it easiest to keep up with exec flip-flopping.
Agility under HiPPO rule doesn't look anything like agility for user-facing development. Teams are only thinking about making it easiest to keep up with exec flip-flopping.
An "agile" team in a feature factory must first build expensive, highly flexible architecture, so that pivoting along with exec whims is easy. Story point estimates are punitive to slow down the rate of requests for changes.
But execs don't want architecture, they want UI!
But execs don't want architecture, they want UI!
So one or two Java developers draw the short straw, spin up a web app, and start making some kind of website.
This is when the org expects designers to contribute. We don't need testing or research since the exec decided that already. Here is the BRD, draw us some mockups.
This is when the org expects designers to contribute. We don't need testing or research since the exec decided that already. Here is the BRD, draw us some mockups.
You will never be able to justify the value of design in an environment where design is the rendering of executive fiat.
The designer can't change their role simply by making better outputs, or challenging the PM. After all, it's not the PM's decision either - it's the exec's. Rocking that boat is a huge risk.
The only way forward is to take on that risk.
The only way forward is to take on that risk.
Just because your outputs change from wireframes to processes doesn't mean that the "make a bet and reduce the risk" model stops applying.
Your users: management. Their goals: make money. Unknown: their mental model around converting features into value into money.
Your users: management. Their goals: make money. Unknown: their mental model around converting features into value into money.
There are different schools of thought on how to do that. But it all boils down to: how can you change management's mental model that experiments are risks, failure, and wasted work? How do you convince them that "just do what I tell you" is actually more risky?
