Beyond Process and Tools: People Issues in Agile Software
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Agile Manifesto laid out a vision for software development; a vision centered on the humans doing the work. Its classic words have ushered in a generation of programmers, testers, and consultants and created a better world for technologists while offering more value back to the business.
Still, one can argue the Agile movement doesn't live up to the promises of the manifesto. Consider the simple line, "We have come to value ... individuals and interactions over processes and tools."
Consider that the Agile discussion space is filled with Scrum, XP, and Lean (processes) and jUnit, SONAR, and Cucumber (tools). Where is the talk of individuals and interactions? Sure, it comes up at conferences, but to someone who can't afford a conference, "Agile" might sound like a bunch of vendors trying to sell things.
Perhaps that is the case. After all, people in the Agile space are trying to make a living, and it's much easier to do that selling products than ideas.
Still, every now and again, someone takes up the challenge, as is the case with Barry Rogers and Ken Howard, co-authors of Individuals and Interactions: An Agile Guide.
In their book, the two suggest the hidden secret that we may all know: "If your team has dug itself into a hole, the process ain't gonna pick up the shovel."
In order for a team to succeed, you need good people. To attract and retain good people, you'll need a healthy environment—one conducive to getting the work done.
But how do you do that?
It turns out the idea of re-inserting humans into the workplace is the central issue of the book. In this interview, Ken and Barry explain their thinking behind the book.
Matt Heusser: Your book title borrows heavily from the Agile Manifesto. Can I ask what got you excited about the Agile Software Movement?
Barry Rogers: I started my career in the 80's working for a large defense company where we would execute 4-year waterfall-based projects. I got to witness first-hand the major issues with the ideas in practice. This is what sparked my initial passion for software process improvement in general, and iterative development specifically. The biggest challenges I see projects and organizations face are not technology-related at all but rather human dynamics and communication. I feel that the Agile Software Movement has enabled the industry to take a leap forward in understanding what it takes for projects and companies to succeed.
Ken Howard: For the first half of my career, I lived in the waterfall world, working for a large insurance company in San Antonio. In the mid 90's I volunteered for a project using object technology and a process that was similar to what we now call "Extreme Programming." Ever since that time, I've seen practices that worked well given fancy names. Ultimately, though, productivity and efficiency was always a function of people, their skills, and how they interact with one another.
Matt: Of the elements in Agile, you chose to focus on Individuals. What is it about that subject that drew your attention?
Barry: Although the first value in the Agile Manifesto focuses on individuals and interactions, most people tend to concentrate on processes and tools. There are countless blogs, books, white papers and presentations on Scrum, XP, burn-down charts, TDD and so on. One reason the first value does not get as much attention is because so much of our industry focuses on computer science. We are uncomfortable talking about "individuals and interactions" because that focuses more on psychology and human behavior. It is less black and white, less perfect, and out of many people's comfort zones. Arguably the most common and complex issues that project teams typically face is related to human behavior and communication. Due to the importance of the topic combined with its relative lack of materials in the industry, we decided to make it the focus of our book.
Ken: The true focus of the book is not really about individuals, but about what happens when multiple individuals are put together to solve problems collaboratively. When two human beings collaborate, there are a multitude of variables at play. Skills, experience, attitudes, emotions, behavioral tendencies, and many more factors can cause even the simplest task to become complex. At the same time, collaboration consistently results in better quality.
Think about what happens when you put one child in front of a bucket of Legos and tell them to build something.
Now, compare that to the same scene with five kids working together to build something. From a pessimist's point of view, the process takes longer and much time is spent discussing and debating. From an optimist's standpoint, there are many more talents at play, and the results of the interactions lead to a higher quality product that meets more of everyone's needs.
There is inherent conflict on many software development teams—software development is a social activity, yet it is often performed by individuals who tend to avoid social situations. This contradiction can lead to communication challenges and conflict. Understanding different behavioral styles can help the members of a team improve the way they work together. This is at the heart of what our book addresses.
Matt: In the first chapter of your book you make the claim that social factors in the workplace make a tremendous impact on worker productivity. Can you give us some examples of that, perhaps tell us about how those factors are managed in a "classic" organization?
Barry: Teamwork is the most critical success factor in any organization. I remember a time when a company where I worked assembled the best technical team—it was a hand-picked team known as the creme de la creme of technical excellence. The project, however, did not succeed. Everyone wanted to be the chief and drive things. No one was willing to do what might be considered the mundane, boring tasks. There was a true lack of teamwork. It is similar to the 2002 U.S. national basketball team that finished sixth in the World Championships. After going 58-0 over a period of 10 years with NBA players, this team lost three games, and went from being the dream team to a nightmare. There was no dynamic on the court.
It is therefore critical for a software team to comprise a mix of behavioral profiles. A good team needs some members who are drivers and decision makers, others who are analytical and detail-oriented, optimists, pessimists, harmonizers, talkers, and so on. Not only is diversification good, it is necessary. The more diversified, however, the more chance for natural conflicts to occur. It is consequently important for the group to understand and accept one another and modify their communication styles to not induce stress on one another. A framework for doing this, known as DISC, is discussed throughout our book.
Ken: It's interesting to note that through high school and college, there is very little attention in the classroom paid to teamwork and collaboration. As a matter of fact, except for an occasional group assignment, collaboration could be considered an honor code violation in many schools. When group assignments are given, there is rarely any training or coaching about how to perform effectively as a team. When these students enter the workforce, they are rarely prepared to work in a collaborative team environment. These newbies don't usually realize that the veterans were never coached at effective collaboration either. Over time, ineffective teamwork has become the norm in many organizations. As Barry pointed out, it's not just about hiring talented people. It's about capitalizing on the strengths of individuals AND leading those individuals as a cohesive high performing team.
Matt: Now that we've talked about the classic organization, can you contrast that with a more "Agile" Approach?
Barry: In a classic organization, teams are managed. On an agile team, the team's behaviors, their task assignments, and team decisions are all self organized. Agile teams are therefore led and not managed. Teams are empowered and trusted. When a team feels empowered, makes their own commitments on the work they will accomplish over a given time period, is allowed to make mistakes and self correct, and so on, the team will have the greatest efficiency and motivation.
Ken: Also, members of a high performing team complement each other. When there is competition for promotions, bonuses, and other forms of attention, team members could find themselves working against each other. Leading an agile team involves focusing everyone on achieving the goals of the team together. When conventional attitudes are focused on individual performance, leaders of agile teams have to work harder to bind team members together.
Matt: You just talked about empowerment, self-organization, and trust, all things I agree with. Yet in Corporate America (and, I'm told, outside of it), I still see a fair amount of command-and-control "leadership." So let's get specific. Say I'm a middle, or even senior manager, used to command and control. Say I read some of your material, and have become convinced that there is a better way. Now what? How do I transition?
Ken: Command and control happens when fear sets in. When deadlines are approaching, finances are tight, or other pressures are bearing down, there is a tendency for many leaders to grasp the reins and take over. What often happens, though, is that a command and control leader realizes that she can't be involved in every project activity. That frustration can lead to pushing for things that can be controlled—reports, audit trails, status meetings, pie charts, and other artifacts that take the team away from solving the problem.
Barry: This is a great question. Perhaps the most difficult challenge I have faced and honestly have had the most difficulty in trying to overcome, is transitioning a command and control manager. Many command and control managers are high Ds (again, referring to DISC). D's are naturally very confident in their abilities and like to remain "in control." It can sometimes be quite challenging to convince them in the first place that empowerment, consensus building, self organization, trust and other agile behaviors are so extremely important. Even when they become convinced, as you indicate in your question, that there is a better way, it can be difficult for them to change their behaviors. One way to help in the transition, assuming the manager is convinced that there is a better way, is for this manager to be open to the team calling the manager out whenever he tries to take a command and control stance towards a particular action or discussion. One way of doing this, that we mention in the book, is using the "Language of DISC." For example, let's assume the command and control manager starts to dominate a discussion to the point where the team does not have the opportunity to contribute to a decision. A member of the team could tell this manager he is being a bit of a High D. The manager will usually laugh (as opposed to getting offended) and will realize he is reverting to his old behaviors.
Matt: Have you noticed a resistance to self-organizing teams? For example, a few years ago, I worked with a team that was begging me, as a project manager, to make decisions. They pushed, pulled, and prodded me to tell them how to do it, despite any appeals to self-organization. When I finally made decisions, they would say something like "well, that's his plan," or "well, those are his dates" (despite building it from their estimates) then not be bought into the solution. It was very frustrating. Do you find that experience is typical? If it is, how can we overcome it as leaders?
Ken: A controversial practice in Extreme Programming is collective code ownership. The general idea is that everyone owns responsibility for all the code, rather than assigning direct owners to each component. Supporters claim that this practice helps avoid finger pointing, blame, and skirting responsibility. Critics claim that shared accountability leads to no accountability. Both of these positions ignore the seminal point, which is that a high performing team working collaboratively toward a common goal shouldn't require overly prescriptive micro management of every single activity on a project—that a goal focused team will do whatever is necessary for the team to achieve its goals together. The skills required to build and lead a team that functions this way are quite different than we typically find on project teams.
Barry: I would not say that I have noticed a resistance to self organizing teams. It is true that some people are naturally going to be leaders and drivers and others are going to naturally be followers. If an entire team is made up of followers then there may be a tendency to want to have a manager make the decisions for them. This is one of the things a "team wheel" (which is discussed in our book) would show. Moreover, you point out that if a project manager gives in to the traditional ways and makes decisions for the team that the team would not have buy-in or commitment to the decisions. This is why it is so very important to resist this temptation to simply make the decision for the team. It is necessary for the agile project manager to educate the team on the importance of having the team make the decisions. One option to overcome this issue is for the agile project manager to facilitate the team's decisions in the beginning. For example, if coming up with an estimate or plan, the agile project manager can teach the team how to play planning poker and can facilitate this process of estimation and team commitment. But, it is still the team that is making the commitment. The agile project manager is providing the leadership to facilitate the decision making process.
Matt: Say an organization wants to transition to Scrum. What classic pitfalls have you seen people fall into? How can we avoid those mistakes?
Barry: There is not enough time to list all the pitfalls and mistakes I have seen. I will list a few common ones. First and foremost I have seen teams transition to Scrum and not understand that Agile and Scrum are not the same thing. That is, they do not recognize that agile is really a set of values and principles and not a process. They move into the mechanics of Scrum without truly getting the point of what and why they are doing things. That is one of the drivers behind why Ken and I wrote the book, which focuses on only one of these values. We chose this value because it is the one lacking the most attention. Another classic problem I have seen is having the teams skip an important part of Scrum. As one example, I have seen teams skip holding a demonstration of the code after a sprint. One rationale for wanting to skip this step was that the software was too difficult to demo (since it was not UI driven). The value of the demo is one of the most important elements of Scrum, from the perspective of feedback loops as well as visibility into progress and team morale associated with commitment/accomplishment. Another example of a classic problem I have seen is related to acceptance—either not having QA as part of the development team or not defining acceptance criteria for each sprint. Again, the list of pitfalls goes on and on. Scrum is so very simple but so easy to misapply by a team simply reading a book. While books are important, having experienced Scrum team members or coaches are also important.
Ken: By now, most have heard about cargo cults, where practices are mimicked with hopes of getting the same results as those being copied. Scrum offers easy-to-learn practices (stand up meetings, user stories, burn ups, burn downs, etc.) that are also easy to abuse. As a consultant, I have worked with many teams that believe they are using Scrum, when in actuality they are following procedures without fully understanding the motivation. I try to urge new Agilists to start by understanding the Agile Manifesto and its principles. This is harder than I ever expected, because most people are drawn to the mechanics.
Matt: Thank you for your time; this has been great. Say someone likes these ideas and wants to know more—what resources can you recommend?
Barry: Well, at the risk of sounding self-serving, the two resources I can recommend are (1) reading the book, Individuals and Interactions: An Agile Guide (Addison Wesley) and (2) taking training or getting experienced Agile coaches from Improving Enterprises.
Ken: Also, the bibliography in the book points to some great resources that are related to the social and psychological side of software development. Thanks for the opportunity to chat about our book. The book is actually structured to serve as a manual to facilitate an agile team dynamics workshop. Facilitation instructions and handouts are included. I hope when people pick up the book they won't just read it. Instead, I hope they'll use it to enhance the dynamics and performance of their teams.