None of us has ever been on a project where “they” stuck to the plan. It seems like stakeholders love to change their minds mid-project. These Clueless Customers derail our precious plans.
All that nice scoping, all that nice design… Down the drain after yet another status meeting.
@MathObsessed speaks for a lot of us when he uses the word “desperate”.
So, how do we counter this?
Timeo Danaos
When I became a PM, I learned from an experienced manager who knew the ins and outs of the trade. How to distil requirements, how to track progress. How to make projections. Earned Value, Critical Path, … These are well-honed skills in a traditional Waterfall model. They allow a team to plan and adapt.
None of this is really relevant in the Lean world we’re living in.
Software projects have always been black boxes for Business people. You’d make a few requests, they’d take six months to code and then you could see the result. The rules of the game were clear. Business decides what needed to be built, IT turned it into a real product. This was a relatively safe approach for the IT department. The burden of discovery was on the Business people. If they forgot a spec, that was on them. And boy, did they forget stuff!
Coders are used to hard black and white feedback. It compiles or it doesn’t. There is no deploy that’s “almost Done”. Yet that’s not how most of the world operates. When we say Done, we hear “black”. To most people, there is that grey area of Done-ish. We know that. We do that in our daily lives. Yet we don’t approach our job that way. Coders have a highly analytical mindset and want to specify the details. Most people in Business don’t do that. They describe a high-level feature and are really convinced this is clear.
Now here’s the crux of the problem: as a coder, it’s YOUR job to turn the vague general ideas into specified code. Not theirs.
Sometimes developers believe they are the only ones who have adopted this Agile mindset. They’re not.
The Lean and XP movement showed us that we can’t define an upfront spec because none of us knows what the details are. We need to discover. Developers need to talk with clients and come up with a solution. Business and IT must work together to discover what needs to be done. There was going to be collaboration. An exchange of ideas. Conversation, not a contract.
But alas.
Et dona ferentis
Agile has been a Trojan horse that carried responsibility in its belly. We were too blinded by the colourful Post-It notes. We opened our gates and dragged the horse from Backlog to Development. In the dead of night, we were overpowered by the new dynamic we let into our walls. No longer were we able to point to a missing spec and yell “Change Request!”. The Business Greeks had put the burden of discovery on us!
Meanwhile, in the Greek camp, a new story was being told. They were promised faster time-to-market and iterative discovery. They’d come up with an idea, the nerds would build it and if it’s not what they wanted, they could still change it on the demo. The success of the Agile movement was the liberation of Business!
A new class of problems arose. The Greeks, freed from the shackles of detailed requirements and analysis, found it increasingly difficult to communicate with the Trojans. “We said we wanted a report, but now you’ve built a dashboard instead of a PowerBI integration!”. Frustration runs high on both sides of the wall.
It’s that wall that causes the problem.
We often see a dynamic where the black box is kept alive. Business still makes demands. The feedback loop is not short. Those sprint demos are just for show. Everybody knows there is a big list of tickets that needs to be processed before the project is “done”. Now that Business is free, they’ll constantly come up with new ideas. What was once a fire-and-forget requirement specification document, is now an ongoing mess of vague features. If it takes you three weeks to build a feature, do you really expect them to stop thinking about it until you’re done?
As long as one side can make the demands and the other side will have to build it, the Lean approach can’t work. Business people are not good at specifying what they want. They feel they know what they want, but communicating those details is inefficient. Software developers are often not included in the Why and What conversations. They have little clue about the business side of what they are working on.
We have external agencies building fixed price software using Scrum. That’s impossible.
We have Product Owners who join the conversation once every sprint. That’s counterproductive.
We have Backlogs that keep growing while the deadline remains. That’s destructive.
We have Project Boards without a single developer at the table. That’s madness.
If we want to draft requirements and then have some external party build it, fine! But then we need to use the powerful tools of Waterfall.
If we want quick-to-market Lean discovery, great! But then Hector and Achilles have to work together.
And that means breaking the black box. No more demos. No more Backlog grooming sessions. No more Product Owners. There is no Business, there is no IT. There is one cross-functional team dedicated to building an awesome product. They decide the scope, the timings and the direction of their product. They build it, they run it.
They share the burden of discovery and can’t blame anyone but themselves.
Fixing this dynamic is fundamentally a job for leadership. That doesn’t mean individuals can’t nudge it in the right direction. One of the best developers I’ve ever worked with made it a habit to go for coffee with people from the other side. He would invite them and chat. He would listen to their ideas, hopes and fears for the project and then proactively flag problems and opportunities.
We Trojans have been taught not to trust the Greeks, so let’s take the first step. Walk out of the gate, hand them a coffee and say “About that horse, man…”