Project vs Product team

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 likley 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 critisised, 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 characterised 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 cognisant 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, 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 organisations 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.

References:

Tuckmans stages of group development – available at:¬†http://en.wikipedia.org/wiki/Tuckman’s_stages_of_group_development

About these ads

About craigew

I am a technologist at heart and enjoy working with like minded people who show a passion for what they do. Craftsmanship is important to me and each day I am honing my skills as a software developer on a journey to one day becoming a master software craftsman.
This entry was posted in Leadership, Software development and tagged , , , , , , , , . Bookmark the permalink.

3 Responses to Project vs Product team

  1. PM Hut says:

    Hi Craig,

    Your theory can work on small projects for small organizations. But it can’t work for large projects. You must have a project team that is disassembled at the end of the project – that’s the nature of project management. You must also have a product team that will handle the product once it’s released. The project manager must handover all the information and all the documentation to the product manager at the end of the project. The product manager then will pass the knowledge to the product team.

    By the way, this is actually an excellent post (although I disagree with it), and I would like to republish it on PM Hut where many project managers will benefit from it. Please either email me or contact me through the contact us form on the PM Hut website in case you’re OK with this.

    • craigew says:

      Hi

      Thanks for your comments. Depending on what you classify as a big project, I would classify a big project as one that runs for longer than a year, then most my arguments hold true for the project team as “product team”. They will experience all the stages of group development (forming, storming, norming, and performing) and get the benefits of reaching the performing stage. But I think it is something the PM must be aware of and help the team to reach the performing stage as quickly as possible. Secondly, due to the length of the project, the team would be incetivised to put the necessary components in place to improve their practice and eliminate waste in their delivery cycle. I would say that my initial argument holds true for projects that are less than six months in duration. For the shorter duration projects the team can still put all the components in place to improve efficiencies, but I don’t think they ultimately end up performing optimally, unless off course it is a team that stays together from project to project.

  2. Pingback: Lean Software Development Principle – Deliver Fast | Craig on software development

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s