In agile methodologies there are two generally accepted ways to group teams: project teams and product teams. Project teams are generally focused exclusively on a well defined goal or objective, and have a completion date to meet and/or a budget to run out of. Product teams generally are intended to support and improve an entire product or system, and generally have regular release dates.
There is no small amount of controversy regarding which is “better” or “more agile.” My contention is that either system are effective ways to manage initiatives
How Are Product and Project Teams The Same?
In a healthy agile environment project and product teams work iteratively. They build a simple solution that meets their customers needs, show it to their customers, and then incrementally refine and add features. Both types of teams have commit to the work they are going to complete for every single work cycle. They are each empowered to work within their budget and their time frames. Fundamentally they are the same. Where they are different is how they are focused and what amount responsibility they have.
So… How Are They Different?
A project has very finite goals. They are intended to cause some change, or bring X or Y. They can be as grand as re-branding a multi billion dollar company or as tiny as creating a way for a customer service team to track call volume. They have objectives which have end points. Once that objective is complete the project is over and the team is either disbanded or moves onto the next project. Generally a project team is not responsible for maintaining the project they just completed. Instead, they hand off that responsibility to a maintenance team.
Product teams don’t necessarily have a well defined goal. Instead they cover a product from creation all the way to the point when it is no longer being sold. This means they don’t have an definitive end point. A product teams responsibilities should not be limited to building a website, but also maintaining it. They are responsible for creating new content, patching security vulnerabilities, and adding additional features. They don’t get to hand off the code base to a maintenance team when they deliver version 1 of their product.
Pros and Cons
Both types of teams are valuable. Each has significant strengths and weaknesses. Project teams can generally get things done faster. They don’t have to worry about supporting another piece of software and are focused completely on their objective. Mmm. Focus. However they’re not very good for adapting to change in overall business needs. Good agile teams will always be good at navigating tricky waters, but if a projects goal is Morocco when it should be Hawaii… Well, that’s not always easy to determine in a project team because their objective is already well defined.
Product teams tend to make slower progress towards a stated objective. They may wind up needing to fix a problem in software 3.0 while trying to make progress on version 4.0. This added mass can slow a team down, but it also allows for flexibility. Instead of running full speed ahead at version 4, they can create version 3.0.1, then 3.1.3 and so on and so forth. The result is evolutionary instead of revolutionary, and lends itself better to consistent delivery of value.
When Should I Use Them?
Project teams are at their best when:
- The objective is already well defined and understood and brings clear value.
- You are creating something that someone else will be responsible for owning and maintaining. Contracting companies, for instance, favor project teams.
- You do not anticipate needing to make changes or adaptations to the completed project in the future.
Product teams are at their best when:
- They are given a general objective or goal to accomplish.
- There is value in regularly improving the end result.
- The system being developed will be maintained by the company developing it.
All in all, project teams or product teams are both perfectly acceptable. Instead of tying your underpants in knots over which is more agile, select the team formation which works for your situation. Recognize the advantages and disadvantages of both projects and products and most importantly, start delivering value to your customers!
{ 2 comments… read them below or add one }
Great article. We actually have found a synergy between the two that works fairly well. We have Product team the handle the Run-the-Business bug fixes and small enhancements to the product and are ultimately responsible for the product. And when a large, long term project is defined, a project team is spawned to accomplish that task, then the responsibility for maintenance is turned back over to the product team.
(*Chris*)
Excellent point Chris. Sometimes you need two paths on the same product, one for incremental improvements and another to radically alter the system. In that case, a hybrid approach would seem to work well.