THEY… Made Me Do It!

I was attending a Backlog Grooming session with one of our teams. I was simply observing as a coach, as the team had a solid Product Owner and Scrum Master in the meeting. It was generally my habit to “wander around” across our various teams and sit in on Scrum ceremonies as much as I could. Usually, as in this case, I just sat quietly. Observing the “goings on” and seeing if I could provide some offline guidance to our Scrum Masters.

In this particular session, the team was leveraging Planning Poker to estimate the amount of work in a series of User Stories on their backlogs. The discussions were going quite quickly, as the Scrum Master would put an egg timer on each story for 5 minutes of discussion, estimation, and “next step” decision-making. The point of examining each story was not to “complete it” in that one grooming session, but to advance the understanding of it and, if it was not a Sprint-Ready story, to decide what the next step in its evolution needed to be. The teams in general were quite good at staying on-point and not drilling too far into each story.

I did notice something though. There were two patterns “in the room” on a story by story basis. One was that the room seating layout was odd. The “developers” seemed clustered at one end of the conference table and the “testers” at the other. The developers seemed to be estimating as a group and the testers seemed to be following their lead. So if the developers gravitated towards a story being 3-5 points, the testers would most of the time wait a bit and then agree with the developer’s estimate.

On the rare occasion when the testers disagreed on points (level of effort, complexity, etc.) for a story, there would be heated debate across the two groups and quite often (almost always) the developers would drown out the testers concerns and they would acquiesce to the estimate. Then the timer would expire and the team would move on…

The other pattern surrounded Randy. Randy would often start out with an extremely high estimate, higher than everyone else in the room. When he discussed the ‘why’ behind his estimates, it was rarely driven by concrete experience or specific reasons. Typically, the rationale was simply:

This sounds like an awful lot of work and if I have to do it, it will take me a very long time!

As discussions unfolded, Randy would never move from his initial estimate. It seemed like he was simply ‘stuck’ there. Eventually the team would need to agree on an estimate and Randy would begrudgingly succumb to the estimate. Then the timer would expire and the team would move on…

Randy had another mode of operation. Often he would flip-flop and “go low” on his estimates. Often the language surrounded things like:

If we hack this together and skip testing these specific conditions, then I could see us doing this 20 point story in 2 points. In fact, if we work overtime, we could do it in 1 point.

When the team confronted Randy on his oscillation, his rationale was always driven by THEY. As in:

They’re going to cut my estimate or not listen to it anyway, so I need to go high. Or they’re not going to give me enough time or trust me to do a good job anyway, so why should I worry about doing things right?

No matter how hard the team tried to get Randy to be more “balanced” in his views, it never really helped. Then the timer would expire and the team would move on…

Who are THEY?

In the first example, the testers THEY were the developers on their team. The testers weren’t comfortable debating them on story scope or holding the line when they felt something was larger than the developers thought. In their retrospectives, it turned out that quite often the tester’s impressions of relative size, their instincts, were much more accurate than the developers. This was probably due to them considering all aspects of a story and not simply the development time.

In the second example, I believe Randy’s THEY was his historical experience with pleasing folks and dealing with demanding and poor leadership. I also believe the roots were well before he ever came to iContact. Randy was riddled with FUD – fear, uncertainty, and doubt regarding the organization and leadership. In the latter case, he would low ball the estimates because he felt that THEY couldn’t handle the truth of real estimates. He basically would say what he felt folks wanted to hear.

His oscillation was around frustration. So occasionally he would ramp up the estimates and try to hold the line—no matter what. So, he would fluctuate between too high and too low estimates, neither of which he believed to be true.

I remember stopping Randy in the hall once and asking him to “tell more truth” around his estimates. And to trust me more, in that I meant what I said around agile principles. What I wanted, as the leader of the technical organization, was for team members to analyze the story and to estimate what it would take to do a well-engineered, high-quality job. A job that they could be proud of! I remember him telling me that leadership (THEY) didn’t want that. Instead, they wanted low ball, cut corners, do it as quickly as possible estimates.

I stopped him and said that, in this case, I am THEY. And I’m asking him to estimate with truth, quality, and craftsmanship in mind. So there is no THEY in this case; there is only ME and I’m asking you to do what I’m asking.

While we had this discussion on several occasions, I don’t think Randy ever got (or at least believed and trusted) that message. Whatever baggage he had—he continued to carry. I recall when he left iContact, I was hopeful that he would leave THEY behind him and start with a fresh perspective in his new team.

Other They’s

In the same grooming meetings as I mentioned in the beginning, often the Product Owners would have their own THEY. In their case, THEY were Product organizational leadership. And THEY were telling them to put pressure on their teams and themselves to “get more done”. That the leaders had prmised customers more features and this pressure then would cascade down to the Product Owners on the individual teams.

How would this emerge in grooming? In a wide variety of ways:

• Often they would second guess the estimates of the team. Looking for ways to get them lower. They would apply questioning, pin one team member’s view against others, and simply keep asking for “better” estimates.
• They would also put pressure on the team to take on “stretch items” as part of every sprint. Then, once the team accepted them as “stretch”, they became firm commitments for the sprint.
• It created a sense of tension in the team, where the Product Owner would be very feature focused and not want to take on any bug fixes, refactoring, or other technical debt work within the sprint.
• Keeping people busy was the overriding theme and not delivering high value, high quality work in a balanced fashion. So if anyone had an extra second, the Product Owner looked to “fill it up” with something.

What was most insidious about this interaction was the sense of distrust and lack of collaboration it created between the Product Owner and the team. In this case, Product Owners allowed the THEY to breakdown their team relationships, which was very sad.

Wrapping Up

One of the five core Scrum values is Courage. I wrote another blog post surrounding that attribute that you might find valuable. But I do think “courage” has something to play in the above scenarios. In these cases, you’ll hear me talk about:

• “walking your talk”;
• “telling truth”;
• “sharing your gut feelings”;
• “filtering less”;
• and “telling it like it is” as the most congruent things you can do.

Often it can be extremely hard to be balanced within your teams. But it’s what they need most from each of you.

I want you to ask yourself if you’re doing things for them? Or are you doing it for yourself? Have the courage in your agile teams to speak the truth and tell it like it is. Don’t succumb to THEY, THEM or even ME. Simply be true to yourself. I hope that the testers, Randy, and Product Owners have discovered this in their paths.

As always, thanks for listening,

Bob.

Story Context
This is another in my series of stories from my days at iContact. I spent time there from 2009 – 2012 working as the Director of Software Development and Agile Coach at this wonderful and mature startup. During that time we grew to approximately 300 people in size, with roughly 100 in Technology. The product space was a SaaS, email marketing application. We had about 8-12 teams that were practicing Scrum and Kanban for roughly 4+ years, so a relatively mature agile instance. Since I’ve left the company, iContact was acquired by Vocus. These stories are rooted in the experiences I had coaching and collaborating with this wonderful group of agile practitioners.

Don’t forget to leave your comments below.