Home > Articles > Software Development & Management > Agile

Beyond Process and Tools: People Issues in Agile Software

The Agile Manifesto says that we value "individuals and interactions" over "processes and tools." Yet TDD, Scrum, Extreme Programming, jUnit, and many other elements in the "Agile" space are processes and tools! Ken Howard and Barry Rogers draw a line in the sand with their new book Individuals and Interactions: An Agile Guide; Matthew Heusser interviewed the authors to find out more.
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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020