The Product Forum is a team-of-teams structure that co-ordinates integration of a Product or Product family.The Product Forum is a self-organizing, often democratic, group that balances competing voices and concerns, owns high level Requirements and Architecture, runs the high level release stream and performing integration activities for the product.
Rather than impose a hierarchy of decision making from a Programme or Project Manager downwards, the Product Forum is a “middle-out” virtual team in the middle of all stakeholders balancing concerns of Product Customers, Business Customers and Business Leadership with Programme and Project Delivery teams. An alternative management structure for cross team working (or managing a large/complex team) the Product Forum can be thought of as an agile alternative to traditional Programme Management.
- In situations where multiple competing stakeholder groups with different agendas are required to work together
- In situations where multiple product groups need to collaborate on a bigger outcome
- Where there is a conflict in direction, resource management/ownership or scope between collaborating groups
- System of systems development
- High complexity development where the solutions is very unpredictable
Sitting in the middle of the H-Model the Product Forum is the connective tissue between high level scoping requirements, architectural context, integration, releases, management and acceptance.
The Product Forum is a virtual team formed from representatives of contributing teams and stakeholders related to a piece of work. The specific composition of a Product Forum will alter over time, and for each activity meeting, as different decisions are made.
As a virtual team the Product Forum uses the Team Forming practice to establish its purpose and decision making dynamics (ranging from autocratic to democratic).
Membership of the Product Forum includes Customer and User representation, contributing resource groups, technical and people management, enterprise analysts and architects. To be most effective it needs to have the least possible number of people actively contributing (a forum of 40 competing voices is going to have a lot of difficulties) however there are certain positions that must be filled.
A good rule of thumb is that, for a large project, the forum should be around 7 to 15 people, if 30 want to turn up then half of them should be on an observational gallery unable to interject in the proceedings. The people who should come can be thought of in the following ways:
- Facilitator (like the speaker in a political context best if it’s someone independent from the project)
- Customer Representatives (2 or 3)
- Resource Management and Technical leadership from each contributing group (2 each)
- Architect – the person or people responsible for guiding the overall system or solution architecture.
People can be elected by their groups to the forum, membership could be rotated, the organization could appoint membership or the least busy from each group could attend. We suggest that the last two are not good options for selecting membership if good decisions are to be made! Of course, depending on the agenda of the Product Forum, different representatives may attend. Presence can be physical or virtual however the best decisions and communications occur when people are physically present.
Avoid filling a Product Forum with “managers” and “talkers” – instead it should be full of “doers” and “deciders”. Use of the Product Forum practice does not prevent any communication directly between contributing groups, it only provides a vehicle for that conversation when it’s relevant for the wider project.
Since a Product Forum co-ordinates work and/or multiple teams it performs similar functions to a traditional programme team. The forum works to de-conflict sources of disagreement before they occur and relies on open and honest communication across the following functions:
- Seizes its autonomy and self-organizes its internal structure – often articulated through a team charter
- Communicates, both internally and externally, radiating information and being open and honest about progress and impediments
- Provides a vehicle for knowledge sharing and conflict resolution by bringing people together
- Stakeholder and Relationship management
- Communicating its decisions
- Acts as a Bubble Up target for contributing teams
Project Integration and Release
- Actually does the Product Level integration and test activity against Integration Scenarios raising the level of done of the product as a whole
- Combining the output of contributing team’s integration and test activities into a larger product by performing cross-team integration and test activity against Integration Scenarios raising the “level of done” of the product as a whole
- Manages acceptance testing and drives acceptance test driven development
- Exposes Releases to higher level integration streams or user environments
Decision Making Processes
- Understands the decisions it needs to make and makes them autocratically or democratically as appropriate
- Defines the direction of the project in a planning, architectural and cultural context
- Ensures System Architectural choices align to Solution Architecture and Enterprise Architecture
- Manages scope (using Integration Scenarios and change management practices)
- Does release planning and elaborates Solution Architecture
- Resource profiling for the work as a whole enabling resource management between the Product Forum and contributing groups