Once upon a time there was a team of dedicated, intelligent, passionate developers and QA engineers who worked on XYZ platform at ABC company. Every day they came to work with the intention of building the best dang platform that ABC had ever seen. However, this team was NOT the original builders. They were the folks who had taken the place of the original builders and had done their best to improve the platform that already existed. They made it their business to make sure they knew EVERYTHING about XYZ Platform.

One day the team noticed a few broken and poorly constructed things that were – let’s say – fire hazards. They decided that everyone needed to know about these fire hazards so they told anyone who would listen. They told their managers. They told the C-Suite. They told the maintenance teams. The listeners agreed wholeheartedly that something should be done about the fire hazards. In fact, everyone agreed that something should be done.

So the team, being dedicated and passionate, laid out a plan to get rid of the fire hazards, but it required that they stop building XYZ Platform and go into maintenance mode for a short while to properly eliminate these fire hazards. And that’s when all the listeners put up their hands and protested. “No,” they said. “If we stop building XYZ Platform, our competitors will build something better!” But the team assured them that if they didn’t fix the problems, then the whole platform would crash and burn. To this, the listeners replied, “We’ll worry about these fire hazards later. Nothing is on fire right now, so just keep building XYZ.”

And the team did what they were told. They continued to build, and they left the fire hazards alone. To their dismay, however, the more they built, the bigger the fire hazards became. So they once again warned the listeners about the fire hazards, and once again the listeners told them to keep building XYZ. One day the fire hazards really did catch on fire, and indeed the whole platform crashed a burned. Everyone ran to and fro trying to extinguish the flames, and after much effort, the fires were put out.

Once the dust settled and the smoke cleared, the listeners called a big meeting. They wanted to know why the team had allowed the system to get to such a state. And the team replied, “We tried to warn you about the fire hazards, but we were directed to keep building XYZ.”

The listeners rubbed their chins and considered this. “But we had no idea it had gotten this bad.”

To which the team replied, “We’ve been telling you for ages!”

“Well,” replied the listeners. “We must take further precautions to make sure this doesn’t happen again. When you see fire hazards from now on, make sure you fix them.”

“But that will mean taking time away from building XYZ,” the team replied.

“We’ll worry about that when it happens. It’s fixed now. Back to building!”

What’s the moral of this story? Listen to the dang Dev Teams and you won’t have a fire! I don’t know how to stress enough that middle and upper management needs to not only listen to their people, but they need to HEED what they say!

Why am I sharing this on a Scrum blog, you ask? Because transparency is important, that’s why. But, as evidenced in the example, transparency doesn’t guarantee that your “listeners” will actually listen. We’ve all been there, right? We’ve all witnessed a platform crash and burn when it could have been prevented. No matter what, as agile professionals it is our job to keep up the good fight and continue to shine that flashlight on fire hazards!