We'll respond shortly.
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:
Moving to the details, here is what the stages look like for an Agile team:
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.
Each person will talk for varying lengths, but strictly adhere to the Yesterday/Today/Blocker (LINK) pattern.
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?”
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.
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?”
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.
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.
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.
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.
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.
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?”.
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?”
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.
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.
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.
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:
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.