Agilists Are People Too
The other day, I found myself in an argument about the best way to do scrum Agile. We both had strong views, and neither of us wanted to concede the other’s points. Yes, it was an actual argument. I believe it went something like this:
“Well fine.”
“Fine.”
“See if I care.”
“Don’t worry, I won’t.”
“Fine.”
“Good. I’m glad.”
“I’m glad you’re glad.”
See, it’s that kind of brilliant, well-paired intellectual discourse that does little to help others take agile seriously. I’m not proud of the exchange, but I thought I would share this with you all, so you can learn from my stupidity.
Like everything in my life, it’s not until I get to reflect on what just happened that I realize where it went wrong. This goes beyond the “What I should have said was. . . ” It’s more rooted in my need to answer “How in the hell did that happen?”–a living retrospective. In this instance, I was insisting that there are certain tried-and-true elements that should be followed in Agile, and that wavering from those leads to failure. What I was forgetting was one of the fundamental truths of the Agile framework–it depends on the team. There are always exceptions, and every team has their own best way. Mike Cohn has a poetic little blog about this very topic:“The One True Way To Be Agile.”
But what struck me was a bigger question–a question about what we think an Agile team is really all about. These are typical expressions we’ve all heard or even stated:
“Let the team decide.”
“The team should be self organizing.”
“A self organized team will know what’s the most healthy.”
“The business problem is presented by the Product Owner; the solution should be defined by the Team.”
“The Scrum master’s job is to protect the team.”
But what so many books, and training modules, and classes skim over is just how singular every team can be. Think back on the teams you’ve worked with in the past and ask yourself if any one of those teams was identical–or even similar to another. Sure, they performed the same actions and engaged in the same Agile ceremonies, but that is where the similarities usually end. There are so many personality types, cognitive patterns and learning styles within even a 5 member team, that my mind reels that I would ever think that a particular set of “standards” would ever hold up for any length of time.
As scrum masters, our job is indeed to protect the team, but to do that, we really need to consider the people that make up our teams–the humanoids. Flesh and blood with odd electrical neurons firing. The very nature of the work we do–delivering software code– can be a bit dehumanizing, and that makes our need to consider team member individuality that much more important. We need to acknowledge that some of the best parts of the Agile framework can be considerably more difficult for some than for others. It involves accepting change, which in turn can lead to a sense of helplessness. Agile requires team members to be almost zen about . . well just about everything. When working with software and deadlines, and changing requirements, that kind of calmness and “absence of self” may not be possible. Even on highly functioning teams, individuals struggle from time time.
A few examples:
- Agile’s “loose” Framework—We’ve all been raised to follow rules, and many team members new to Scrum Agile see the guidance offered by a scrum master as wishy washy or “soft.” They want structure. They want rules. They want black and white, “if-then” decisions. Agile doesn’t play that way, and this can be literally distressing for team members. The scrum master who tries to placate these people with platitudes like “Just be patient and let the scrum agile work flow” is only exacerbating their distress. A successful scrummaster will find a way to put people with this personality type in charge of aspects of the team’s sprint–giving them a sense of control that they feel is missing in Agile.
- TDD–Test driven development is a GREAT way to get good cooperation between Dev and QA and even improve throughput, but the frequent, open communication required and the frequent early “Failures” are all REALLY hard for some personality types. A scrum master has to work with these people almost as though they are in couple’s therapy–to help them open up.
- Paired Programming–Like TDD, paired programming requires not only working closely with another person and close communications, but it also requires the developers to be completely open to criticism. Few people take criticism well and even fewer know how to give constructive criticism. A successful scrum master will be able to guide these team mates toward a give-and-take that works best for them.
All of those sound painfully obvious, but I am frequently disappointed when I see
 |
| The original father of emotional intelligence |
companies assign the role of scrum master to people who have little knowledge of (or in some cases actual possession of) emotional intelligence. I’m not saying that all scrum masters have to be therapists or experts in human behavior, but it sure helps if we acknowledge the individuality of our team members and personalize the coaching we are giving them.
Now, not everyone can have the patience and wisdom of Dick Van Patten’s “Tom Bradford” from Eight is Enough when working with their team members. It takes experience. It takes practice. It takes time. Like the Bradford kids, every member of a team will be carrying all manner of personal baggage from previous experiences. Over time, you as the scrum master, will figure out just how to get your Agile “family” through each sprint, helping your team members maintain their individuality while bringing the team as whole closer together. You will get iteratively better at it. And like the kids from Eight Is Enough, your team members will appreciate the fact that you are even trying.
nice post thanks for sharing. i will also share this article in my circle
Business softwares