Protective Collaboration

Protective Collaboration

I was recently asked my opinion about collaboration within an organization.  Being I just completed an organizational assessment for a client, I have a fresh perspective of the topic.

I was specifically asked:

“Is it healthy for Scrum teams to work in a bubble protected from the business around them? Should collaboration go beyond the team?”

There are two common threads that I see time and time again. One, what is the goal? Two, is that goal communicated?  Until these two threads are tied together, you can’t have good collaboration.  I don’t see this being unique to the world of Scrum.  To help illustrate my point, I’ll try to use terms people outside the Scrum community can understand.

Strategic Mission (Goals)

Executive Leadership, in order to lead, needs to communicate the strategic vision of the organization.  Strategic vision translates into strategic mission or long-term goals. Strategic mission should be understood by the entire organization.  If you don’t know the mission, how will you be able to help the organization reach its goals?  From there, the leadership needs to empower people tasked to do the work to figure out how they will accomplish the goals.

Tactical Mission (Goals)

This is where you keep lines of communication open but insert a protective buffer.  If you’re leveraging Scrum, that first buffer is called a Product Owner.  This person understands the strategic mission of the organization and is able to translate it into tactical mission.  You could also refer to this person as an organizational liaison.  This person or group of people don’t need to know all of the answers.  But, they do need to be readily available to answer questions from the team and to reach out to the appropriation organizational subject matter expert(s) when necessary.  The second buffer, when leveraging Scrum, is called the ScrumMaster.  If not leveraging Scrum, they could also be known as a process manager.  This person understands organizational process on a team level and is there to ensure the team consistently follows that process.  They also work to keep those who do not aid in tactical execution from derailing the team from getting work down.

Collaborative Team

It’s time for me to answer the first direct question. Is it healthy for Scrum teams to work in a bubble protected from the business around them?  Though I do believe the team should be protected from the business directly trying to change their tactical priorities, you should never operate in a vacuum. If people from within the organization do try to change team short-term priorities, the process manager (ScrumMaster) should be right there to impress upon them the needs of the organization and to respect the agreed upon processes.

Collaborative Organization

The second question was, should collaboration go beyond the team? My short answer is, yes.  Communications is different from collaboration and it needs to flow up and down the organization.  With information flowing freely, I’ve seen good (strategic) ideas become bad ideas overnight.  All it might take is one executive standing in the back of the room during a daily (stand-up) meeting.  Once the appropriate information is presented to the appropriate people, real collaboration can take place.  The entire organization, which includes all cost and profit centers, needs to collaborate to discover the best solutions and work toward common goals.

What do you think?

Did I miss anything?

4 Replies to “Protective Collaboration”

  1. Nicely written Derek!, and yes its true this is not something unique to the Scrum world. Sometimes we have a tendency of bringing -up old problems when a change is introduced in hope of a solution 🙂
    There is one additional layer that or circle I’ve seen, you may call it as the Program/Project Leadership team (PLT). I believe it is part of their mandate to ensure that the Tactical goals are not in conflict with the strategic goals. Overall yes I agree, the project or program team should have the freedom of setting up their tactical goals.

    1. Thanks Sam!
      If it fits the size and culture of the organization, I see a Directive PMO as the Program/Project Leadership team that you refer to.  For those without (or even with) that PMO layer, I would recommend a Portfolio Alignment Wall to help the organization visualize the portfolio of work and identify cross-dependencies between projects. Mapping tactical work back to this strategic visual management system ensures no conflict between tactical and strategic goals.

  2. Interesting: I really worry that the increased productivity on our Scrum team is at the expense of the rest of the organisation not being assisted when they need help and thereby harming their productivity. Developers can be very useful with support, sales, and services etc. Its important that product development consider the effectiveness of the organisation as a whole not just their own function. I agree it’s not necessarily as a Scrum issue, but perhaps scrum encourages it? I wrote a bit more about this here:

    1. Tom, I agree with you. The late Dr. Eli Goldratt once said “A system of local optimums is not an optimum system at all.” I don’t believe Scrum 1.0 or 2.0 addresses the organization as a whole. It still focuses on the team. Organizational complexity and uniqueness makes it challenging to apply such a simple framework but I think it can be done. Why can’t we look at the organization as just one large cross-functional team? Why can’t we look at the strategic goals and an organizational portfolio as the backlog?

Leave a Reply

Your email address will not be published. Required fields are marked *