The CEO’s New Clothes

A Business fable about transparency (or a lack thereof) and Agile Facading. Based on ‘The Emperors New Clothes’ by Hans Christian Andersen.

Clients and investors are voicing their dissatisfaction with E-Suite X, which is losing market share rapidly. The CEO of E-Suite X, Ray, loses a lot of sleep over it. During the shareholder committee, Ray promises to increase the delivery speed of features and the platform's quality.

The throughput of features is slowing down, and the Development Department keeps missing deadlines. The QA Team is blocking valuable releases. The Backlog is called ‘the Buglog’.

Luckily for Ray, he has a true hero in his service: The Chief Architect Oscar, who knows exactly how to turn the ship around. Oscar is meeting with two Agile consultants promising them more, better, faster.

The consultants propose a phased Agile Transformation, including a transition to Microservices.

Ray agrees with Oscar to compile a best-of-the-best “Agile” team called: The Cheetah Team. This team will consist of the most experienced Developers and one QA engineer with a tech lead as Scrum Master. They are the ones who built the original platform, so they know best how to rework it.

“Furthermore,” Oscar argues, “if we build this, I can put my developers to the test and eliminate those who are unfit and reduce the operational expenses.”

In one blow, Oscar believes he can single out the best men and weed out the lazy developers whilst out-innovating the competition with Microservices.

Ray appoints his best and most trusted to oversee the project: Michelle, the head of PMO. She inherits the title of the Chief Product Owner to oversee this Agile project personally.

Michelle runs through the Cheetah’s plans. “Heaven help me,” she thought as her eyes flew wide open, “I don’t understand it at all. I can’t see how this will change anything about our client's concerns at all.”

Michelle learns they will build a facade of new APIs on top of the old ones. Michelle understands little about Agility and even less about Microservices.

“All this stuff is way beyond me. I’ll trust them to get the work done. I’m giving them the environment they need. It would never do to let on that I can’t understand any of it. But we need to break away from the old. I trust Oscar knows what he’s doing.” She figured.

“It’s a sound plan; this amazing technology is our future!” she reported to Ray.

She worked all day and night on a splendid Gantt chart titled:

Agile Transformation Roadmap: Project Cheetah.

Michelle instructs all the developers who are not on the Cheetah Team to continue to build the new promised features as scheduled in the old codebase.

A few weeks later, Michelle met the Agile Consultants. They instruct her on Scaled Agile for Enterprise and convinced her to allocate more budget for this major transition. After all, E-Suite X belongs to a big e-commerce conglomerate. Sure, they only have one Cheetah Team, but that will soon scale when it proves its success. Michelle wants to be ready for that. Big Change was happening fast!

After a few weeks of planning, designing, and researching, Michelle brings everyone together to plan the next quarter in a PI Planning event. “Exhilarating!”

At the end of each bi-weekly iteration, they hold an Iteration Review where Oscar gives a PowerPoint presentation showing the progress on the Roadmap to all the stakeholders who want to join. Sadly, none of the stakeholders joined. But that was okay; everything was so technical, and there was nothing of value to be demonstrated.

The highlight of the Review is that the Cheetah Team’s “Velocity” is skyrocketing. “None of the old code is slowing them down now. It is all under control!” Oscar concluded proudly.

During the UAT and Hardening Sprints, Michelle works day and night with the Marketing Department on a major marketing campaign. She spares no expense. After all, this is the future of E-suite X, and Oscar’s Cheetah Team had now scrummed 8 months to turn the ship around.

With the campaign launch, the clients are thrilled to learn about the new update and can’t wait for it to be released. All their concerns will be gone! The Platform’s Performance will increase, the Time-to-market of new features will be minimized, and maintenance costs will surely go down. Right?

Mr. Ray is the guest of honor at the final Go/NoGo Review (which had already been postponed three times). Oscar and Michelle needed the help of some designers to make this Final Launch presentation as sexy as possible, given that the project was all very technical.

But as Ray tries to understand the slides, the models and diagrams, and the RGB dashboard, he thinks: “But what’s this? I can’t see or understand how anything has changed. This is terrible! I can’t let on that I have no clue what they are showing me. And yet… all the lights are green; look how excited they are. Our clients will surely love this.”

“Oh! It’s exhilarating,” Ray said. “It has my highest approval. Why wait for next week? It'll be an amazing success! Let’s launch it today!”

Ray overhears some disturbed developers questioning the imminent release on his way out.

“These developers know they will become redundant. That’s a good sign”. Ray shrugs it off.

The Product launched. It was received with a deafening silence. The clients waivered. After a few weeks, though, complaints started raining in.

“This release isn’t doing anything at all!”

Ray was dumbfounded. As time went on, the system destabilized further. There were more incidents than before. But at least Michelle is happy to see the team embracing the Fail Fast mantra. And Oscar is already deeply entrenched in the PI planning of the next promising ‘‘Capability’’: Machine Learning.

“This show has got to go on.” Ray thinks, asking for a status report contemplating another round of lay-offs.

Turning the ship around

Don’t underestimate the wasteful nature of managers to base projections on what they’d like to happen, only to lose sight of what is happening.

“Only what has already happened may be used for forward-looking decision making” — The Scrum Guide.

So what needed to happen to turn the ship around?

E-Suite X did not live these four Agile principles:

• “Working software is the primary measure of progress”
• “Agile processes promote sustainable development.”
• “Continuous attention to technical excellence and good design enhances agility.”
• “Simplicity — the art of maximizing the amount of work not done — is essential.”

Decisions and expectations must be based on the actual state of the product. E-Suite X’s mantra of “even more, better, faster” resulted in the product being used less, performing worse, and developing slower.

When the observations about the product aren’t complete or correct by those deciding over it, or if there is a different understanding about its perceived state, decisions will be flawed, progress will not be predictable, risks are not controlled, conflict occurs, and value goes down the drain.

Ray needed to inspect and understand the product and its clients truly. So no… not Gantt charts, roadmaps, RGB dashboards, backlogs, architecture models, PowerPoint presentations, and whatnot. They are facades that set (false) expectations with emperors and ministers.

The map is not the terrain.

A result of poor transparency is ‘Technical Debt’. Technical Debt accumulates when poor choices are made. Technical Debt is scary stuff. The trouble with Technical Debt is that, as it grows, it obscures. It’s the nemesis of Transparency. It makes the product rigid, fragile, and immobile. It breeds fear.

Radical transparency would turn the ship around.

Oscar, the hero architect, could have opted for the following ways.

• Visualize Technical Debt. As in Horror movies. Seeing the monster makes it less scary.
• Remove what is not adding value. Refactor what is. Clean the code! Reduce complexities.
• Pair-up and swarm. Share the knowledge. Reduce the ‘bus factor’. Remove the Shade.
• Commit to a more stringent Definition of Done.
• Re-organize development sustainably. Refactoring: not as a luxury, but as a habit. Built quality and tests into the product to ensure that what works stays working.
• Align team priorities around problem-solving, not feature-building.
• Inspect actual outcomes and experiences rather than emphasizing output.

With all of the above: Be truthful about why you haven’t done this all along. But doing all that would reveal the true state of the mess Oscar’s team had made in the first place. Oscar did not want to slow down to speed up. So, Oscar opted for a greenfield project together with those who made the mess in the first place whilst raising an Agile facade to obscure true product performance.

What would you do to turn the ship around? Let us know in the comments!