Monthly Archives: December 2016

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.

Definition of Ready (to be a robot)


Robots are cool, but they don’t get to make important choices.

Most agilists are familiar with Definition of Done (DoD): a team works together with the Product Owner to agree on a set of criteria that they can all point to and say “a story is complete when this list is checked off”. DoD can get pretty elaborate, including automated testing, documentation, bug rates, and so on. Teams don’t always hit their DoD with every story, but it’s a shared goal and reduces debate over what “done” really means. The value of a Definition of Done seems pretty obvious.

Definition of Ready (DoR) is the natural companion to Definition of Done, but it’s used maybe a bit less often. It lists out all the characteristics a story should have before the team accepts it into the sprint. It’s most helpful when teams struggle in their collaboration with Product Owners, business analysts, UX specialists, or other dev-team-adjacent roles. It says, “look, we’re eager to make a firm commitment and get started on this work, but we can’t just wing it. We need good acceptance criteria, and need to have talked about the stories enough to feel like we know what you want and how long it might take. We expect some challenges and surprises, but there’s no reason to be totally unprepared.”

Again, the value of a good Definition of Ready seems apparent. But I recently saw a DoR that looked something like this:

  • Acceptance Criteria detailed enough to be the basis of a test plan.
  • All UI wireframes completed by the UX team.
  • All text content finalized and translated.
  • All input validations detailed and complete.
  • System designs complete and finalized by the architecture group.

… plus all the usual stuff about sizing, review with the Product Owner, and the INVEST story characteristics.  Seems good, right?  I thought so at first too.

So, What’s the Problem?

The team with this Definition of Ready had a few notable characteristics:

  • The Product Owner and adjuncts (BA, UX) struggled to get things ready in time even though they were clearly trying.
  • The team was quick to point to missing DoR items as a reason for problems getting stories done and done well. “Well, the error messages weren’t provided.”
  • There was an over-dependence on design “spike” work prior to the sprint, often by different people.
  • Team members often complained that the work was boring or cookie-cutter and that there was no room for creativity.

What if I paraphrased the team’s DoR like this: “Before we start to work on these stories, we want them to pass through a series of gates – Product Owner, UX team, and architecture team – so that everything is finalized and we can be 100% sure in advance we know exactly what to build”? Hmm, what’s that sound like? Starts with “W”, has “RF” in the middle, and ends with “L” … no, not “Winterfell”. Waterfall!

How Did This Happen?

The team certainly didn’t mean to ask the business to spell out their work for them to that degree. They were reacting to some common problems that spring up in teams, mostly around communication. This team was pretty disconnected from the customer and the product vision, and wasn’t getting involved in any of the brainstorming and back-and-forth debate about features and how they should work. In addition, the organization was under a lot of pressure to deliver a lot in a short time and was reluctant to give the development teams an open license to be creative; instead, people in various named roles were expected to provide 100% of the ideas in their space. Finally, communication during sprints was unreliable because of how busy everyone was with design for the next feature, conferences, customer surveys, meetings, and tons of other stuff.

In this environment, the team had been left in the lurch more than once. Three days left in the sprint, and no one to answer a question. Lots of “we actually meant this; can you squeeze in that change?” Bombshells, curve balls, the works. And despite all this, a real quickness to blame the team any time a sprint didn’t burn down 100%. They went into defensive mode and traded the joy of creativity for the certainty of detailed requirements.

The Fix

There’s no exact right amount of detail to demand before accepting a story into a sprint. We’ve all heard that a story is an invitation to a conversation. That conversation should certainly start before the sprint, in story sessions, backlog grooming, and high-level design white-boarding. But it absolutely must continue into the sprint as the team begins to grapple with the details and has early builds available in test environments. That means that the Product Owner needs to be available throughout the sprint, which is a basic Scrum rule that is often broken to varying degrees. It also means that the team should have more authority over technical decisions and should not need be overly reliant anyone outside the team to give them answers. Remember, an ideal Agile team has the skill set to deliver a feature on their own. They should make a plan to own the work themselves and pull in auxiliary resources as needed instead of waiting to be given a complete instruction manual. If those auxiliary contributors have daily, strong, and open communication with the team, the team can get comfortable with a bit more ambiguity going into a sprint. I feel strongly that this makes for a healthier, happier team that is able to really deliver the spirit of want the business wants, and more often than not surprise and delight the Product Owner with brilliant solutions to the business problems posed to them.

I’m not saying to throw out your Definition of Ready, if you have one. Just don’t let it be a substitute for continuous communication or for trusting your development teams to make some decisions in flight. And teams – don’t write all the creativity out of your job.