From handshake to trust fall: Patterns of high-performing agile teams

May 20, 2014 Nic Werner

Waterfall, agile, XP, lean – these are all processes and methodologies. But it’s still a team of humans building the software. And how the team works together is crucial; we’ve all been on projects where more time was spent on why it was doomed to fail than on actual development. And the lucky few to have been on high-performing teams you’d swear shipped code in their sleep and communicated telepathically. Enter Tuckman’s 5 stages of Group Development. Introduced in 1965, he breaks down how a team develops from a motley crew to Mötley Crüe. We’ll review these five stages from an Agile lens, and pinpoint potential issues that stop teams from evolving. Five stages of group development:

  • Forming: Team meets each other, sometimes for the first time. Everyone is polite and avoids conflict.
  • Storming: Members begin speaking up, voicing opinions. Conflict arises, processes are challenged. Cliques are formed.
  • Norming: Members converge on agreed-upon conventions, such as regular stand-up. They begin policing each other and enforcing their flavor of team dynamics. Individual roles are clarified.
  • Performing: Team is at highest productivity, focusing on delivering product. They understand each others communication styles and fill in gaps where needed.
From: http://www.the-happy-manager.com/articles/teamwork-theory/

From: http://www.the-happy-manager.com/articles/teamwork-theory/

Moving to the details, here is what the stages look like for an Agile team:

FORMING STAGE:

In the forming stage, the team may not know each other or may be new to the agile methodology. People are polite to each other, and apologetic if they’re not doing agile “the right way”. Everyone silently accepts the goals of the project, even if they’re not sure how or why it is being built. The product manager lays out the agile process, the times for meetings, and steers all discussions. If any mistakes are made, people think it is their fault, not the team.

Standups (forming):

Each person will talk for varying lengths, but strictly adhere to the Yesterday/Today/Blocker (LINK) pattern.

Iteration Planning Meeting (forming):

The PM has inconsistent writing patterns for stories. Estimating is awkward and all over the place. Junior members may not be comfortable explaining their estimate, and they’ll politely defer to other team members. Nobody will ask the age-old question “But how do you get Back from that screen?”

Retrospective (forming):

The happy column will be full of items such as “Great we’re starting!”, “Looking forward to working with everyone!”. The sad column will be non-confrontational and generic so as to not upsetting anyone directly, “Pairing stations took longer than expected to setup”, “Not used to a standup desk”. During discusssions, people aren’t specifically called out for anything bad.

STORMING STAGE:

After holding back in the forming stage, the criticisms come out here and members become vocal. At this stage the PM is still steering the decisions and direction of discussions. This gives the team umbrella cover regarding product, which causes them to focus on *how* they’re going to build it. That makes people nervous since they’re on the hook to deliver but they view other team members as not carrying “their share of the load”. Now if any mistakes are made, people point fingers at others, not themselves. Criticisms are focused at specific people, and cliques form to discuss the weakness of others. Team members will complain about agile, that standups are a waste of time, and that better time could be spent coding. PM and Design are criticized: “I wouldn’t buy this thing”, “Are we really going to put this design in front of customers?”

Standups (storming):

People will still talk for varying lengths, but may be interrupted. Side discussions will occur, and the PM (or scrum master) is constantly intervening to steer the conversation.

IPM (storming):

Long and painful. A large amount of discussion is focused on personal “I” preferences. Members use this time to voice their unhappiness of a certain technology choice. People talk over each other, and the product manager is constantly cutting off conversations to move things forward, “So, are we ready to point this?” The meeting will run long because the PM has barely any pointed stories in the backlog and they need the team to estimate.

Retro (storming):

The sad column explodes after a week of pent-up frustration. “Stories are too big”, “Stories are too small”, “Low velocity”, “Blocked on design again”. Debates from the iteration meeting carry over, rehashing a controversial decision made by a certain pair. Only a handful of items are covered due to time.

NORMING STAGE:

The team comes together. They’ve aligned with the agile process and ryhthm; acting collectively and focusing more on product. They now understand each others inputs and needs so requests flow smoothly. Shift from use of “I” to “We”. The recurring items (retro, standups,etc) are tweaked to fit the needs of the team, not the individuals. Everyone agrees on which meetings are for structured or unstructured conversations. If anyone strays from these team-decided agreements, the team polices them as a whole. The PM is steering less of the discussions as the team understands the goals. Social norms are introduced, such as clapping after standup, or having breakfast together. People start asking about each others lives outside of work.

Standups (norming):

Updates are generally shorter as the team understands context behind the stories. Updates are focused less on process “I’m grooming the backlog” and more on product “Yesterdays user testing showed some great insights”. People will call “Time” on longer updates, and those that are interested in the update will stick around after. For time efficiency, tech standups are sometimes added for developers to give deeper updates without taking up time of the full group.

IPM (norming):

Meetings run smoothly and within the allotted time. At this point, the team knows the balance between deep technical discussion and enough information to provide an estimate. Story pointing is fairly consistent among the team, and everyone is comfortable asking for more clarification or defending their appraoch. The PM is writing stories that the team readily groks, and design is providing clear mockups with thought-through interactions. People begin to use eye contact to signal “let’s move along”,”can you help curb this?”.

Retrospective (norming):

With a few iterations under the belt, the team is more optimistic about implementing change or delivering functionality. The “meh” (Watch) column increases – not out of pessimism but because people want to bring it up as a topic of discussion. “App starting to feel sluggish”, “Not many stories accepted”. Conversations are now constructive, “How can we make the app snappier?”, “Can we dedicate a pair in the morning to help the PM accept stories faster?”

PERFORMING STAGE

Productivity is at its highest as the team has clear understanding of product vision, their roles within the team, and how to communicate with each other. The team is completely autonomous, and everyone feels free to make decisions without lengthy consultation. The agile process fades to the background as the team hones in on execution. Velocity is high. People are using Happy Hours to celebrate, not to vent.

Standups (performing):

Teams are generally co-located at this point, so daily communication and overhearing reduce the need for extraneous updates. The walk back to your desks should be longer than the meeting.

IPM (performing):

Very similar to the norming phase, these run smoothly. Since the team is no longer scrambling to estimate within the hour, high-quality communication increases. The PM uses this extra time to re-iterate the broader vision, and communicates any learnings that may shift the roadmap. Design shows an overview of upcoming features, or user-testing findings. Conflict is still encouraged, but the team focuses on the potential problem, not the person.

Retrospective (performing):

At this point, it’s almost a casual hangout. The team uses this time to let off steam, or raise items they feel need discussion. People will vote on certain items that they know colleagues want to discuss, or to receive feedback. This can be a checkin point “Quality of stories?”, “Users happy with new features?” Keep in mind that the steps are not linear, and the team can revert at any time. The Performing stage sounds like a unicorn utopia, but what if your team doesn’t seem to be moving along? What if you were once crushing it, but now you’re back to complaints and in-fighting? The Storming phase is where most teams become mired, let’s look at a few reasons:

  • Team members are constantly rotating through the team, challenging processes and procedures. The team has to spend more time enforcing their norms and less on shipping. Keep rotation to a minimum or either absorb the new person quickly.
  • Less-experienced team members are afraid to speak up, and others aren’t encouraging them. This leads to an imbalance where junior devs don’t feel like this is a safe environment for them to grow and develop. In IPM, ask quiet developers to explain the thinking behind their estimates.
  • Manager is micro-managing team, trying to solve all their problems. This practice prevents the team from working out their own strifes, inhibiting accountability and development of team values. Build an umbrella so the team can resolve their own differences.
  • PM focuses on what they think the product should be, not the needs of the personas. The team loses trust in the product vision and their true market. Reinforce the focus on user personas in user stories.
  • Runaway discussions in IPM. While the goal of the meeting is unstructured time to discuss technical approaches to building, teams can go off in tangents. Have a pre-IPM with the lead developer to walk through the stories and explain your approach. This helps them steer the team away from technical tangents.
  • One person sidelines all conversations and refuses to acknowledge other thoughts. Doing “the right thing” for the customer means a fully functioning team. Give this person a growth plan, and if you don’t see improvement, talk with the team, make the tough call and remove this person.

Now that you’ve seen the value of a Performing team, take the time to observe your team, starting inward. How do you react to criticism? How do you provide feedback to your team? If you feel the team is stuck, start with your own actions, and use your optimism to influence the team towards positive outcomes. Interested in being part of a Performing team? Labs is hiring, check here for our open positions! If you’re a PM, find me on LinkedIn and we can chat more.

About the Author

Biography

Previous
Cloud Foundry at the OpenStack Summit Atlanta 2014
Cloud Foundry at the OpenStack Summit Atlanta 2014

Last week we attended the OpenStack Summit Atlanta 2014 and we were amazed not only to see the great moment...

Next
Unit-Testing AngularJS in a Rails app using the Jasmine gem
Unit-Testing AngularJS in a Rails app using the Jasmine gem

Testing AngularJS applications is easy with Jasmine. If you look at the AngularJS docs, many of the code ex...

×

Subscribe to our Newsletter

!
Thank you!
Error - something went wrong!