Have you ever heard of Tuckman’s stages of group development? According to Tuckman, teams must go through four stages -- Forming, Storming, Norming, and Performing -- in order to grow and develop as a collective. This quarter, my team entered the ‘Performing’ stage: we gelled. We finished our quarterly objective early and the feature release has been a success for users.
So, what does a performing team look like? And how did I know that my team had entered this stage?
First, I’d like to share with you where Rally was when I started here as an engineer almost three years ago. We had just switched over from full-on Scrum to Kanban. In Scrum, timeboxed commitments are king and predictability rules. Kanban is a little different in that your team pulls the work as you finish the previous piece of work, and it flows through the system much like a car flows through a manufacturing plant before it rolls out the door. Switching to Kanban brought its own problems: commitments and timeboxes became bad words, and we lost predictability. Furthermore, teams had no shared sense of urgency for time commitments; developers were shielded from much of this pressure by the product owner.
A little over a year ago I became product owner. I’m still learning as I go, but one thing I know is that dates matter. Everyone wants to know when customers are going to get access to a feature. They want progress on how the beta’s going.
During my first months as a product owner I would show up with a feature, plan it with the team, and have them pull it. Though features took a while, my team never questioned why we were pulling certain features. They assumed that I had done my due diligence on the customer development side, and figured that I understood the customer value we were providing.
Then one day, everything changed.
Sales came to Product with a customer escalation, an urgent request to help one of our customers find a solution to a major obstacle. I had some urgent calls with one of our VPs, a few directors, and the customer, and we started brainstorming possible ways to quickly fulfill their needs. We were given a date: show progress on the solution by the end of Q1.
Once we understood the need and I budgeted my team’s time, I and a few members of the UX team went to visit the customer to learn more. We came back with a good understanding of an MVP (minimum viable product) and entered our Q1 planning with a decent list of stories.
In planning, my team started examining the work and subsequently began to pull it apart. Everyone knew there was a date looming in the near future; the customer was expecting to get something by the end of the quarter, and this changed the game. Suddenly the question became, Is this absolutely necessary for the first release? Can we delay this story until the must-haves are complete? By the end of planning, the size of the feature went from 21 stories down to 11 stories, and everyone felt confident that it was doable.
(Flickr Library of Congress, CC)
The examining didn’t stop there. Every week in planning, the team questioned my initial acceptance criteria along with our priorities. We continued to ask, Is this the most important story that we can pull right now? How much do customers really want this? Throughout the development process, the team actively helped to define the feature.
Team members came to beta calls to find out how their work was received by users. They listened thoughtfully, and took action afterwards. They continued to ask questions in planning: Are we sure this is the most important implementation for this story? Can we split this off and prioritize it later?
The team also grew comfortable telling other developers, No, we can’t help you with that defect right now, because we have a feature to do. Their number one priority was making their commitment. We all shared the sense of urgency.
We released our feature, early -- not because it was perfectly planned at the beginning of the quarter, but because the team felt ownership and responsibility for its success. It was our MVP and then some.
Rally has a concept we call “delighters.” A delighter is a part of a feature that isn’t necessary, but will really please and delight the user. Not only were we able to release the MVP of the feature, but we released several delighters that hopefully made our customers’ lives a lot easier.
It feels good to be a part of a performing team. I always want the team to feel collective ownership for the success of a feature. My team members should feel comfortable questioning our priorities and what’s in my head, and I should have a thoughtful answer for them. I always want to encourage them to listen to customers and hear both positive and negative customer feedback. This will only make us feel more invested in our product and the features we’re producing, and that’s certainly one mark of a high-performing team.