Chapter 2. Organizational Culture Considerations with Agile

Moving from Waterfall to Agile requires an organizational culture transformation in most companies. This chapter delves into the impacts as well as examples of both successful and unsuccessful ways to handle the culture change. First we understand what organizational culture is and how it influences an organization. Then we look through the eyes of three positions in a company to see how Agile changes the way common situations and challenges are addressed.

How important is the organizational culture in a company’s ability to adopt Agile? Critical. In fact, in the VersionOne annual survey of “The State of Agile Development,” they found that culture change is the primary barrier to further Agile adoption at companies (VersionOne 2013, p. 9).

Why is it so hard to change a culture? An organization’s culture was not built overnight; it is the accumulation of years of interactions and experiences that have formed into a belief system of how work progresses and how decisions are made. To shift the culture, one must create new experiences and reward those who dare to embrace the new and unfamiliar. The organization must be prepared to examine its old practices with a critical eye and try a new way of doing things. When the new experiences are difficult or uncomfortable, it is common to revert to old habits. Driving true culture change, which Agile requires, needs commitment and nurturing from all levels of the organization.

Another desirable outcome of self-organizing teams is that the team members get to actually select the tasks they want to work on during the iteration. Before Agile, many organizations distributed work from the manager to the developer, without the developer getting much say at all on the assigned tasks. The pre-Agile assumption was that managers understood the work and how best to deliver it, so they would assign the necessary tasks to individual developers who would execute on their task. There is a high cost of missed opportunities with this method that Agile addresses: The developers might have a better solution for the business problem, and Agile gives them the opportunity to voice their suggestions and alternatives. Also, developers may have skills in a variety of areas, and to be assigned tasks by someone else does not allow them to choose to work on different items. The added variety to their workload is often appealing. Another benefit to self-organizing teams is the ability to organically cross-train. This happens when one developer wants to learn something new and acts on that desire. When selecting the tasks to work on, developers can request those tasks under the guidance of a more experienced developer, or they may ask to shadow an experienced developer so they can learn. The opportunity to choose their own tasks is a dramatic improvement over the pre-Agile environment.

This concept can be demonstrated in university settings as well. If you are put on a team to deliver a class project with no predetermined task assignments, the team can decide how best to distribute the work: One student might be the best researcher, one might be the fastest typist, and another might be best at the oral presentation. By allowing the team to determine how work is distributed, you can play to the strengths of each individual and facilitate new learning, which is the point of the next section.

The reason why this is a compelling difference from other methodologies is because individuals are no longer waiting to have their problems solved for them—they are actively engaged in the solutions. In the past, a developer or tester might have relied on the manager or someone else in the organization to resolve issues, improve processes, and relay information. Within Agile, the teams are empowered and encouraged to seek out answers and improvements on their own.

To apply this to a university setting, consider teams that are assigned for the entire semester. Within a team, there may be highly organized, highly driven participants as well as others who are not willing or able to put forth as much time and effort. If one of the team members goes to the professor seeking a solution and the professor rearranges the team assignments, that is certainly one way to solve the problem, but it is not the Agile way. Within Agile, the team members would be asked to resolve their differences themselves first. Of course, if the issue is a true performance problem, then the professor may need to intervene, but the first course of resolution within Agile is always within the team.

For Alistair Cockburn and the Crystal methodology, this principle is the number one priority: In his 2010 blog, titled “Seven Properties of Highly Successful Projects in Crystal Clear,” he states:

The single most important property of any project, large or small, agile or not, is that of delivering running, tested code to real users every few months. The advantages are so numerous that it is astonishing that any team doesn’t do it:

• The sponsors get critical feedback on the rate of progress of the team.

• Users get a chance to discover whether their original request was for what they actually need and to get their discoveries fed back into development.

• Developers keep their focus, breaking deadlocks of indecision.

• The team gets to debug their development and deployment processes, and gets a morale boost through accomplishments.

All of these advantages come from one single property, Frequent Delivery. (Cockburn 2010)

Obtaining feedback is critical to an organization’s ability to course-correct if something is not quite right or does not meet the needs of the customer. Within Waterfall, because working software was not delivered at regular intervals but rather as a “big bang” after months or years of development, gathering this type of interim feedback was difficult. Becoming comfortable with frequent delivery is important for developers and testers because they must truly desire the feedback and be willing to act on it.

Frequent delivery is not always part of the university experience, because many classes have a team project that is due at the end of the semester; however, projects that allow for feedback throughout the semester are easier to manage. For example, if a critical paper is due after month 1, the team can incorporate the feedback from that paper into future deliverables. If the written presentation is due after month 2, then the team can learn if their proposal resonates and practical ways to improve it. By the time they make their oral presentation at the end of the semester, they are more confident in their work because they have had the opportunity to solicit and incorporate feedback throughout the semester.

Testing is one of the most visible manifestations of the Agile concept of teamwork, but many other groups are affected as well. Agile is about working together toward a common goal, and it creates a structure or framework to facilitate collaboration and break down organizational silos. Another area where this is demonstrated is between the product owner and the team. In the past, a lack of clear requirements was often the reason that software was late or inadequate. Now, the product owner, with responsibility for bringing clarity and priority to the requirements, is part of the delivery team. If a developer is unsure of how to proceed, it is his or her responsibility to seek clarity from the product owner, and it is the product owner’s responsibility to provide an educated response.

Central to this culture shift is the idea that the team succeeds or fails together. Within Agile, it is impossible for a tester to succeed but the developer to fail, or for the product owner to succeed but the Scrum master to fail. Either the team, the whole team, delivered working software at the end of the iteration, or they did not. If the iteration did not produce working software, it is up to the team to diagnose the problems and work to correct them, previously described as continuous improvement.

In a university setting, this is often demonstrated in group projects where the entire group will receive a single grade. The professor is not likely to entertain conversations about who did what and why the project is difficult—he or she is interested in results, and part of delivering the necessary results is figuring out ways to maximize the talents and motivation of everyone on the team.

By allowing the developers and testers to have easy access to one another, questions or issues that may have taken several e-mails or meetings to resolve can be addressed face-to-face for immediate resolution. The speed of clarification and problem solving that comes from being collaborative provides teams with an excellent opportunity to improve their deliverables.

The idea of colocation works in a university setting as well. Many colleges offer remote degree plans today, which is a great alternative for students who live in rural areas or who want to participate in a program that is not offered locally. The challenge with these sorts of arrangements is on the team assignments, where classmates do not have the opportunity to get together regularly to discuss the project progress and roadblocks. These challenges can be overcome, however, using some of the methods described later in the chapter.

First, members get to know one another. Each person has his or her own personality, family situation, areas of expertise, and temperament; by knowing teammates as human beings first and workmates second, team members see themselves as a cohesive unit, poised for success (Adkins 2010, loc. 4841). The most successful team members are the ones who maximize their environment around both personal and professional preferences. For example, if one team member needs to take children to school before work and cannot arrive before 8:30 A.M., then having the mandatory daily stand-up meeting (described in Chapter 8) at 8:15 A.M. would put that team member at a disadvantage. From a professional perspective, if one team member is unskilled at writing documentation, it would be unwise to have that person assume all of the documentation responsibilities. An effective team will address both the personal and professional nuances of their group to maximize everyone’s effectiveness and create a desirable work environment; the working agreement described earlier is a great starting place for that clarity. A project and team that are structured around the individuals’ personal goals and unique talents will generate the desired commitment (Cohn 2010, p. 216).

The second indicator of success on high-performing teams is their ability to adjust and course-correct. When things do not go as planned, the successful teams find a way to address the conflict in a productive manner.

The most effective teams are the ones that tackle concerns early on, in a respectful and resolution-oriented way. The least effective teams get angry but do not share their frustrations constructively. Ideally, teams operate in a manner that is based on honesty and proactively addresses situations the instant they are problematic. If a team member says or does something that seems disrespectful or too negative, it is best to address that right away. Members of strong teams are honest with one another and if something is not working, the whole team works together for a better alternative.

When team members are not colocated, the lack of face-to-face communication is the first hurdle that must be overcome, and this can be accomplished using video tools. Ideally, this means that every meeting is conducted with a video connection so the virtual team members are included in the discussion. Honestly, the structured meetings are the easy part; where virtual team members might miss out is in the organic conversations that happen in the hallway or in the lunchroom. Human beings are always thinking and learning. Sometimes walking away from your desk or leaving the meeting room or bumping into a particular person on the way to the vending machine can spark an idea or help solve a problem. When those moments of inspiration occur, it is vitally important to contact the virtual team members and bring them in on the innovation. Otherwise, the team could advance but the virtual team members would be inadvertently left behind.

How can you create an environment where virtual team members feel as if they are part of the team? The first best practice is to have those people sit with the team at the start of the project for a significant period of time; ideally, this is at least two iterations. It is important for the team to feel as if they “know” the virtual employees, and vice versa; once the initial relationship is established, the virtual team members do not feel so far away. Inside jokes and team banter can happen naturally, with everyone feeling equally involved.

Travel budgets are tight at many companies these days, but having virtual employees come to town for key meetings, such as project kick-offs or quarterly reviews, can help the team bond and can increase the trust between the team members. In fact, to ensure success with distributed teams, companies will likely need to increase—not decrease—their travel budgets (Demarco et al. 2008).

• Individual workstations should be arranged to facilitate collaboration. Some teams prefer to have distance or walls separating them from other teams to keep noise and distractions to a minimum; other companies place teams with or near the business units that they support so the sense of a common goal is shared in the space.

• An Agile (Scrum) room is a discussion area with white boards for times when something needs to be debated or brainstorming of ideas is required. Ideally, this space is not shared with other teams or the rest of the company, because it should be immediately available when something comes up and the team wants to be able to leave their documentation and drawings on white boards for future reference. One innovative company turned old management offices into Scrum rooms so teams had their own dedicated space.

• Access to company conference rooms for the larger meetings, such as Sprint demos and backlog grooming sessions, is also necessary (see Figure 2.2). These often have to be scheduled because they are shared spaces, and each conference room needs access to a projector or Smart Board to display the working software at the end of the sprint.

In some companies, moving the physical space will make a powerful statement about the seriousness of the Agile implementation. If you say you are Agile but you stay in cubicles, how Agile are you? By rearranging the office space, you visibly demonstrate your commitment to change. It is worth noting that the nature of Agile means that the physical requirements will change over time. As teams grow and shrink and traffic patterns change and interdependencies between teams morph, it will be necessary to rearrange the office space again.

First, they fail to self-organize. There are truly people in the workforce today who are more comfortable being told what to do and simply execute on that order. When we ask those people to become more engaged and be part of the solution process, they are reluctant, or incapable of doing so. Some people are conditioned to this behavior, but over time in a supportive and learning culture, they can transform to being key contributors. For others, it is simply in their DNA to take direction from others and not rise to the level of accountability that Agile requires; these people will not be successful on Agile teams, so the organization needs to either find them a different role or allow them to move on.

Another example of the inability to self-organize is where teams demonstrate hostility, bullying, or demeaning behavior toward one or more of their team members. This aggressive behavior cannot be tolerated, and if the team cannot resolve it on their own, then management needs to get involved. Agile workplaces are safe environments where people are encouraged to learn and grow and take chances and deliver great results; but if there is an unhealthy team dynamic, that can be difficult—maybe impossible—to achieve.

Many people have served on unhealthy teams, and the same dynamics that exist in sports or academia can exist in the workplace. Teammates on unhealthy teams

• are unwilling to help or support one another

• refuse to broaden their role by saying things such as “it is not my job to test” or “he owns that piece of code, so it is his problem”

• withhold helpful information or training because they want to be seen as the expert

These unhealthy team dynamics can sabotage an Agile implementation, and it will take a strong Scrum master, coach, or possibly even manager to break down these bad habits.

Another example involves making the transition from cubicles to an open concept. When introducing the collaborative work arrangement, worries may range from a colleague who wears too much perfume, to a germophobe who fears being sneezed on, to concerns about background noise and the ability to concentrate. All are legitimate issues that need to be addressed, but none are worth abandoning the benefits of moving to the open, collaborative space. The teams or individuals that refuse to be open-minded about the seating arrangement and constantly complain are sabotaging their Agile implementation. Like all things, if a legitimate concern is affecting safety, then management needs to address it immediately. Otherwise, being adaptable in the seating arrangements demonstrates a commitment to the greater good. An inability or unwillingness to consider new options and adapt to the evolving needs of the organization can lead to failure.

The lack of commitment can reveal itself in a number of ways—failing to complete the work is the most obvious and detrimental—but there are other manifestations as well. Not adhering to the meeting cadence within Agile by grooming, planning, tracking, and demonstrating, all described in Chapter 8, can lead to suboptimized work. It might be easy to become lazy about the daily stand-up meetings and write them off as unnecessary, but that is not in the best interest of the work, the team, or the Agile transformation. Being disciplined about participation and active engagement drives success.

Failing to address issues with team dynamics and allowing bad habits or relationships to continue without proactively confronting them are also examples of lacking commitment. An unwillingness to learn and grow can create a stagnant environment where an individual team member or the entire team stops moving forward and simply becomes complacent. Innovation does not come from places described as complacent or lazy or lacking commitment. Innovation is coupled with true agility, and this comes from dedication, discipline, and a desire for continuous improvements.

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.

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.

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.

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.

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.

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.

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.

Agile advocates for a different approach. Let’s just try to replace one minor application in the mainframe. We will keep the scope very small, we will deliver frequently, and we will inspect our results often, allowing us to course-correct if necessary. With the learning gained from the first effort, we will embark on the next effort, and so on. The organization gains much more predictability in the incremental deliverables, and the wise Agile executives are courageous enough to present this new philosophy and information flow to their investors.

Executives came to be in their positions because they are decisive, action-oriented and results-driven, so their first impulse is to mandate an immediate response. However, respecting the existing priorities, providing the team with an opportunity to clarify the details and examine the best solution, and allowing the team to finish the work currently in flight will lead to much more consistent and predictable results.

Let’s examine these instances individually to identify the best reaction by a truly Agile executive.

• The command and control manager is uncomfortable. This often takes the form of bringing up the multitude of ways that Agile could fail—the teams cannot self-organize, our clients are too demanding, our software is too complex, we are impeded by government regulations, our business partners are too inexperienced, and so on. Each of these hurdles, and many others, has been overcome by organizations with Agile. The Agile executive needs to resist the urge to slow down the implementation and carefully think through every possible scenario. Instead, he or she should embrace the “inspect and adapt” mantra of Agile by moving rapidly and carefully forward and learn from every decision. Constantly inspect the implementation and make course corrections as necessary. Do not let fear of what could happen delay the positive outcomes of what will happen.

• Developers self-select out of the organization. There are certainly people in every organization that we believe we cannot live without; their domain expertise or years of experience make them assets to the organization. Agile supports these experts and provides them with opportunities to contribute in ways they may never have before. The employees that see and desire the collaboration and accountability associated with Agile are critical to the longevity of the organization. Those that are threatened by Agile and want to withhold their expertise or refuse to try new alternatives will ultimately hold the organization back. Certainly, their departure is disruptive, but it can and should be managed by an Agile executive. Creating an environment of continuous learning involves identifying and rewarding those who want to join the transformation.

• New expenses. Agile does not break a budget, nor does it come for free. If you are truly committed to changing an organization’s culture, then spending money on training and tools and possibly even new hires is an investment—not an expense. Asking an organization to convert to Agile without any additional budget is not demonstrating the necessary commitment to the change. Agile executives need to “put their money where their mouth is” and authorize the appropriate expenditures to ensure success.

An Agile executive will stay the course when confronted with issues and concerns. Making an Agile transformation cannot be optional to the organization: Either the executives are committed or they are not. There can be no wavering, because the minute an executive indicates that it is acceptable to continue with the old ways of doing business, many people will fall back into their old, comfortable patterns that will not deliver the desired results.

We need to avoid burnout amongst the teams. When organizations adopt Agile, there is typically a good deal of enthusiasm and a desire to work hard and deliver compelling results. Then as the Agile implementation continues, some teams can suffer from long hours, which can create an unsustainable environment. Bob Hartman wrote about this in a July 2009 blog:

If the pace of the team is not sustainable several undesirable effects are likely to occur:

• Defects will increase. Tired teams let more defects through.

• Work output will decrease. Tired teams do less work in more time!

• Morale will drastically decrease. This may lead to employee turnover at a most unfortunate time in the project.

• The blame game will become common. (Not our fault you didn’t say X. I said X. Did not. Did so . . .)

• The team starts to abandon good practices for those that “seem” faster. Sorry, but test-driven development (TDD) is actually faster than just writing the code and throwing it over the wall to QA! (Hartman 2009)

The responsibility for sustainability often lies with executives because they can control the resources and, to some extent, the expectations of the organization. If executives make commitments to customers that are unreasonable or fail to provide teams with the tools and training that they need, then the executives are contributing to an unsustainable environment where good people can become frustrated, which either affects the quality of their work or may even encourage them to leave the organization. Most employees want to work hard and accomplish significant goals, but they require an environment that facilitates their success.

An Agile executive has an opportunity to influence this, just as a university professor does. By forcing team members to slow down enough to think things through—and giving them the time and latitude to do so—both professors and executives encourage thoughtfulness and deliberate decision making. Rushing and setting unrealistic expectations compromise technical excellence.

An Agile executive that understands and values simplicity can propel the organization forward. Simplicity can be utilized in an Agile implementation in several ways. The first is with the implementation itself. Being flexible in an Agile implementation means embracing the unknown and trying new things. If an organization tries to overplan an Agile transformation and think of every possible roadblock that could be encountered, they will strive for perfection and get stuck in a lengthy (and Waterfall-like) planning stage.

The Agile organization that understands simplicity will try different small steps to learn what will work best for the organization. Continuous learning by inspecting and adapting allows for a simple approach to Agile.

The second way that an Agile executive can embrace simplicity is with the corporate or product objectives. When goals are too ambitious or expectations are too varied, it leads to an organization that is fragmented and chasing too many disparate deliverables.

Steve Jobs once said, “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are” (Griggs 2012).

An Agile executive knows that simplicity and precise focus enable the teams to deliver great work.

Are there instances where the sprint must be interrupted? Absolutely. If one of your production servers goes down and your developers need to restore the system, then that is clearly a priority over new development. If you are under attack from hackers (such as a DDoS attack), then the developers may need to work on an immediate patch. Those situations notwithstanding, there are many more instances where the “crises” can and should wait while the team works on their current sprint commitment.

A strong Agile executive should have the power and conviction to keep fellow executives in line so the sacredness of the sprint can remain intact. Executives who have not fully embraced Agile or do not appreciate the impacts of their decisions on the organization can create chaos and confusion by not honoring the teams’ commitments.

• Actual time taken to complete a task vs. estimated time

• Velocity of Team A vs. Team B

• Number of stories with acceptance criteria vs. those without

Each of these metrics may sound reasonable, but they could drive the wrong behavior. With the first example, one might wonder: What does the organization value, working software? or precise estimates? Of course, Agile would like the estimates to be relevant and close to the level of effort required, but we want our developers to spend their time writing great software, not doing extensive research to ensure accuracy in their estimates. Defining the wrong metric could force developers and testers to spend time in unproductive efforts.

In the second example, velocity, or the amount of work that a team can accomplish during a sprint (described in detail in Chapter 6), is a tool used to predict the amount of work that a team can commit to, not as a measure of productivity. First, two teams could use different measures of effort—a medium-sized task or an eight-point story (also described in Chapter 6) might mean very different things to different teams. Second, a dip in velocity might have nothing to do with productivity: If Team B has three developers at a training class, then the amount of work they can accomplish is reduced, but not because the team is less productive.

Finally, with the third example, the premise behind Agile requirements gathering is that we are learning and negotiating on the best way to deliver maximum business value. If we are measuring the performance of how stories are written, we may unknowingly reduce the conversation about that story.

Agile executives need to be very careful about the metrics they choose to ensure that incentives are provided for the correct behaviors. Measuring success in an Agile environment is different from traditional metrics, as we now place a heavy emphasis on customer satisfaction, frequent delivery of working software, and continuous learning.

• Self-organizing teams have working agreements, select the work that they will own, cross-train and support one another, and create a dynamic that plays to the strengths of each individual.

• Continuous improvement on teams means that members can solve their own problems without outside intervention and they are working to improve not only the product but also team effectiveness.

• Frequent delivery of working software is central to Agile success. This creates a meaningful feedback loop for the team to incorporate.

• Agile breaks down organizational silos and creates teams where developers, testers, and requirements owners all depend on each other for shared success.

• In Agile, teams should be colocated to facilitate collaboration. This can be challenging for teams with virtual or international participants, so optimizing the physical workspace and collaboration tools is a priority.

• High-performing teams have excellent team dynamics where individuals know and respect each other and can resolve differences productively.

• Effective teams are adaptable to the changes that come with continuous improvement in Agile, and they demonstrate a commitment to completing the deliverables even when circumstances are not ideal.

• Managers in an Agile transformation have to make adjustments as well, and some managers will struggle to embrace their new roles and enable the teams.

• One area where managers can assist an Agile implementation is to refrain from offering solutions to the teams. Instead, they should ask thoughtful questions to help the teams reach their own conclusions.

• Another way that managers can accelerate an Agile deployment is to clear roadblocks for the team. This is particularly helpful when it comes to resource and staffing discussions, because the manager may be able to address impacts to the budget more effectively than the team can.

• When it comes to trusting the team, some managers follow Douglas McGregor’s Theory X style of management, where they believe employees are lazy and need oversight to monitor their performance and behavior. This style of management will struggle to adopt Agile.

• Executives in organizations adopting Agile will find that their roles have changed too. Since executives often hold the budget resources and the decision-making power, their involvement in the transformation is critical.

• Executives can support Agile by understanding and embracing evolving requirements. Those that want comprehensive plans and business cases will fail to reap the benefits of iterative development, rapid feedback loops, and continuous learning.

• Executives are in a unique position with Agile to respect the commitments and priorities. They hear complaints and feedback from a wide variety of stakeholders and may be inclined to immediately act on that feedback without understanding the disruption and negative impacts to the team.

• Executives that truly want Agile to be a part of the ongoing organizational culture need to dedicate budget dollars to its implementation; it might be with regard to tools, training, staffing, consulting, or a number of other things. A transformation of this magnitude requires investment.

Kristin and Sondra: How do you know when a company is culturally ready to adopt Agile?

Scott: My initial thought was “you just know,” but clearly that’s not the answer you’re looking for. People, at all levels of IT and at least in key positions within the business, need to recognize that they need to deliver IT solutions more effectively. They need to recognize that the old, documentation-heavy ways simply aren’t working, and in many cases they need to stop lying to themselves about this. They need to recognize that greater collaboration, greater flexibility, and the need to embrace some kinds of uncertainty are the order of the day.

Kristin and Sondra: What are the most significant differences between Agile and Waterfall, from a cultural perspective?

Scott: Agile focuses on collaborative, iterative, high-value activities that focus on producing solutions that meet the needs of stakeholders. The challenge is that Agile teams need to be skilled and disciplined enough to pull this off, while the stakeholders need to be actively involved with the Agile teams. Waterfall teams often take documentation-heavy approaches in the name of risk reduction. The challenge is that Waterfall strategies prove to be higher risk in practice, but because they involve so many perceived “checks and balances,” the people involved are unable to recognize the very clear risks they are taking on.

Kristin and Sondra: How important are things like the seating arrangements for a successful Agile adoption?

Scott: Communication and collaboration are key success factors on Agile projects, so how people are physically organized is important. I’ve explored this issue in several surveys [see http://Ambysoft.com/surveys/], and it’s clear that the closer people are to one another, including to stakeholders, the higher the success rates of project teams. Even something as simple as putting people in cubes can lower the success rate.

Kristin and Sondra: How do successful teams integrate virtual (and perhaps global) team members?

Scott: The best strategy is to not take on these sorts of risks at all. If you choose to, do so with your eyes wide open. Try to have distributed subteams, not dispersed individuals. Fly key people around between sites. Fly key people together at critical times in the project, particularly at the beginning when you’re making fundamental strategy decisions. Adopt communication technologies, in particular video conferencing. And finally, adopt distributed development tools, such as IBM Jazz or Microsoft TFS.

Ambler, Scott, and Lines, Mark. (2012). Disciplined Agile delivery: A practitioner’s guide to Agile software delivery in the enterprise. Boston: IBM Press.

Atkinson, Philip. (2012). Creating culture change. http://www.philipatkinson.com/Philip-Atkinson-CreatingCultureChange.pdf.

Beck, Kent. (2000). Extreme Programming explained. Boston: Addison-Wesley.

Cockburn, Alistair. (2006). Agile software development: A cooperative game (2nd ed.). Boston: Addison-Wesley.

Cockburn, Alistair. (2010). Seven properties of highly successful projects in Crystal Clear. http://alistair.cockburn.us/7+Properties+of+Highly+Successful+Projects+from+Crystal+Clear.

Cohn, Mike. (2010). Succeeding with Agile: Software development using Scrum. Boston: Addison-Wesley.

Demarco, Tom, et al. (2008). Adrenaline junkies and template zombies. New York: Dorset House.

Derby, E., Larsen, D., and Schwaber, K. (2006). Agile retrospectives: Making good teams great. Frisco, TX: Pragmatic Bookshelf.

Goodreads. (2013). https://www.goodreads.com/author/quotes/13560.Leonardo_da_Vinci.

Gower, Bob. (2013). Agile business: A leader’s guide to harnessing complexity. Boulder, CO: Rally Software Development.

Griggs, Brandon. (2012). Ten great quotes from Steve Jobs. http://www.cnn.com/2012/10/04/tech/innovation/steve-jobs-quotes.

Hartman, Bob. (2009). New to Agile? Work at a sustainable pace. Blog entry, July 24. http://www.agileforall.com/2009/07/new-to-agile-work-at-a-sustainable-pace.

Layton, Mark C. (2012). Agile project management for dummies. Indianapolis, IN: Wiley.

McGregor, Douglas. (1960). The human side of enterprise. New York: McGraw Hill.

Schwaber, Ken, and Beedle, Mike. (2002). Agile software development with Scrum. Upper Saddle River, NJ: Prentice Hall.

Schwaber, Ken, and Sutherland, Jeff. (2012). Software in 30 days: How Agile managers beat the odds, delight their customers, and leave competitors in the dust. Hoboken, NJ: Wiley.

Sutherland, Jeff. (2011). Ten year Agile retrospective: How we can improve in the next ten years. http://msdn.microsoft.com/en-us/library/hh350860(v=vs.100).aspx.

VersionOne. (2013). 8th annual state of Agile survey. http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf.

2. Who should the team look to first to solve their problems?

3. Why would frequent delivery of working software make a developer uncomfortable?

4. What do successful teams do to incorporate virtual team members?

5. How does altering the seating arrangements change team dynamics in Agile?

7. What is an example of a type of roadblock that an Agile manager could clear?

8. What are the characteristics of a Theory X manager, according to McGregor?

9. How can an Agile manager demonstrate trust in a team?

10. What are some managerial traits that are incompatible with Agile?

12. How can executives help with sustainability on Agile teams?

13. Why might an executive want to change the priorities for an Agile team immediately?

14. Who typically serves as the executive sponsor of an Agile implementation?

15. What are examples of metrics that drive the wrong behavior, and why?

17. Identify several roles outside of the IT organization that are affected by an Agile transformation.

18. Why is it so important to enable teams to honor their commitments?

19. Why would someone choose to leave the organization (resign) rather than move to an Agile environment?

20. What should be done when an aspect of the Agile transformation is not working or delivering the desired results?