The Team Members’ Viewpoint
The first perspective we want to explore concerns the individual team members that are being placed on an Agile team. These people are typically in development and quality assurance (QA) roles but could include others in the organization. The team role is described in detail in Chapter 4, “Describing the Different Roles.” Why would team members want to embrace Agile for their projects? Several key principles within Agile are highly desirable to most individual team members.
What Is Different?
To understand the benefits and cultural impacts of Agile, first we should explore what is actually different with the Agile practices and the typical work environments of pre-Agile organizations.
Agile advocates for self-organizing teams, which is a big change for many organizations. Many workplaces hire individuals to work on a specific thing, and even though they are part of an organizational structure, they really act alone. They are responsible for their own work, and their performance is measured based on their individual achievements. That all changes with Agile: Employees come together as a team—not just a set of individuals—and they establish themselves as an entity. They become a group of people driving toward a common goal. One of the first manifestations of this newly created team takes the form of a working agreement, described in Chapter 4. The team gets to establish their own norms and rules of engagement without management oversight; this offers developers and testers a great deal of autonomy that may not have existed before Agile.
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.
Another big organizational culture impact of Agile from a team member’s viewpoint is the ownership of continuous improvement. Within Agile, each team member is responsible for ensuring that problems from a past or current iteration are not carried into the next one; this creates a higher level of engagement from employees, because they have to determine how best to solve any problems or issues existing within the team. This type of continuous improvement applies not just to their code and the products they produce but also to their sense of teamwork. The best teams actively practice reflection, usually through a meeting called a retrospective, which is covered in Chapter 8, “Tracking and Reporting.” This meeting is sometimes referred to as a postmortem or “Lessons Learned,” and it allows for the team to discuss what went well, what did not go well, and what they need to improve. It is important for teams to step away from the day-to-day activities and spend time discussing the team dynamics. Allowing the teams time to reflect on their actions and progress is important within the fast-paced cycle of iterative development (Cohn 2010, p. 213).
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.
When developers move into Agile teams, they may experience a profound shift with the expectations of working software and frequent delivery. In many pre-Agile organizations, developers and testers could work on a project for months and months with very little feedback. This is no longer true in an Agile workplace: Teams are asked to deliver tested code very quickly so that stakeholders can review progress and make adjustments if necessary. This shift in expectations can be significant to some developers and testers—particularly perfectionists—who want everything to be precise and thorough before anyone sees it.
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.
Removing the “Us versus Them” Scenarios
In a pre-Agile world, some development teams handed off their code to a testing group, where the QA activities took place; this handoff frequently created an “us versus them” environment, where the developers could criticize the testers based on the types and quality of tests they were running, and the testers could lament the poorly written code that they were expected to debug. By changing the definition of “done”—a concept described in detail in Chapter 6, “Grooming and Planning”—to include testing, the team has a new appreciation for the testing effort. Developers are now collaborating with their testing teammates to create the highest quality software. If an iteration cannot be completed on time because of testing problems, the entire team is responsible.
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.
The collaboration aspect of Agile allows team members to work together and solve problems quickly. When the entire development team is colocated, which is ideal, then how the seating arrangements are managed can greatly contribute to their effectiveness. The best scenario is for the team to sit together in a type of pod arrangement that easily facilitates spontaneous conversations. Cubicle walls (or even offices) can be torn down so everyone can sit together and see one another (see Figure 2.1). This invites collaboration. The founders of Scrum were very direct on this point: “Use open working environments. Such environments allow people to communicate more easily, make it easier to get together, and facilitate self-organization” (Schwaber and Beedle 2002, p. 39).
Figure 2.1 Agile teams working together
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.
Now that we understand the differences that Agile brings to individual team members—self-organizing teams, the opportunity for continuous improvement, embracing frequent delivery without organizational silos, and having a collaborative physical workspace—next we examine what organizations do to ensure success or avoid paths to failure.
The best self-organizing teams place a high priority on members’ knowing each other and creating an environment that plays to the individuals’ strengths. What best practices do strong teams use?
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.
Incorporating Virtual Resources
Another defining characteristic of high-performing Agile teams is their ability to include virtual and perhaps even offshore (international) resources on their teams. Having team members that are not in your physical location introduces new challenges, and the teams that are able to adapt and incorporate the skills of the virtual team member will enjoy success.
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).
Optimizing the Workspace
Companies and teams that enjoy success in an Agile environment take their workspace considerations seriously and look for options to optimize. Here is a summary of the three key spaces that are required:
- 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.
Figure 2.2 Team workspace
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.
What traps or mistakes do team members make that can have a negative impact on the Agile implementation? In many ways, they are similar to the traits of successful teams, but they somehow miss the essence and turn into a liability instead of an asset. Let’s explore some common mistakes.
Unlike the high-performing teams, unsuccessful teams typically fall into one or more of the following situations.
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.
Inability to Adapt
Agile requires team members to change, and that is uncomfortable for some people. They need to change how they interact, how they do their work, where they sit, and much more. An inability to adapt is a key reason why some team members fail in an Agile transformation. Looking at a specific example, as already mentioned, having a geographically distributed team introduces challenges, and some teams fail to adapt and accommodate. If the team does not make the effort to include the virtual resources in key conversations and meetings, then their ability to contribute is compromised; this can especially be true with international resources. Having sensitivity to time differences when scheduling meetings, creating a work schedule that allows for overlapping hours, and clarifying requirements so no language barriers impede progress are all efforts high-performing teams make. The ones who fail to have the appropriate sensitivity create a work environment that is polarized between those in the building and those outside.
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.
Another area where team members can experience failure is by lacking a sense of commitment. Within Agile, the team commits to the amount of work that they intend to complete during an iteration. If a team does not feel a sense of obligation to that commitment, the level of success that can be achieved is in jeopardy. Some teams reach the end of an iteration in which they have not completed the required work, but they have an attitude of “oh well, we tried”; these are not successful teams. Failing to honor a commitment should be a disappointment. It should serve as an opportunity to assess what went wrong and how it can be corrected in the future. The teams that are lackadaisical about their commitment will never be truly Agile.
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.