We like to criticize managers who have an excessive need for control. We refer to them as micromanagers, control freaks, and the antithesis of organizational agility. Rarely do we refer to them as the person in the mirror.

I have observed far too many of these “hands on” managers over the years and have identified a couple of common traits. First, they tend to be very conscientious. They are driven to perform their duties to their utmost ability. They are willing to put in as many hours as it takes to accomplish a task. As a result they are quickly promoted to the ranks of management. A second, far less endearing trait is that they speak with disdain about others. They accuse one person of being lazy and another of being stupid. They question the judgment of one peer and the honesty of another. After a brief conversation with a micromanager, it becomes clear that no one is up to his standards. This prideful attitude is the reason they are unable to delegate. After all, how can one delegate to someone who is incompetent?

So, returning to that person in the mirror, how often do we fall into this pattern of thinking ourselves? A little humility may be in order. That humility may result from getting to know a team member well enough to understand his areas of expertise. It may come from an embarrassing, public mistake of our own. A sure cure would be to assume management responsibility of a function for which we have no experience.

From time to time it is good to get in touch with your inner control freak. And then knock some sense into him.

One of the 12 principles of agile is, “Simplicity – the art of maximizing the amount of work not done – is essential.” Those of us with Type-A personalities may feel uneasy with this principle because it seems to promote a slacker mentality.

As it turns out, simplicity requires a good deal of discipline. To achieve it, the product owner must scrupulously review the backlog to ensure that functionality with lower business value is de-prioritized. Simplicity may require the project manager resist a PMO-driven requirement for excessive documentation or develop a business case for implementing automated test tools. Simplicity will require that the developer clean up sloppy code and the tester avoid redundant test cases.

To become truly productive, we borderline workaholics need to put down the to-do list and get in touch with our inner slacker.

Even in a well run organization, it may be necessary to cancel a project in response to new information. A new competitor may have already introduced a game-changing product. Market pricing may have changed, making a new product economically infeasible. It may be necessary to reduce capital outlays to keep the business afloat. Cancelling a project under these conditions may be a great example of agile decision making. But it could also be a sign of inadequate planning.

Whenever a decision is made to cancel a project, it is worth taking some time to reflect on the project and ask a few questions:

What were the flaws in the original planning premises?

Do these flaws indicate shortcomings with access to market intelligence?

Was the project clearly tied to a strategic objective?

If the project was tied to a strategic objective, should that objective be evaluated?

How was the decision made to launch the project?

Would there have been a different outcome with a different project team?

Cancelling a project is a very painful decision and it is human nature to want to move on quickly. An agile leader must ensure that the organization first learns from the pain, and then moves on.

Early in my management career, I reported to a politically savvy executive who insisted on “no surprises” from his direct reports. He wanted to make sure that he would always be able to respond to questions about any of our projects and thus avoid the appearance of being out of touch. Since then, I have met managers who either explicitly or implicitly expected the same. Some would become angry with their direct reports any time they were presented with questions for which they were unprepared.

Beyond exhibiting insecurity, these managers are increasing costs for their employers. Their direct reports waste time on frequent and sometimes detailed emails on day-to-day problems and issues. Meeting time is devoted to bringing the boss up to speed and PowerPoint presentations are developed to ensure the manager is properly briefed.

Managers who want no surprises are focused on control rather than empowerment. They demonstrate that do not trust their direct reports to make decisions themselves. As a result, they inflict a level of organizational paralysis.

In a fast moving organization, managers look for ways to remove obstacles for their teams rather than control their actions. For such an organization, the cost of no surprises is the loss of agility.

Reflect on someone that you trust completely. You are confident that person will look out for your best interest or will meet his commitments. Now think about your co-workers. Do most of them meet that description? Conversely, how would they assess your trustworthiness? High performance, agile organizations require a high level of trust, and those of us in a leadership position must cultivate a culture of trust. Here are three tips for doing so.

Bury the hatchet
It is not possible to hold a grudge and simultaneously trust the person who is the object of the grudge. As leaders, we need to discipline ourselves to let go of animosity and instead focus on the work to be accomplished. Further, we need to coach everyone on our teams to do the same.

Turn off the email flame-thrower
Flaming emails are a sure sign of a low-trust environment. If you feel the need to correct or admonish someone, do it in person rather than sending an email with a broad “cc” list. If you are copied on such an exchange by someone on your team, have a word (not an email) with the sender and coach him on proper email etiquette.

Make commitments and then meet them
Your customers, co-workers, and team members rely on information from you in order to do their jobs. When asked to provide some information or a deliverable, don’t just say, “I’ll get it to you.” Instead, say, “I’ll get send it to you at Tuesday afternoon at 2 pm,” then do it. Make it a habit to set expectations and then meet them. Before long, others will learn to trust you to get the job done.

After an argument with a defiant teenager, an exasperated father was heard to say, “He’s not completely worthless – he can always serve as a bad example.” Just for the record, I was not the defiant teenager in question. While this father was able to find some good in a bad example, there is much greater power in a good example, particularly in an agile culture which runs on interpersonal relations rather than formal authority. A project manager who arrives at meetings on time and looks after the best interests of his team members will have greater success in meeting project objectives. A developer who consistently meets commitments and deals well with customers will have her choice of new project assignments. A product owner who publicly praises the accomplishments of the team will receive better response to requested changes.

All these people can wield considerable power in their organizations. Why? The reason is simple. Knowledge workers have a great deal of latitude in their daily work and they will use this latitude to support those who treat them respectfully and get even with tyrants, micro-managers, and political animals.

An agile organization needs managers who can receive and quickly respond to feedback from customers, peers, and team members. Some managers will be unable to adapt to an agile culture while others will be quite successful. It has been my experience that successful agile managers will have the following traits.

Organization

In a fast-paced, adaptive environment a manager receives a barrage of information from multiple sources – email, texts, meetings, wikis, etc. The manager must have an innate sense of organization to ensure that information does not “fall between the cracks.” A successful manager will build and continually refine a system for managing information. The type of system used is less important than the manager’s desire to organize.

Discipline

In a dynamic environment, it is easy to give in to the temptation to follow each “bright shiny object” that comes into view. A successful manager must have the ability to distinguish between what is important and what is interesting and the discipline to focus only on the important. The manager must also have the discipline to honor commitments and thereby instill the same discipline in the team.

Emotional Maturity

An agile culture promotes face-to-face communication, and that communication can sometimes be unpleasant. The new feature does not meet the customer’s expectations. Priorities have changed – again. A developer fails to meet a commitment. A successful manager must have the maturity to control his own emotions and deal with issues calmly, objectively, and professionally.

You may be thinking that these are traits that ANY manager should have – agile or not. And you would be right. However, it is possible for a manager to be successful in a traditional organization without all three traits. In an agile organization, all are required.

Agility builds on competence, ingenuity, and team work rather than workflows, tools and techniques. An organization with an Agile culture will focus on providing business value, foster collaboration between business and IT, and encourage personal accountability. In so doing, it will also highlight deficiencies of certain team members and leaders. Team members who lack initiative, interpersonal skills, or proficiency will become highly visible. Project managers with a command and control mindset will find it difficult to allow team members to figure out problems on their own.

To cultivate a high performance Agile culture, it will be necessary to provide special attention to those team members and project managers who are having difficulty adapting. That attention may mean additional coaching, but if the coaching is not successful, it will be necessary to remove people from teams. Not everyone can adapt, and it is unfair to the individual or the team to continue in a role for which they are not suited.

The Program Management Office (PMO) function in most organizations was designed with two goals in mind: gain control over projects and improve project management processes. As organizations scale up Agile, these two goals begin to conflict because the controls can inhibit the improved (Agile) project management process. The controls were designed to support the waterfall method and need to be adapted to facilitate Agile. Following are three common PMO controls that will require adaptation.

PMO status reporting should be modified to focus on deliverables rather than activities

Phase gate reviews should be limited to the project definition or charter

Analysis and design documentations should be eliminated because they are normally not developed in Agile

These changes sound simple but they can be a difficult sales job unless the PMO manager is already an Agile proponent.