Tag Archives: process agile scrum system control

It’s The System, Maaaan!

Battleship Control Room

Do the modes of control in your workplace encourage dysfunctional team behaviors?

For those of you working with Agile development teams, here’s a question:  Are the behavior patterns you see in your teams because of the personalities of the team members, or because of the structures the team is operating within?  Think carefully …

 

 

Out Of The Mouths Of Babes

Recently I was driving my 4th grade son home from school when we were blocked by an accident in my neighborhood. Our streets are very narrow and people park on the street instead of in their driveways for some reason, so you have to be careful passing traffic going the other way. This particular day, a school bus and a car going around a curve in opposite directions had sideswiped each other and were totally blocking the street while waiting for the police. No one appeared to be hurt, so we turned around to make a 2 mile detour to get to my house the back way.

During the drive, I said to my son, “Wow, I hope no one’s hurt.” Then I asked him, “So … I wonder whose fault it was?” I was thinking about the bus driver and the car driver, but he immediately said, “Whoever designed the road. It’s way too narrow.”

Hmm … good point. Maybe both drivers were doing their best, and the system constraints set them up for failure. Can we relate this back to Agile teams in some way?

A Bit More About Why People Do Stuff

Around the same time this happened, I listened to an episode of the excellent Invisibilia podcast called The Personality Myth (synopsis here). I was already thinking about systems inducing behavior in people, but this discussion went even further to talk about whether people even really have consistent personalities! That is, if you think about people you know, maybe they only seem consistent because you encounter them repeatedly in more or less the same situations: at work every day, as your spouse at home, as a friend you play tennis with, or whatever. You’ve probably had the experience of seeing someone you thought you knew in a new and unexpected way. One person can be a quiet software tester at work, a community leader, music teacher, protester, party animal … or someone might seem stable but change dramatically under financial, work, or social pressure.

The discussion about this in psychology is called the Person-situation debate (Wikipedia):

The person–situation debate in personality psychology refers to the controversy concerning whether the person or the situation is more influential in determining a person’s behavior. Personality trait psychologists believe that people have consistent personalities that guide their behaviors across situations. Situationists, opponents of the trait approach, argue that people are not consistent enough from situation to situation to be characterized by broad personality traits.

The podcast talks in part about a hardened criminal who becomes an expressive ballet dancer when exposed to a new set of expectations. So surely we should be able to change our Agile environments and get different results out of our teams, right?

Refine Your Agile Experiment

Agile asks us to continuously inspect and adapt not just the product we’re building, but also the process itself. Teams do this via holding retrospectives and acting on “things to try”, but often they are more focused on technical or mechanical changes rather than influencing behaviors. They may also stay away from certain topics because they perceive them as sensitive or otherwise off limits. Guess who gets to worry about those things? You do! Here are just a few things that can significantly affect how teams behave:

Measuring teams against each other. It’s really tempting to look at story points or actual hours and use those to compare teams. Don’t do this. Story points normalize over time for individual teams, but not across teams unless there’s a lot of cross-pollination of members and ideas. And teams’ “actual hours” are often … er … highly creative retroactive estimates. As soon as teams think you’re gauging them like this, they will start overestimating everything to protect themselves. Instead, look at the big picture. Is each team delivering obvious business value? Do they always burn down 100% of their committed stories? How do their features look? Do they generate lots of production bugs or later rework?

Measuring individuals instead of teams. If you want your teams to jealously guard information and little architectural fiefdoms, and point fingers when things go wrong, the best way is to measure each person on a team as an island unto themselves. If instead you want your teams to hold each other accountable and work together to get things done despite individual hurdles, make it clear that success or failure happens at the team level and keep that focus for things like rewards and performance reviews. Obviously there will be occasions where someone just isn’t a good team fit, but more often members of a high-functioning team will actively strive to support each other and fill in skill gaps so that they can deliver more consistently.

Chaotic or inconsistent process. Scrum (and Agile generally) is about rhythm and predictability. Plan, execute, review, repeat. Over and over every couple weeks, forever. Take advantage of that rhythm by doing things the same way you did last time – except of course for things you decide to change as part of your retrospectives. Is your planning day always on Mondays (for example), with opening and closing ceremonies at the same time? Do stand-ups start at 9:30 am in the same spot each time? Is backlog grooming every Wednesday at 4 pm? Do you have a standing invite list for sprint reviews? Are retrospectives done before the next sprint starts? Are you insulating the teams from random production issues somehow, by using a support team or accounting for support time in planning? The answers to all these questions should be “yes”! For everyone on your teams – developers, testers, Scrum Masters, Product Owners – executing on the current sprint should be the number one priority. If it truly is, you should be able to create a reusable template for each iteration and let other non-sprint stuff live in the gaps. If the sprint stuff is what’s living in the gaps, you have a problem.

Lack of solutions from management. Teams get asked to do a lot. I haven’t yet seen a sprint where the Product Owner starts out by asking the team to do 80% of what they did last time. It’s usually a down-to-the-wire negotiation during planning, and the team decides to “go for it”. Then stuff happens – sick days, production issues, technical surprises – and they push through all of these, or try to anyway. But they also need the system to work for them, which means listening to their concerns and acting on them as needed. Did they work too many hours last time? Did we spring a feature on them at the last minute? Are they still fiddling with old work while trying to start on a new goal? Do they have the right development machines and software tools? How about work space issues like chairs, ergonomics and noise level? Nothing’s more demoralizing to a team than knowing what’s wrong and feeling helpless to change it. You’re supposed to be helping build self-directed, empowered teams – so get to it!

Lack of a clear vision. Most people will work harder and smarter if they are part of a compelling story. Product Owners take the wheel here – hmm, will “take the wheel” make sense in 30 years when all cars are self-driving? Anyway … the vision for a team needs to start at a high level and zoom in to the current time and scope:

  • Where is the product going?
  • Where is the product going in the next quarter?
  • Where is the product going in the next release?
  • How does my team fit into the vision for the next release?

Teams need to understand this vision and believe in it. They need to see their work get released and used by actual customers. They need to hear feedback from those customers in some way, the more directly the better. If teams do a competent job but don’t seem to have any fire, and rarely deliver any brilliant insights, it’s a good bet they don’t buy into the vision.

In Closing

I’d like to stress here that I’m not saying that individuals are helpless pawns whose actions are determined solely by environmental factors. We expect professional software teams to succeed in the system of which they’re a part, even as they try to push and pull it into a form that suits them. But as a leader you can have a disproportionate effect on that system and can accelerate positive change. So next time you see unwanted behaviors in your teams, please at least think about whether the problem might not be with the individual players, but with the rules of the game.