If you’ve followed my blogging at all, you know that I’ve worked for several companies in the last 6-8 years that have colored my thinking as an agile coach. Sure, I’ve coached a wide variety of other organizations, but there’s nothing like being an employee of a company and assuming the role of technical leader and agile coach to get your attention each day.
One of those companies was iContact (now Vocus), which develops an email marketing SaaS platform. This story comes from my time spent there working with some wonderful development teams.
Conflict and Confusion
We had a fairly well established Scrum instance at iContact. And the teams had generally received entry-level Scrum training at one time or another, so everyone was relatively on the same page. One of the things I noticed early on though was quite a bit of what I’ll call – role confusion.
It often happened with the Product Owners. For example, they would be haranguing the teams about their estimates being too high and the sprints not producing enough work. Often, the User Stories they were writing included design details and internal construction guidance as well as sharing the functional requirements.
This was causing the teams angst, because they felt the Product Owners were stepping into their area of responsibility. And, they were.
But the problem didn’t solely rest with the Product Owners. In fact, it was much more pervasive from my perspective. Literally everyone seemed to be struggling to figure out his or her ‘place’ within our agile transformation. And it was leading to a great deal of confusion and some unhealthy conflict. It was also undermining our capacity and results—in that we were wasting time posturing instead of driving forward as teams.
The Root Cause
After observing this for a short while, it struck me that perhaps our initial Scrum training spent insufficient time or focus on clearly defining and establishing the core values, principles, and roles within agile Scrum teams. You could clearly see it in the behaviors and conflicts that were occurring.
I felt it might also be too individually focused, so too little emphasis at the organizational and team levels. When I spoke to several of our Scrum Masters, this was exactly the case. They had sort of “jumped into” sprinting without establishing some basic team-based agreements and guidelines.
And by the way, this didn’t come as a surprise. I think many teams jump in too soon towards execution without establishing a baseline of understandings and agreements for how they’ll “behave”.
The Way Forward
I pulled together a presentation for the teams that tried to explain the expectations of what I thought were good agile practices, tactics and the mindset. Not only did I explain the role of the Scrum Master and Product Owner, but I also explained the role of the cross-functional team and managers/leaders within our agile context.
So I tried to explore all aspects of the organizational dynamics.
I also tried to make the point that the roles are situational in nature and quite nuanced. For example, I’ve always felt that leadership forms across the entire agile team. I believe the Scrum Master and Product Owner play an important role as leaders. But I also want the entire team to take on situational leadership roles as each sprint and release unfolds.
Beyond these roles and responsibilities, I also explored some of the following –
Principles & Values
Looking at core agile values – I went back to reaffirm the Agile Manifesto and the principles behind it. Too often we look at these as something ethereal. Yes, they’re nice, but do they really apply in the “real world”?
Well, the answer is – yes, they do. So we explored these as an organization and I/we tried to make them more real and more relevant within our organizational context. And as a leadership team, we also took the time to “go on record” as supporting the principles. And that included supporting them when the going got tough in our projects.
Constraints or “Guardrails”
One of the things that often amazes me when coaching some agile teams is how frequently they interpret agile methods to be a “free for all” to do whatever the heck they want. I sometimes liken it to – The Inmates Running the Asylum.
But then I think about the “best” agile teams I’ve encountered in my career. The most mature, the ones with the greatest quality and efficiency, the ones who ultimately delighted their clients. And it occurs to me that they didn’t do it by doing whatever they wanted or whatever was easiest.
They did it by being:
- Very principled and consistently holding to those principles;
- By being very rigorous in their application of technical practices;
- By putting the team before the individual and swarming around their work;
- By having very specific definitions of done and always adhering to them;
- And by putting the customer first and truly looking to deliver what they needed vs. what they asked for.
In a word, I think these mature and effective agile teams were self-directed BUT incredibly disciplined at the same time.
I would argue that having a finely grained definition of done goes a long way towards establishing team norms and behaviors. I would encourage you to explore the multi-layers and nuance around this.
And, By The Way, You’re Never Done
So, we went through this roles and responsibilities level setting exercise at iContact and at the end I thought great, now we can put this behind us. But I was wrong.
After about 3-4 months, we noticed some of the same patterns emerging. Then it struck me; the organization is growing and evolving. We’re getting new folks in, some are leaving, teams are re-forming and roles are changing, and even our leadership team is evolving.
Point being—it’s a moving target.
We then realized that we had to “re-do” our work iteratively, about every 4 months or so, to re-initialize our understanding across our teams. It was sort of funny. I would “dust off” the same set of Powerpoint slides, updating them as appropriate. Then we would go through the sessions again for the entire organization.
To some it was redundant. To others it was brand new. But there was never a session that was exactly the same nor that didn’t explore new ground in some way. So be prepared for refreshes.
Wrapping Up
I guess the title is misleading in that I don’t believe it’s a question any longer. Do we need roles and responsibility clarity in agile teams?
I hope the answer is a clear and firm – Yes.
I think you owe your teams this as a Scrum Master and Coach. And that even the best of us often forget how important “starting up well” is. One of our more senior Scrum Masters at iContact reminded me of this when she joined our team. Her name was Maureen Green.
Maureen came in and found that her team hadn’t established team norms and agreements, that they hadn’t made our organizational definition of done their own, and that they were waffling on many of the principles we aspired to hold firm to. Instead of just charging forward, she “paused” her team and established these sorts of agreements and clarity first.
Not only that, she served as a role model for our other Scrum Masters to tighten things up in this important area.
If you’re struggling with your teams’ execution and results, I would encourage you to consider “starting over” and redefining your agreements and principles as a way to accelerate forward.
Stay agile my friends,
Bob.