Agile Coach What is Agile Coach ?

Introduction to Agile Coach

Agile Coach. If you work with other people to build software, then you’ve spotted at least a few things some practices, ideas, attitude changes that will help your team.Now, go ahead and do it. Make your team go agile. Right now! That doesn’t seem quite realistic yet, does it? There’s a big difference between readingabout values, principles, mindsets, and practices in a book and actually changing the way that a team works.

Some teams are able to take a book on Scrum or XP, adopt the practices, and immediately see great results. After reading Agile paractices, you should recognize why: those teams already have a mindset that’s compatible with the values and principles of the Agile manifesto and the methodology.(Agile Coach)

To a compatible team like that, adopting agile feels easy because the individual people on the team don’t have to change the way that they think about their work. So if you already have a mindset that’s compatible with the agile methodology you’re trying to adopt, you’re much more likely to have a successful adoption.

But what if you don’t already have a mindset that works for Scrum, XP, or another agile methodology? What if you’re working in an environment where it’s difficult to succeed with the agile values? What if individual contributions on your team are rewarded far more than team effort? What if mistakes are punished harshly? What if you’re in an environment that stifles innovation, or where your team has no access to the customers, users, or other people who can help you understand what softwareyou’re building? These are all barriers to agile adoption.

This is where an agile coach comes in. An agile coach is someone who helps a team adopt agile. Agile coach will help each person on the team learn a new attitude and mindset, and get past the mental, emotional, and technical barriers that prevent the team from adopting an agile methodology.

Agile coaches work with every person on the team to help him or her understand not just the “how” of the new practices that they’re being asked to implement, but also the “why.”
slowly change their attitude, and to get into the right mindset so that they go beyond simply getting better-than-not-doing-it results.In this article you’ll learn about agile coaching: how teams learn, how an agile coach can help a team change their mindset so that they can more easily adopt an agile methodology, and how that coach can help you and your team become more agile.

"Agile coach" Why People Don’t Always Want to Change

Most people in your organization are trying to do a good job. They want their peersand supervisors to see that they are good at performing the tasks assigned to them.When someone has developed a level of comfort and familiarity with his job, the lastthing he wants is to have someone come along and make him adopt an entirely new way of doing things.

Coaches spend most of their time helping people on teams change the way that they work. This is challenging for both the coach and the team, because only the coach sees the big picture.There are many ways that a well-intentioned team trying to adopt a practice can alterit so that it doesn’t really work anymore. But many teams that attempt to adopt Scrum end up just using it as a daily meeting for team members to report their individual statuses, in which the Scrum Master acts as a de facto project manager and assigns work to them.

Similarly, some teams add stories to business requirements documents, but otherwise treat those documents as specifications in the same way most waterfall teams do.They’re still doing big requirements up front (BRUF) development, just with user stories added. Or instead of doing test-driven development, some teams attempting to adopt XP will just make sure that they have very high code coverage for the tests that they develop after they build the code which means the tests don’t have any impact on the design, because it’s complete by the time the tests are written.

In all of these cases, the people on these teams are genuinely trying to adopt agile. But in each of these examples, the people on the team don’t really understand how those practices fit into a larger ecosystem of a methodology. So instead of trying to change the way that they work, they focus on the part of the practice that feels familiar.

Most of the teams adopting agile alreadybuild software, and have some success. Completely dysfunctional teams rarely have a manager who is open-minded enough to let them try agile in the first place. They’re naturally looking to make small, incremental changes, because they don’t want to break what’s currently working.

Why do team members so often insist on adopting only the practices that seem familiar to them, and reject any practice that doesn’t immediately translate to something that they’re doing today?

Because every new practice is a change, and there’s always a chance that any change won’t work out. And when changes at the office don’t work out, people get fired.This is something that every agile coach needs to keep in the front of his or her mind.The job of coaching is to help teams to change, and change can cause an outsized but entirely rational—emotional response from the people being asked to change.

Why? Because work is how you pay for your life and feed your family. When we’re asked to learn and do new things at work, if we don’t feel like we can master them quickly and easily, it causes us severe emotional discomfort. There’s a basic hunter-gatherer part of our minds that thinks, “Yesterday I knew that I could do my job and bring home food for my family, but today I can’t be sure of that anymore.”

This is an important reason why being expected to learn new things at work can cause anxiety and seemingly irrational reactions.Another reason why people push back against a change at work and gravitate towar what they already understand is that they don’t feel like they have time to sit and think through all the reasons behind it. For example, it’s very common for teams to adopt agile by simply trying it on a pilot project. This often starts when one person has read a book about agile, and is now leading the whole team through their adoption while at the same time, dealing with deadlines, bugs, conflicts, changing requirements, and all of the other things that happen during a typical project.

This is not an ideal proving ground for a completely new way of thinking about work. People will do the best they can, but if there’s something they don’t quite get, they’ll keep the label “agile” and the names of the methodology and practices, but little else will change about how they work. Milestones in their old project plan are now labeled “Sprint,” or maybe someone puts up a task board that never really impacts the work being done. In the end, the team will just do what they did before, because they know that it worked in the past, and there’s a deadline.

When a team uses the names of agile practices but doesn’t change the way they work,it’s not hard to see why the team members quickly become disillusioned with the ideas behind agile. To them, it’s a reasonable assumption to think that agile is just another name for whatever it is they’re currently doing. They think that they’ve adopted agile, but they haven’t changed the way they work, so they get the same results. The people on the team will decide that agile doesn’t work, without ever realizing that they never actually saw anything that resembles agile in real life. They have this reaction because they’re being asked to change how they work without understanding Coaches Understand Why People Don’t Always Want to Change why, and without someone to help them through the change without compromising the integrity of the new practices and ideas.



This is why teams need agile coaches. An important job of the agile coach is to recognize when people are being asked to do something new, and to help them feel comfortable with the change. The coach needs to give that person context for the change,so they understand why (and not just what). This helps the team actually change the way they work, rather than simply taking the name of something from an agile methodology and attaching it to a practice that they already do.

For example, a good coach will explain—in language that everyone understand how the Daily Scrum helps the team self-organize, how test-driven development helps the team think functionally and move toward incremental design, or how user stories help everyone on the team understand the perspective of the people using the software. The coach helps everyone go beyond just adopting new rules, so they start to see where they’re going and what these new things will eventually give them

"Agile Coach" Coaches Listen for Warning Signs That the Team Is Having Trouble with a Change

If you spend time coaching many teams, you’ll hear many of the same sentiments repeated from different people. Here are a few things that team members say that could indicate that they’re uncomfortable with a change, and what you can do when you encounter them which is useful for seeing things from the coaching perspective, even if you’re not an agile coach:

We already build software well. Why are you telling me to do something different?

It’s hard to argue with success. If you’re working with a team that has a history of getting software out the door, they have a right to know why they need to change at all—and it’s not enough to tell them that the boss said so, because that will just undermine their morale. As a coach, you need to stay positive about the work that the team did in the past. But don’t be shy about pointing out problems that they ran into. The practices in every agile methodology are aimed at fixing problems that teams have; if you can help your team understand why those problems are happening and give them solutions, they’re much more likely to accept thechange.

This is far too risky.

This is a very common response to agile, especially to someone who’s used to a command-and-control style of project management. Where are all the buffers? Where’s the risk register? Where’s all the extra bureaucracy that slows down the project and gives me plenty of CYA? A project plan can be opaque, which can make teams comfortable: they don’t need to share details beyond vague milestones, and can build in buffers to reduce and even eliminate variability.

When you use status reports as the primary measure of software progress, you can controle The message that you give to the users and customers. To a team that’s used to these things, agile can feel very risky.

If something goes wrong on an agile team, everyone knows. Your job as an agile coach is to help the managers, users, and customers to feel comfortable with this undiluted measure of progress and give the team a safe environment where they’re allowed to fail today, as long as they learn from it tomorrow. If this isn’t realistic today, then your job is to help everyone, especially the boss, to set a goal to change the team’s climate and attitude in the future.

Pair programming (or test-driven development, or some other practice) just isn’t going towork for me.

developer used to working alone might feel in his gut that pair programming will slow him down. He may even have a legitimate point if he works on a team (or for a boss) with a mindset in which mistakes are simply unacceptable, then it’s reasonable for him to feel uncomfortable having another person watch him code. And anyone who’s taught a teenager to drive can relate to the uncomforta‐ ble feeling that a senior team member might have thinking about letting a junior team member control the keyboard for their pair.

There are a lot of reasons that people can rationally feel uncomfortable with these practices, especially when the team has a mindset that doesn’t match the practice. A good agile coach will help the team first choose the practices that are compatible with their mindset. As the team members start working those practices, they’ll see the benefits and understand how and why the practices work. With guidance from a good coach, everyone will naturally start to shift toward a more agile mindset.

Agile doesn’t work for a business like ours.

People often say this because they’re used to building large and detailed plans or designs before work begins, and they can’t imagine working any other way. Command-and-control project managers and bosses get a lot of comfort from having the scope, requirements, and project plan on paper before any work starts. And in the same way, architects and development leads are reassured when the entire design for the system is on paper before the first line of code is written. Now they’re being asked to trust the team to make decisions at the last responsible moment—and that means giving up that control.

So they’ll say something like, “Our business is very complex. People in other companies may be able to jump right into projects, but because of how our particular business works, we need to do all of this planning and design ahead of time.” The truth is, every business is complicated, and every project needs analysis and planning. A good agilecoach will help the managers, businesspeople, and development leads to see that teams are much better at capturing that complexity when they’re allowed to divide the project into smaller pieces, and have the freedom to make decisions at the last responsible moment.

This is exactly like what we’re already doing, just with a different name.

This is one of the most common reasons that people reject agile methodologies. They’ll find ways to keep doing what they’re doing today, and just choose new names for them that match agile practices they’ve read or heard about. This can make all of agile seem trivial—and even wrong, if they’ve decided to give the agile name to a practice that failed for them. In fact, if you do a web search for a term like “agile sucks” you’ll find people who have done exactly this, denouncing agile as “hype” without substance because it’s just another name for old waterfall practices. They’ll even call agile an “obfuscation” of simple, commonsense software development. As a coach, you need to recognize that this isn’t done with malice or ill intent; it’s just a natural reaction from someone who’s never actually seen agile (but thinks he has). Your job, as a coach, is to help your team understand that agile really is different from what they’re doing, and that it doesn’t suck.

One good model for mastering anything (if that’s possible) comes from martial arts. Amartial arts student progresses through three stages of proficiency called Shu Ha Ri Shu: Follow the rule. Ha: Break the rule. Ri: Be the rule.
In Agile Software Development: The Cooperative Game, Alistair Cockburn talks about a basic idea of learning called shuhari, and it’s a very valuable tool for a coach trying to figure out where the team is. Shuhari is adopted from martial arts, but it’s a good way to think about how people learn about almost anything. In Shuhari, learning comes in three stages.

"Agile Coach" The first stage, shu (守, “obey” or “observe”)

describes the mindset of someone who first encounters a new idea or methodology. He wants simple rules that he can follow. This is one reason that people latch onto practices: the team can make a rule about adopting sprints, pair programming, using a task board, etc., and everyone can tell whether or not it’s being followed.

Shuhari, ha (破, “detach” or “break”)

An agile coach needs to understand more than simple rules, which brings us to the next stage in Shuhari, ha (破, “detach” or “break”). This is the stage where people have gotten practice with the rules, and can start to understand and internalize the principles that drive them. When people on a team reach the ha stage together, they start to progress from getting better-than-not-doing-it results to getting the real gains in productivity that come when a team truly adopts an agile mindset.

Shuhari,ri (離, “separate”)

We haven’t talked much about the last stage, ri (離, “separate”). When you reach the ri stage of learning, you are fluent in the ideas, values, and principles. You care less about the methodologies, because you’ve gone beyond them. When you have a problem that can be fixed with a specific practice, you and your team just do that practice.You don’t really care if it’s Scrum, XP, Kanban, waterfall—it doesn’t matter, and your process doesn’t need a name. But it’s not like the chaos that you see on a team where nobody has tried agile. A team where everyone has reached ri is a smooth, wellfunctioning team, where everyone just does what’s right.

The Principles of Coaching

John Wooden, coach of the UCLA men’s basketball team in the 1960s and 1970s, is widely considered one of the greatest coaches in the history of sports. In his book, Practical Modern Basketball, he lays out five basic principles of coaching: industriousness,enthusiasm, condition, fundamentals, and development of team spirit. They make just as much sense for an agile coach as they do in basketball:

1. Industriousness

Changing the way a team builds software means working hard at things that they’ve never done before. Developers have to think about planning and testing, not just coding. Product owners need to understand what the team does, not just throw features over the wall at them. Scrum masters need to learn how to give the team control, while still staying involved with the project. These are all new skills, and all new skills require work.

2. Enthusiasm

When your heart is in your work, and you’re excited about a new way of doing things, it rubs off on everyone around you. And there’s a lot to be enthusiastic about: you’re solving problems that have given you headaches in the past. When everyone goes into agile with a real enthusiasm toward it, you get more than just better software; you get a team where everyone is more innovative, happier, and excited about working together every day.

3. Condition

Agile works when every team member is good at what he or she does. There’s a real, implicit assumption that everyone has pride of workmanship: they try to build the best software that they can, and work to get better at building it—and that they’re genuinely motivated by pride in their work. This is why every member of an agile team continues to work hard at improving their skills, so that they bring their best condition to the project.

4. Fundamentals

Wooden writes, “the finest system cannot overcome poor execution of the fundamentals. The coach must be certain that he never permits himself to get ‘carried away’ by a complicated system”—and this is especially relevant for an agile coach.Agile works because its values are simple and straightforward, and its methodologies consist of uncomplicated practices. These are the fundamentals of agile,and a good coach works to keep the team focused on them, and helps the team to keep things simple.






5. Development of team spirit

We’ve talked about self-organization, whole team, energized work, and empowering the team: ways that agile teams build each other up and create a collaborative,innovative work environment. On the flipside, an agile coach needs to be on the lookout for team members who are primarily focused on their own personal performance, career goals, résumé, or getting promoted out of the team, and help them change their attitude. Wooden is clear about the effect that sort of person has on team spirit, and what to do about it: “The coach must use every bit of psychology at his command and use every available method to develop a fine team spirit on his squad. Teamwork and unselfishness must be encouraged at every opportunity, and each [team member] must be eager, not just willing, to sacrifice personal glory for the welfare of the team. Selfishness, envy, egotism, and criticism of each other can crush team spirit and ruin the potential of any team. The coach must be aware of this and constantly alert to prevent such traits by catching them at the source before trouble develops.”

These five principles are a solid foundation for the mindset of an agile coach. Animportant step in becoming a great agile coach is to understand, internalize, and usethem, in exactly the same way as you would use the values of the Agile Manifesto andany agile methodology.

Source Content = Learning Agile: Understanding Scrum, XP, Lean, and Kanban