“We think the biggest takeaway is an emphasis on Agile as a culture, not a process,” say Ken Howard and Barry Rogers...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
about their new book, Individuals and Interactions – An Agile Guide. In this second part of a two-part interview with Howard and Rogers, we look more at Agile values and leadership. Howard and Rogers continue to emphasize the importance of communication, collaboration and teamwork in Agile environments.
SSQ: In the book we read that Agile is a set of values rather than a process. However, aren’t the underlying values really trust and respect rather than adherence to prescriptive frameworks? There are some very high-performing military teams who lead by command-and-control, yet maintain a high degree of mutual respect with their subordinates. There are also Scrum teams in which Scrum Masters demand adherence to Scrum process rules with embarrassing penalties for those who don’t follow them. Which team is more Agile?
Ken Howard/Barry Rogers: Interesting question. I would say that neither team is Agile. It would be like asking which shape is rounder, a door or concrete? While a military team might have mutual respect between superiors and subordinates, I do not believe that makes them an Agile team. Respect is only one characteristic of an Agile team. And command-and-control style leadership is only one way to potentially and questionably earn this respect. Similarly, a dogmatic Agile Scrum Master with embarrassing penalties is not fostering a team or trusting environment. So, I would argue that neither is truly Agile. Having said that, I have seen teams adopt a subset of the components of Agile and/or Scrum. They are still much better off than they have been prior to adopting these components. However, they have not truly reached all the benefits of a high performing team and may not be close to what one would deem an Agile team.
A common misapplication of self-organizing teams is that team members should only do what they want to do. In a perfect world, this may yield optimal results. In reality, though, not all team members are motivated and productive. Therefore, strong leadership is still a necessary component of Agile projects. Self-organizing and self-managing are important, but strong leadership is necessary to facilitate optimization.
In the book we discuss Maslow’s Hierarchy of Needs and how oversight of an individual’s essential needs can easily be overlooked by other team members. For example, when selecting the best time for the daily standup meeting, it’s possible to alienate a valued team member who does not want the standup meeting to be at 8:00 a.m. because it’s the only time she is able to spend quality time with her kids before work. If she is a high “C”, she is unlikely to push for a later meeting time, and therefore this distraction could negatively affect her productivity. A strong leader could recognize this and “facilitate” the team to a more generally agreeable meeting time.
SSQ: Agile practices promote co-location. However, if I were to suggest an amendment to the Manifesto it would be “Mutual trust and respect over physical presence.” I believe that physical presence helps in establishing initial trust, but that once that trust is solid, modern technologies allow for strong collaboration. Do you agree? Why or why not?
Howard/Rogers: I agree with your phrase, “Mutual trust and respect over physical presence.” I also agree that once the trust is solid, modern technologies help with collaboration. However, I am also a strong believer that co-location is much better than a distributed team. Just last week I heard the statistic that only 7% of the meaning of a sentence is achieved by words while 38% is tone. And 55% is body language. Therefore, much is lost via documents, email or even phone. How many times have you sent an email that has been misinterpreted? Emoticons have added a lot to instant message communication. For example, if someone is making a joke or being sarcastic they can add a smiley face and express some level of tone or body language. However, miscommunication can and often does occur.
In today’s global economy, it would be foolish to say that all teams can always be collocated. But it is important for the teams to recognize the inherent issues and risks. In our book, we have an exercise called origami which demonstrates this very nicely. It’s fun to watch the “ah-ha” moments occur when conducting the origami exercise with groups.
SSQ: In the chapter on collaboration, you talk about diametrically opposing forces and say, “The conflict between the QA and developer roles is engineered to increase the quality of the software being built.” Though I agree with the yin and yang forces of helping to maintain balance, the conflict described, the developers’ frustration with a daily “Bug Report,” seems to be more one of a “we/they” attitude between QA and development. Wouldn’t this be better solved by a “whole-team” approach where both QA and development were responsible for reporting and resolving issues?
Howard/Rogers: I agree with you. The book was giving an example of the traditional conflict between QA and developer roles. While Scrum no longer distinguishes between the roles – it is the “team” – there often exists team members who are playing the traditional QA/test role and others who focus on development and so on. As you say, the “whole-team” approach is the way the Agile team should handle the sprint. There should no longer be an “us versus them” mentality. Together the team is making a commitment to produce quality/tested code. So, the goals of each individual team member are the same. Having said that, since the testers are focused on finding bugs and the developers are focused on fixing them, there would still exist some natural opposing force (which is a good thing). Agile facilitates this natural conflict since the individual’s goals are aligned as a team.
SSQ: With the strong emphasis on teams that is promoted with Scrum, might the Scrum teams themselves be creating the very silos or walls they are trying to discourage, alienating people who are not directly on the team, but still play a role on the project?
Howard/Rogers: An example of people not directly on the team but still playing a role on the project might be business stakeholders that care about the end product being built. Even though they are not “pigs” (from Scrum) who are committed to the project, they are still invited to be very much involved. They are invited to the daily standup/Scrum meetings and/or the sprint demos. So, the intent is not to alienate them but to include them.
SSQ: What do you think the biggest takeaway of the book will be for readers?
Howard/Rogers: We think the biggest takeaway is an emphasis on Agile as a culture (not a process). Agile has definitely become mainstream. The fact that PMI has started an Agile certification tells us that Agile has definitely crossed the chasm. We are also starting to see executives demanding Agile but not necessarily realizing that Agile is just as much, if not more, a set of behaviors, a leadership style and a culture as it is an iterative process. We are talking about behaviors like transparency, trust, respect for individuals, empowerment and so on. We hope that the book will enable teams to focus more attention on this aspect of the manifesto and will give specific stories and exercises to help facilitate discussions within companies and within teams.
For part one of this interview, go to:
Dig Deeper on Scrum software development