This chapter is from the book
This chapter is from the book
This chapter is from the book
A Manager’s Viewpoint
Agile for team members is full of new opportunities and a chance to contribute in ways that may not have been available in the old environment. The same is true for managers, but they may feel as though their role is shrinking or becoming less important. In many instances, Agile alters their span of control, which can create unease and a lack of clarity regarding expectations and performance measurements.
What Is Different?
The differences for managers center on how their role has evolved. It can be quite positive, but it is definitely different, and some managers are unable or unwilling to let go of their past responsibilities to embrace the new ways that they can help the team.
Questions, Not Solutions
Perhaps the biggest impact to most managers is that they are no longer responsible for defining the solutions—this now belongs to the team. Many managers have prided themselves on being owners of an application or architecture, so adjusting to the idea of team members making decisions about those applications can be difficult.
The manager is in the pivotal position of being able to facilitate how much a team learns and how quickly they embrace their self-organization. The most effective managers will make the shift from telling to asking. When a team member approaches management and asks, “How can we increase the response times with the database?” the manager in a pre-Agile world would provide an answer or at least a suggestion. In an Agile environment, the best managers will ask questions: “Why do you think the response time is bad?” “What is the customer expecting?” “What data is being retrieved?” “Is that the right amount of data?” “Are any business rules being applied to the query?” And so on. This allows the team to think through the situation to arrive at their own solutions. It might take a bit longer, but by enabling the team to derive the solution, the manager is truly being Agile and positioning the team for success and continuous improvements.
Applying this concept to a university environment often brings memories of favorite professors or key learning moments. When you struggle with a concept and visit the professor, the Agile-minded ones will ask you numerous questions until you arrive at the answer on your own; the less engaged professor might just give you the answer. By asking questions and allowing you to reach the answer on your own, your professor is demonstrating confidence in your intelligence and problem-solving capabilities. Taking the time to work with you to arrive at the answer—rather than just telling you—is an investment of the professor’s time and will enable you to feel empowered and capable of reaching the right conclusion in the future. Professors are often used to this teaching role because they purposely chose their profession; managers may not be inherently good teachers, and displaying this type of faith and investment in employees might feel foreign and unnecessary. The good Agile managers are the ones who adopt a professor-like mind-set focused on continuous improvement and learning.
Clearing Roadblocks
The manager’s role shifts to one of clearing roadblocks for the team to enable their success. This is a different role for a manager, and although it is vitally important to the organization, it might not feel very rewarding, at least not at first. If the team has an issue with training or tools or collaboration with other departments, the manager can be a great help navigating the political environment to solve the problem. The difference is that the manager used to be deeply involved in the problem solving, but now he or she is clearing roadblocks to allow the team-led solution to come to fruition. Some managers view this negatively, as though part of their job—or even their worth to the company—has been diminished. This should not be the case: Effective managers in an Agile environment are a tremendous asset. Since they no longer have to focus on every day-to-day detail associated with the project, they can devote time to higher-level activities such as technology architecture and true employee development—areas that are often neglected in the pre-Agile environments. Managers can assist with mapping the business process flow and then make recommendations to improve performance and drive toward simplicity. They also can spend time creating career development plans for employees based on their skills and desires, and they can devote meaningful time and attention to recruiting and making sure each hire adds to the cohesiveness of the team and further position them for success. It is a new role of clearing roadblocks and focusing on higher-level activities, but when done well, it is meaningful and delivers significant value to the organization.
Trusting the Team
Some managers are predisposed not to trust those beneath them in the organization. Douglas McGregor captured this management style in his X-Y theory of management. The Theory X manager believes that employees are inherently lazy and therefore need authoritative supervision and a comprehensive set of controls to manage them (McGregor 1960). Thus, Theory X managers will have a very hard time with an Agile implementation, because they fundamentally believe that self-organizing teams cannot exist. These people tend to act as “command and control,” meaning that they dictate the work to be done and even how it will be done, and they tightly control the environment for that work. Clearly, this type of management attitude directly conflicts with the very core of Agile values. This belief system still exists in the modern workplace and must be addressed to ensure Agile success. If an organization has Theory X types of managers, they may need to move to new positions to not interfere with the Agile implementation. Departments that are very operational in nature often thrive with this type of management; self-organizing development teams do not.
Even if the manager is not a Theory X manager, he or she may still need to make adjustments in trusting the team. For some period of time (perhaps years), the manager has evaluated staff aptitudes based on a non-Agile measure. Often, managers have a hard time envisioning their employees stepping into and embracing new responsibilities and problem-solving techniques. The most effective Agile managers are those who know that the best way to truly embrace Agile is by letting go of their control and allowing the team to learn, and perhaps fail.
A nonworkplace example of this comes with parenting. When children are small, their physical, emotional, and intellectual capabilities are limited, but as they grow, these things obviously evolve. Imagine if parents kept acting as though their children were three-year-olds, even as they grew: The parents would still cut their food into tiny bites, would never dream of allowing them to ride a bike, and would certainly not allow them to bathe themselves. As the children grew, they would become increasingly frustrated with the limited expectations and would either lash out or disengage. The same is true in our workspace: Employees are constantly learning and evolving, and they can and should take on increasing levels of responsibility for their work. Agile supports this evolution, but some managers cannot move beyond their initial assessment of an employee’s abilities. If a manager is struggling with an Agile transformation, this is an area to apply some self-reflection: Is the manager actually holding the employees back? If so, a little bit of trust can go a long way.
Successes
Can managers survive the changes in their roles in an Agile environment? Of course, and the successful ones display a few common traits. The best managers embrace the Agile values and principles by endorsing teamwork and trust.
Teamwork
The ideal manager is going to do everything in his or her power to ensure the success of the team. This includes staffing the team for success and ensuring that all roles are covered, assigning the team members full-time, and making sure they have the necessary tools and environment to deliver on their commitments.
One example that Cayman Design encountered needed management assistance to ensure team success. When creating the Scrum teams, there were not enough testing (QA) resources for every team to have a dedicated tester, so the decision was made for two teams to share testing resources. The first iteration went well, and both teams received the testing support that they needed. But in a subsequent iteration, one team ran into a problem, and they relied heavily on the tester to help them diagnose the issue. The other team, therefore, received no QA support during their iteration, and they were unable to deliver working software. Solving this problem was outside of the control of the individual teams because it required a reallocation of resources. The successful Agile manager took ownership of this problem and worked through budget and head count issues with senior management to allocate a dedicated QA resource to each team. The manager’s proactive ownership of the situation positioned the teams for success.
A strong Agile manager also allows and encourages team members to work on their own differences. Members of a certain team at Cayman Design visited the manager, complaining of communication issues on the team: They did not know what their team members were working on, they were surprised when things were not completed, and they did not feel informed on roadblocks that were impeding their teammates’ progress. Rather than addressing this in the typical management fashion, by calling the team together to discuss it or by speaking to everyone individually, the successful Agile manager pushed the issue back to the team to solve. Agile provides a structure to facilitate team success, and teams need to use those mechanisms on their own.
Trust
An effective Agile manager fundamentally trusts the team to do good work; this is evident in allowing team members to truly own issues and resolve them on their own. Trust is a bit like allowing your children to explore their own ideas, even if you are skeptical that they will work. Here is an example:
Your Scrum master comes to you and says that the team would like to work from home four days a week and be in the office only the one day that they host their Scrum meetings. You, as their manager, have serious reservations about this idea: It contradicts one of the Agile principles about the importance of face-to-face communication, and it will likely reduce the team’s ability to collaborate. A non-Agile manager might immediately respond with, “That is out of the question. We would lose far too much collaboration if no one was in the office. Plus, what would our business partners think if they came into our workspace and no one was here?”
A successful Agile manager would likely respond with a question: “That is an interesting proposal. What is the business problem that you are trying to solve with the work from home idea?” Through this response, the Scrum master can share additional facts and drivers that led the team to think that this was a good idea. The manager can then react to the additional information with more accurate guidance and may even—through asking questions—guide the team to a different alternative. The successful Agile manager assumes the team is trustworthy and that their ideas are valid.
Failures/Risks
The managers that fail to make the transition to an Agile organization typically display common characteristics.
Command and Control
There are managers who simply cannot give up their command and control demeanor; it is how they manage, and it is inherent in their style. It can be similar to asking a Marine drill sergeant to let recruits decide how far they are going to run and how clean their barracks need to be—it is just unnatural to them. When working with a company recently, we encountered this type of personality in the Project Management office. When asked what he liked about his current (non-Agile) role, this person said, “I like being able to manage people, control the environment, and manipulate the teams to get the deliverable that I want.” A person with this type of philosophy will have a very hard time adjusting to an Agile environment.
How can managers overcome their command and control tendencies? First, we must accept that some are willing and able to change and some are not, and that the organization must respond accordingly (see the discussion of executive roles in the next section). Many previously controlling personalities have successfully shifted to Agile by understanding its benefits and the important role that they can play in optimizing the team. Some of these techniques have already been mentioned; here are some additional details.
- Ask questions instead of offering solutions. If a manager can shift into a questioning mode, he or she can help the team to self-organize and establish trust. This could be as simple as asking “What do you think we should do next?”
- Direct others to the team. If someone from another organization has a question or needs information, instead of immediately answering, as command and control personalities tend to do, a manager can encourage that person to ask the team directly. This will position the team as the authoritative source of information.
- Do not talk. When a command and control manager attends a meeting, typically the first impulse is to actively contribute to the meeting to advance the discussion. As a start to break down this tendency, a manager can try not to speak during an entire meeting. The silence might be profound, particularly if the team is conditioned to receiving direction. The manager can embrace the silence and let the team members fill it with their ideas and suggestions.
It is difficult to change a way of thinking that likely served managers well throughout their careers, and that is why Agile asks people to stretch outside of their comfort zones. The results can speak for themselves when empowered and self-organizing teams deliver amazing business results to the organization.
Territorial
Some managers truly believe that they “own” a process or an application and that no one should make decisions on that process or application without their involvement and consent. Agile is very collaborative and customer-focused, and if a solution is presented that crosses systems or changes workflows to enhance the experience for the customer, that effort needs to be allowed to proceed without deference to artificial organizational boundaries.
As an example, we had a situation where a manager believed that he owned a gateway service, and to maximize the speed of the gateway application, no business rules could reside in the gateway; all business rule logic needed to be performed by other systems. This is actually a wise architectural guideline to drive performance, but if a team has a need where putting business rules into the gateway might make the most sense, then that discussion needs to be able to proceed without territorialism. The decision may not change, but the ability to have a productive and value-focused conversation is critical to the organization.
Ownership is a difficult challenge within Agile because we want people to feel accountable for their work. Some could view territorialism as ownership, which implies accountability. The difference that Agile presents is that territorialism for the sake of ownership is bad; accountability for the sake of delivering business value to the organization is good. Whenever managers find themselves feeling uncomfortable about what is being suggested for “their” application, the best course of action is to step away from the technical details of the situation and dive into the business problem that they are trying to solve. The better we understand the end users’ pain point, the better we can devise solutions, without undue deference to a particular system or workflow. Looking through the eyes of the customer can tear down territorial boundaries quickly.
Team Oversight
Another failure that comes up from time to time involves managers who simply cannot let go of the team: They continue to distribute work to team members, thwarting their ability to self-organize. Managers who attend and actively participate in the daily stand-up are not allowing the team to self-organize, and those who dictate roles on the team are not helping the Agile environment.
How can managers overcome their need to get involved in day-to-day decisions and team oversight? One of the fastest cures to this problem is to stop attending the meetings. This happened at Cayman Design, where a manager chose to stop attending the meetings and would get the necessary information from the transparency Agile afforded. At first, the manager’s absence slowed the team down because they believed they needed her to make key decisions. Over time, the team realized that the manager was not going to attend the meetings, so they needed to solve their own problems and come up with their own recommendations. It can be a difficult transition, but there are simple ways to become more Agile. It is important to note that an Agile transformation does not happen overnight: Managers do not move in one motion from being controlling and territorial to being collaborative and en-abling, nor do teams accept the accountability of becoming self-organizing and decisive in short order. Organizations must be thoughtful and deliberate with the Agile adoption, always striving to embrace the Agile principles and continuously improve.