Getting a New Team to do Cool Stuff

When I took on my current job I was given an established product team and a mostly-new engineering team. We also had a brand new engineering manager, QA manager, and program manager working with us.

Our job was to launch an all-new version of Toolbar while we maintained our existing versions and continued to support new corporate partners. Engineering and QA had just been moved overseas. We didn’t have any well-defined processes in place to build and maintain software. Without a clear process, or “rules of working” that described how individuals would be accountable within that process - the first few months were difficult. We struggled to prioritize current bugs against future features, and to support our existing partners while we tried to create a foundation for a new kind of partner business.

The team leads and I spent a lot of time trying to setup, execute, and debug a product development process that worked for us. In the first few weeks I spent most of my time figuring out where our strengths and weaknesses were. Being a product guy with an engineering background I focused on finding the holes in our product and technology: features we were missing, things that didn’t quite work, where our technology worked well and where it was a smelly mess, and so on.Over a period of weeks we began to tighten up our product definition, and to understand, prioritize, and fix some of our deep rooted engineering and process problems.

We were pretty effective, and shipped a version that was mostly well received. But I felt that the “re-launch” of the new team didn’t go as smoothly as it could have. Our team and process hadn’t been fully formed, and I didn’t have a good model to determine what to fix first. The other managers and I used our experience and intuition to decide what to look at first; we then gathered some data and made some decisions. But I, at least, never had a complete framework in mind. I’ve since done a bit of reading on the topic and mean to sum it up here.

Forming Storming Norming and Performing: Back in 1965 Bruce Tuckman created the Forming – Storming – Norming – Performing model of group development. In a nutshell, the stages are (borrowing from the wikipedia article):

  • forming: the team meets, learns about opportunity and challenges, and begins to tackle goals as a group
  • storming: “team addresses issues such as what problems they are really supposed to solve, how they will function independently and together and what leadership model they will accept”
  • norming: “Team members adjust their behavior to each other as they develop work habits that make teamwork seem more natural and fluid.”
  • performing: “Some teams will reach the performing stage. These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision.”

Tuckman’s model goes on to describe why each stage is necessary, and how leaders should act in order to be most effective at each stage. Much of this is common sense, but the article is still a good read, and most “team building” training in place today seems to build on Tuckman’s work.

The Agile Maturity Model: In his post last week Tyner Blain details an Agile Maturity Model. He outlines a “hierarchy of needs” that somewhat follows Tuckman’s example. Read it for yourself, but Blain’s six levels were:

  1. Staffing the engineering team correctly - And I would replace “engineering” with “entire team” correctly. This takes the form of managing for performance as well as re-shuffling roles and responsibilities to match skills with needs.
  2. Assuring Quality is in your team’s DNA - This was huge with us. Individually, every person on the team was committed to quality, but we had no shared understanding of what level we should be shooting for. What makes a “P3” bug a “P3?” What kind of architectural limitations can we live with, and when should we refactor? We needed to come together to answer these and other quality questions, and get us to the point where we could ship a product that we were all proud of.
  3. Reducing overhead in the release process. - Oh GOD yes. You can’t have a fast, agile team, productive team that has fun unless you’ve taken most of the drudgery and variability out of the release process.
  4. Feeding the beast. - This is what I’m currently struggling with. Once you address the first three points and begin to move faster, you find yourself constantly running out of requirements for the team to work through. One way to solve this problem is to set clear, higher-level objectives and empower the engineering team to work directly with the QA, design, and product teams to build stuff. I’m a bit of a control freak, but I think that there are big gains to be made if you can empower your team in this respect.
  5. Managing stakeholder expectations - ’nuff said
  6. Continuously learning from your markets - this is a topic that deserves a post unto itself - it is the foundation of creating wonderful products.