Transparency is Key to Agility
By now, the word “agile” has become a swear word in many companies. Employees roll their eyes when they hear it and in many ways, rightfully so. Many managers use the term without understanding it or what it requires. Instead of gaining the concepts benefits, we’ve become frustrated with our managers as they seem to hide behind the word whenever they need us to change.
Where Leaders Fail
Most leaders who harp on being agile seem to only understand the idea that we need to be able to change (pivot) quickly to stay competitive in nearly every industry. What leaders have failed to understand is that agile is as much, if not more of a managerial concept than a technical concept. When a leader is demanding more agility from their team, my first question is to ask what that manager has done to facilitate agility.
Simply demanding that an employee rapidly accept a changing environment is not enough. Informing employees that their work may drastically change at any moment is a recipe for job insecurity, not agility. Making an employee aware of the possibility of change is in fact the first step, but only the first step. You must change how you lead.
Transparency: Tell Them You’re Failing

The primary difference between a good leader in an agile environment and a bad lead who thinks they are agile is transparency. Your employees should understand the possibility of a possible change and the causes for that change as early as you do. You should never surprise your employees with change, even if you are giving them the appropriate time to instigate the change. To phrase this another way, your team should be aware of the causes of a change before the decision to change has been made.
I am working on two projects that each underwent a major change this week. The first one had an issue “pop up.” The owner of the issue had been aware of the threat for weeks but did not share the concern until it was confirmed to be a problem. This left us scrambling, re-planning, and adjusting the project’s scope. In other words, it left us with the exact problems that agile should prevent.
My other project completely crashed and burned but everyone on the team had been aware of this possibility for months. It was the train wreck that we couldn’t look away from. The leader had told all of us of an issue they were struggling with long before it was even fully understood, let alone acted upon. We hoped it would succeed but, because we were aware of the threats, were prepared for it’s failure. In true agile form, once the failure occurred, we were able to pivot seamlessly and move on.
Success
Both projects mentioned above provided for enough time and resources to change direction. The difference, however, is that the first project is inching along with confusion, frustration, and key employees leaving. The second project simply changed scope and moved on. No one is happy about the failure, but our conversations are far from negative. We were able to accept the change and quickly pivot because it was not a surprise.
This concept is not specific to project management or agile teams. Any manager will at times need their employees to rapidly adapt from one job to another. Retail managers need their employees to change their sales pitch or coupon advertising overnight. The key to this is having them understand as early as humanly possible that there is a possible change, why their is a possible change happening, and how it will be managed if it does. If you’re telling your employees about a change once it’s been decided upon, you’ve set them up for failure.
Turn the Tables
Here’s a thought process for you. If you have an employee who becomes aware of a growing issue, at what point do you want them to bring it to your attention? Do you want them to mention it once it’s a ball of fire running through your office? Or do you want them to mention it as soon as they learn about it so you can discuss it and plan for it? If you chose the latter, what do you think they would choose? Wouldn’t they want you to tell them of issues as early as possible as well?

Originally published at https://hubpages.com.