Skip to main content

Teams are the Building Blocks of Agile Organizations

Mike Cottmeyer Chief Executive Officer
Reading: Teams are the Building Blocks of Agile Organizations

If you are going to embrace any form of agile, you need to start by thinking about your teams as the elemental building blocks of your agile organization.

Teams are Elemental

Regardless of whether you decide to organize around feature teams or component teams, you need to look at the team as the fundamental unit of organizational capacity. Francois Bachmann from SprintIT has a great way of saying this… build projects around teams… don’t build teams around projects.

We’ve got to stop thinking about how we are going to resource level across teams… or how to optimize the utilization of individuals within teams. Instead, let’s think about how we can increase the performance of the team overall. Let’s think about how we can develop better capabilities, greater technical prowess, and better working relationships between team members.

Great teams deliver great software… period.

With the team as the elemental unit of throughput… and knowing that over time we can establish a stable team velocity… we can begin to think about becoming predictable as an organization. We can start to see our teams as the building blocks around which we’ll construct our agile organization. We’ll be able to deploy teams of teams that solve our most critical business problems.

Normalizing Inputs

Think of a team as a black box that has both inputs and outputs. The primary input to the team is the prioritized product backlog. The output of the team is working software on regularly defined intervals. In order to get working software on regular intervals, you have to have a steady input of prioritized product backlog ready for the team to work on.

It is up to the business to normalize the input to the team if they expect to get a predictable output. If you put crap in the system… you are going to get crap out of the system. No groomed product backlog… no working software.

So from the teams perspective… all the normal agile stuff applies. Apply all great engineering practices… do the visual progress indicators… collocate… have daily stand-up meetings… do team building… and conduct retrospectives. That is the stuff inside the box. Regardless of scale… the team is king. They are an empowered, self-directed, self-manged unit of organizational capacity.

Everybody outside the team is responsible for making sure the teams have the proper inputs so that the business can get predictable outputs. The business has to act like a UPS that protects the team from unexpected spikes and brownouts. Scrum calls this function the Product Owner. I don’t care so much what we call it… or who does it… we just need to make sure somebody or someone does it.

Context and Coordination

Regulating inputs to the teams means providing context… what we are going to do and why; as well as coordination… when we are going to do things and in what order.

Over the past few posts… we established that the Product Owner in Scrum is the single person that acts as our UPS for the team. We’ve already explored how in any moderately complex organization, this role is too big for a single person to handle. What I am saying here is that naming a single person to play the role of Product Owner is not nearly as important as fundamentally making sure that each of our agile teams has stable input.

We need stable input so the teams can deliver predictable and coordinated outputs that align with the broader organizational objectives. This is not a product owner problem, it is not a team problem, it is a business alignment problem. Abstracting this problem behind the Product Owner concept only hides the mess.

This problem is further exacerbated as we start putting multiple teams together in order to deliver on broader organizational objecives. Remember… the problem is not finding single person to serve as a Product Owner… the problem is making sure that teams of teams have proper context and coordination.

Next Product Owner or Product Ownership

Comments (3)

  1. Dennis Stevens
    Reply

    Great post Mike. You inspired me to talk about the impact of promising on the performance of teams http://www.dennisstevens.com/2009/03/13/teams-and-promising/

    I have had great success in getting Agile teams much more successful by facilitating agreement on the promises made to the Agile team and by the Agile team. In his work on Conversation Theory, Gordan Pask says that our perspective of the conversation effects how we participate in the conversations. When we talk about continuous integration and SCRUM to people outside of technology, they don’t understand the expectations.

    Talking about the interaction between teams as establishing agreement on the promises being made raises the perception of the conversation from a technical perspective to a more tangible and human perspective. Promises have direct accountability. When we don’t establish the promise of coordination and context clearly we are acting as Dragon Slayers. “Ok, I will take your inadequate requirements and lack of clarity and work through the long dark nights to save the day.” This is setting the team up for failure and the leader of this team is malfeasant. We create the Dragon and then expect to be rewarded when we slay it.

    You are spot on with this post. After initial improvement in the development team, the key to improving performance for the organization is establishing the appropriate context and coordination.

    Reply
  2. Mike Cottmeyer
    Reply

    Haeckel talks about this in his work ‘Adaptive Enterprise’ along with the idea of context and coordination. Leaders provide context and coordination and teams make commitments that deliver on the goals of the organization.

    This is self-direction within the confines of organizational constraints. Lissack and Roos talk about this idea of creativity within constrained boundaries in ‘The Next Common Sense: The eManagers Guide to Mastering Complexity”.

    In a nutshell, they contend that any creative process not guided by constraints leads to chaos. Leadership provides the constraints… teams deliver the value.

    Mike

    Reply
  3. Jeff Anderson
    Reply

    great post

    this is something I’m always having to struggle with explaining to the typical PMP crowd.

    Individual resourcing doesn’t matter, team results do…

    Individual tracking just doesn’t scale on projects of any size…
    regards
    Jeff
    http://agileconsulting.blogspot.com

    Reply

Leave a comment

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