Project vs Product Team

Project vs Product Team
By Craig Williams

When it comes to creating teams to deliver software, I believe the impact and lag of getting the team to perform optimally is underestimated. Project teams are setup for a specific goal, they work towards that goal, they deliver and then they disband. And in my experience this has the potential to have some bad consequences. You can bring the best developers together, and they will deliver, but it will not necessarily be optimal.

I believe there are two areas that project team fall short when it comes to delivering software. The first is around the team dynamic and how the team grows as individuals and performs as a unit. The second area is around the practices that are required to deliver software in a manner whereby the team is continually able to eliminate waste.

If we take Bruce Tuckmans model of Forming, Storming, Norming and Performing. Teams start out in the Forming stage, where the team members are more interested in being accepted and causing as little conflict as possible. Even though the team might be delivering, it most likely is sub-optimal.

As software developers we need feedback, and the people we get it from is our team members. In this stage we are likely to get only positive feedback and to give positive feedback. It takes time before we are comfortable giving and receiving the difficult feedback, which grows us as developers. We need to understand each other and how best to approach these difficult discussions. No developer likes to have their code criticized, and we need to learn each others temperament in order to deliver this feedback constructively.

Next the team moves into the storming phase, which is typically characterized by tension, struggle and sometimes argument. How long the team stays in this stage depends on the maturity of the team. Being able to constructively debate and argue around ideas is crucial for the delivery of good sound software. In this phase team members would be arguing strongly for their ideas in an attempt to prove their competency, possibly at the detriment of a idea of a quieter less outgoing developer.

This type or arguing is typically wasteful and the team lead must steer the team in order that the arguing does not lead to dissent. I have found that in this phase the argument often revolves around problems and not solutions, because the team members are not fully aware of the domain they are working in.

The team needs to be in a safe space where ideas are thrashed out and everyone contributes. All the pomp and ceremony of shouting loudest for ones own ideas needs to be replaced by efficient idea generation and discussion. This starts to occur when the team moves into the norming stage. During this stage the team is starting to all pull in the same direction with a common goal. They are starting to work efficiently together and they are becoming effective in delivering software. However, the leader must still be cognizant of the fact that team members might still be shying away from conflict and not debating problems to the fullest.

Finally we get to the performing phase, in this phase the leader becomes a participant and the team really performs as a unit. This is the phase that we want to keep a development team at. This not only allows team members to grow as better developers, testers or BA’s (Business Analysts), but most importantly the team delivers software in the most efficient way that their constraints will allow them.

I have also notice that as team members come and go, the team will move between these phases. New team members bring fresh ideas and approaches that inevitably unbalance the status quo. This is a good thing, but the team leader must be aware of this and facilitate the team quickly moving back to the performing phase.

Moving away from the team dynamic I also believe that it is not in the project teams best interests to work towards a set of principles to enable continuous improvement. Unless they are working in an environment where tools such as Jenkins and Sonar are already in place there is no incentive to leave this legacy. The project team is there to deliver working software, not to ensure the future maintainability and quality of the software.

When a team is working towards long term goals, such as a product team would be, it is in their best interest to setup automated mechanisms to provide feedback that empower the team to constantly improve their software. In my experience, having something as simple as Sonar running against your code base daily and then fixing any new violations from the previous day, allows for the slow incremental improvement of software. And you experience the benefit of this over an extended period of time, not overnight.

A team revolving around a product has the prospective of performing manual tasks into perpetuity, unless they leave the team of course. A project team on the other hand has a set period after which they will move on. Therefore it is in the product teams best interest to eliminate these wasteful manual tasks and automate them.

I have just recently had the experience whereby deployments took multiple steps across multiple machines, it is now automated and deployments can be done with a single button click. This saves a developer 15 minutes for each deployment, and anyone in the team can now do a deployment. It is not a technical task anymore. We did this, not only because it is good practice, but because none of us enjoyed doing it and it would be a task that would not go away.

So, in closing, I believe that it is in an organizations best interests to have their delivery orientated around product teams, rather than creating project teams that are created to deliver a set of requirements and the then disbanded on completion. This tends towards a short term view that could lead to problems in the future.

Craig Williams is a technologist at heart and enjoys working with like minded people who show a passion for what they do. You can read more from Craig on his blog.