New Book: The Human Side of Agile
Coach, trainer and consultant Gil Broza has written a book focusing on the people factors that are needed for successful agile adoption and transformation in an organization. Titled “The Human Side of Agile” the book is aimed at leaders and managers who are guiding agile teams and guiding agile implementations in their organizations. He provides advice for leaders at every level and leadership role both within agile teams and those setting direction for programs of work.
An extract from the book can be found here.
Shane Hastie from InfoQ interviewed the author:
InfoQ: The title is “The Human Side of Agile” – surely Agile is all about putting humanity back into the software process? Why did you need to write this book? What is the problem you are solving?
Gil: Agile means different things to different people. I see it indeed as a people-centric philosophy for developing complex products. But many others think of it as a cheaper, better, faster way to do business as usual. The package of value and principles known as “Agile” has been around for more than a decade, yet most of the implementations I know about are too focused on process mechanics and moves. With my book, I wanted to paint a vivid picture of what is involved in “doing” Agile and “being” Agile, both for leaders and for team members. If you truly want to reap the benefits of Agility, you must address the human side of it.
InfoQ: You subtitle the book “How to Help Your Team Deliver” – who are you targeting the book at?
Gil: Leadership in an Agile team context has a singular purpose: to help the team deliver. Agile teams work best when they enjoy shared leadership. Everybody has innate leadership qualities and some level of desire, possibly unexpressed, to lead in some way. So you can lead either from a designated position or as a team member.
Having said that, most of the teams I’ve known in my career could use the help of a designated leader. That is the role I identify as the Agile Team Leader. It is the third role that already exists on so many Agile teams, the first one being delivery or development, and the second being customer or product owner. The primary readership of the book is thus people who are (or should be) in a position of leadership vis-à-vis their teams: ScrumMasters, project managers, managers, senior folks. Other team members are the next circle of readership as well as of leadership: the book helps them express their leadership qualities suitably in an Agile context, and shows them what the dedicated leadership they deserve looks like.
InfoQ: What makes an Agile Team Leader? What are the characteristics of this person, and what are their responsibilities?
Gil: As an ATL, you understand and believe that you’re a servant leader who’s there to help your team deliver. To qualify as an ATL, you need certain skills, behaviors, and attitudes. One of these skills is excellent communication. Some of the behaviors flow from recognizing that you don’t command or control anyone in your team. A necessary attitude is that the team will succeed more when you lead, nurture, and coach people rather than manage their work. It is very much about people skills and people orientation. That’s why the ATL shouldn’t be confused with the technical leader.
The responsibilities fall into four broad categories: people, product, process, and project. Of course, context is everything; the details and “dose” of each category depend on your team’s makeup, stage of evolution, and constraints:
1. People responsibilities include heading off distractions, providing air cover, and holding people accountable. You’re there to help people do their best work in a collaborative setting.
2. Product responsibilities include ensuring the flow of business value, keeping stakeholders in the loop, and doing a lot of coordination. That means you also help the busy product owner do their work well.
3. On the process side, it’s process stewardship (not ownership), removing impediments, and facilitating team interactions.
4. Two substantial project responsibilities are: ensuring that the team is properly staffed and effective, and reporting needed information to the rest of the organization.
InfoQ: How is the Agile Team Leader different from a ScrumMaster or a project manager?
Gil: If there were a single interpretation of the ScrumMaster and project manager roles, I could give you a straight answer…
See, I know ScrumMasters who behave exactly as ATLs. But I’ve also met ScrumMasters who told me, “I’m here to enforce the Scrum rules. And book meetings. And monitor the burndown chart. And track velocity.” Those guys focus mostly on the Process category of responsibilities.
It’s similar with project managers. Over the years, many PMs have told me, “I make sure my team knows what they need to do, and I stay out of their way.” But other PMs believe the fate of their Agile project rests on their shoulders alone. They’re worried, so they end up micromanaging, mistrusting, and focusing too much on artifacts and progress metrics. Those PMs emphasize responsibilities from the Product and Project categories.
An effective ATL looks at all four categories (in particular the People one), and accepts those responsibilities that would matter most to the team. Early in the book, I invite ScrumMasters, PMs, and other “third role” folks to step into Agile team leadership. They don’t need to be promoted or formally designated as such; rather, it’s about their identity, values, attitudes, and behavior.
InfoQ: Agile teams are supposed to be self-organizing, so why do they need a leader? And what does the leader do to encourage self-organization by the team?
Gil: I wholeheartedly support the ideal that teams should be able to lead themselves. Where that’s possible, you may not need a designated ATL. But in all my years in the industry, I have encountered or heard about only a handful of teams like that. In almost every team, the personalities and behaviors, the complexity, and the organizational context make a dedicated ATL necessary. (Scrum teams are already expected to have designated ScrumMasters, and, as I said before, great ScrumMasters are really ATLs.) Even with a dedicated ATL, by the way, individuals still can – and should – play to their own leadership strengths.
Just because you remove the organizational shackles and give a team freedom to self-organize doesn’t mean they will necessarily do that or that they’ll do it well. I see this again and again whenever I lead a workshop or a simulation, which are far less complex than the typical development environment. I have intelligent professionals form groups, and some groups thrive while others stall.
Here are 5 ways a leader can help self-organization:
- Rally the team behind meaningful targets, goals, or outcomes. Keep playing those up so members can convince themselves that working together with their particular teammates is worthwhile.
- Encourage people to play to their strengths and to discover their colleagues’ strengths.
- Help the team make clear agreements and set behavioral expectations that match their unique situation and culture.
- Coach individuals and the entire team: offer feedback, help with experimentation, give support in difficult conversations.
- Ensure that supporting process mechanisms are in place. And make sure they’re actually supportive in the team’s context; there’s really no such thing as “best practices,” only practices that seem to work well for many others.
InfoQ: How does the leader help when there are dysfunctions, disruptions, and negative attitudes within the team?
Gil: Workers deserve and must have an emotionally safe team environment. Company policy, social norms, and professional courtesy can only go so far. Having a clearly identified, capable leader increases safety not just during team discourse (such as meetings and workspace interaction). Such a leader would also notice emotional behavior, hold regular one-on-one encounters for feedback and coaching, set and clarify boundaries, and use the organization to keep alignment.
By the way, in many other environments managers take on this duty and apply the same tools. I simply don’t think that a capable, genuine leader has to be the boss to get the same effect.
InfoQ: How does the leader protect the team from external organizational dysfunctions?
Gil: The leader can shield the team in 3 high-leverage ways:
- Providing “air cover”: acting as a buffer between the team and the rest of the organization. The leader simply enables team members to do what they are already paid to do. An example would be hiding details of individual task assignment and of micro-progress from those who don’t need to know about it outside the team.
- Championing: the leader needs to actively tend to relationships and influences that might adversely affect the team. For example, the greater the team’s reputation for excellence, the more likely they are to be broken up to bolster other teams. They need protection from that, and individual team members can’t usually offer that protection.
- Taking a stand for the team (this way may be needed even in the best of organizations). For instance, I’ve seen too many teams receive a verbal lashing from an executive for messing up a sprint demo. The leader would help the team recognize the slip-up’s significance and impact, take corrective action, and prevent recurrence. And she would also have the difficult conversations with that executive and with other stakeholders to demonstrate how they are taking responsibility. These tough times are when leadership is tested, since without a leader the team is apt to quickly descend to blaming and justification.
InfoQ: You title an entire part of the book “Engage People in Powerful Conversations” – what are the characteristics of such conversations, and why do they matter?
Gil: Conversations happen in the workplace all the time. Hundreds of them take place daily just between managers and subordinates. But once people form teams and intensely communicate sideways (with their colleagues), that’s an order-of-magnitude more conversations. The trouble is that many conversations at work are downright awful. Misunderstandings, walking on eggshells, unintentional slighting, and unclear agreements are everywhere.
Powerful conversations, on the other hand, are worth having. They result in progress. A powerful 1-on-1 conversation (that’s the focus of one of the chapters) is both delightful and energizing. A powerful team conversation (that’s the other chapter in this part) strengthens the team. When you strengthen the team, you increase engagement, mutual accountability, productivity, and retention. These conversations are characterized by patience, listening, respect, acceptance, rapport, and caring.
InfoQ: What advice can you offer to help make meetings more effective?
Gil: Did you know that some Agile teams out there have a daily standup without knowing why it matters? That’s your first target: know your meeting’s purpose, and make sure the participants know it. My good friend and coach extraordinaire David Spann likes to say, “If I could change corporate culture with only one sign, I’d post the following on every conference room door: ‘If the meeting you are about to attend has no stated purpose, please return to something that does!’” I share this particular message with most of my clients, too.
My next advice: if the meeting requires safety, ensure that it’s really safe. We’ve all attended muted retrospectives where only the obvious, innocuous challenges were discussed. That’s a waste of everybody’s time and goodwill. Dig for the reason and you’ll usually find that it’s safety-related.
My third piece of advice: facilitate meetings. Facilitation involves assembling the right group, helping it set objectives, crafting a workable process so that it can meet those objectives, and then taking the group through the process. If the team leader doesn’t know how to do that, they should get training ASAP. Facilitation is measured by the group’s achievement of valuable results, not by following a process. For instance, it’s about getting value from standups and retrospectives, not about asking three questions or filling two columns with “Worked Well” and “Needs Improvement” stickies. Don’t rotate it among team members unless you know what you’re rotating.
InfoQ: How does an Agile Team Leader help teams stay the course when adopting Agile approaches, and when making change in general?
Gil: Change isn’t a one-time thing. It has three stages: first you prepare for it, next you execute the change, and then you make the new situation a habit, a new status quo. Different activities are needed in each stage.
In preparing for change, the team leader can make sure that its necessary conditions are met. One of these conditions is education. The ATL should remind the team that change always involves a chaos period, which can be easily mistaken for failure. Other universal conditions include motivation, bandwidth, focus, and sponsorship. And then there are a host of conditions that are specific to your context.
During the execution of the change, the team leader can manage expectations, protect the team from interruptions that can derail the change, and help install feedback loops for the change’s effects. In some situations, those loops involve metrics.
Having made the change, you now need it to stick – to become habit and the new normal way of doing things. The ATL can again offer feedback, also known as mirroring, to reinforce the fresh behaviors. He can monitor (informally or otherwise) for bounce-backs and point them out as they arise. And he can keep looking for even further improvement, to prevent complacency.
InfoQ: What happens to the Agile Team Leader when the team has made the transition to being an effective self-organizing group? How does the leader contribute to continuous improvement?
Gil: The more evolved and successful the team is, the less the leader needs to be involved. When teaming has been taken care of, as I like to say, the leader can transition to protecting the team and helping them be even better. She can bring new ideas from the outside, organize learning opportunities, and continue to support individuals’ growth. She also needs to keep challenging the team so they don’t rest on their laurels (and do stay motivated). And, on a bigger scale, the leader can expand her sphere of influence to inspire even greater Agility within the organization. This contributes to global optimization and increased efficacy, which may be far more valuable than team-level optimization.
About the Book Author
In the last 10 years alone, Gil has mentored more than 1,500 professionals who then delighted their customers, shipped working software on time, and rediscovered passion for their work. Gil has also:
- Served as a development manager, team leader, and programmer for 12 years, successfully applying Agile methods since 2001
- Coached more than 40 private- and public-sector clients, large and small, including independent software vendors, custom development firms, and organizations that build software for internal use
- Written several practical papers for conferences and trade magazines, including the prestigious Cutter IT Journal (Gil also co-produced the Coaching “stage” at the Agile 2009 and 2010 conferences)
Throughout his career, Gil has focused on human characteristics that prevent positive outcomes in software development teams. These include limiting habits, fear of change, outdated beliefs, and blind spots. In helping teams overcome these factors, he supports them in reaching ever-higher levels of performance, confidence, and accomplishment. Gil offers much-needed services (beyond basic education) to help ScrumMasters and other Agile team leaders grow in their roles. In addition, he provides workshops, consulting, facilitation services, and enablement programs to fix lackluster Agile attempts and support ongoing Agile improvement efforts. He is in high demand by individuals and companies looking to fully realize Agile’s potential.
Want a taste of what makes Gil different? Visit this link to receive Gil’s popular (and free!) “Something Happened on the Way to Agile” mini-program. Consisting of 20 daily training segments, it will help you break the cycle of Agile mediocrity and move toward the promised benefits of Agile.