Review of Learning Part 2: Product Teams

Post date: Oct 16, 2014 10:9:0 AM

Product Teams | Small, Stable, Co-located

If organising work by product (or service) is the appropriate approach for specialist individuals involved with software delivery, how do we go about structuring that Product team?

Much of this depends upon the value a business is looking to achieve, and this influences which specialists are needed, to accomplish the work required. In my opinion there are some fundamental aspects which we need to be cognisant of, when structuring a Product team.

Small

Brooks (1975) law states that adding manpower to a late software project makes it later. This is based on the premise that people take time to become productive within a team, and that communication overheads increase as the number of people in a team increases. To address this I would advocate starting with the smallest team possible, and only adding to it as the work required emerges and becomes clearer. Although this approach will have an impact on the group’s development, it is my opinion that it is better to start with a small core team and pull in the skills required as the work emerges and the needs of the group are identified.

Group Development

As Tuckman (1977) observed people within teams progress through four stages of group development: Forming, Storming, Norming and Performing. When a group is first formed, individuals come together under the banner of a shared purpose. People are initially hesitant, stand-offish and often not clear on what their role in the group is and what’s required of them.

With a more typical work by major function organisational structure, a significant part of any project’s setup and life-cycle can be concerned with first identifying the relevant individuals, and then having them progress through to the Performing stage of group development. When individuals are not closely collaborating, this group development is hindered.

Co-located

Often individuals are based across different locations within the office, or perhaps geographically distributed across different offices around the country or even the world. Having individuals who are distributed across locations makes progressing through the stages of group development harder, and can take longer.

Teasley et al (2000) observed through their study of six teams operating in a war room environment; having the entire project team in one room for the duration of a project, resulted in producing remarkable productivity improvements for the teams involved.

I advocate starting with as many individuals as possible being co-located in a single location and sat together working as a team. This will help them progress faster through the stages of group development. I would also add that once mature, this team can still perform well when working remotely perhaps in a more virtual team setup, but this can only happen effectively after the team has progressed past the forming and storming stages.

Reduce Waiting

Ohno (1988) observed that within the time line, from the moment a customer places an order, to the point where the customer receives the order, and cash is collected, there are value-added steps and non-value-added steps that can be observed. He suggests there are seven major types of non-value adding wastes within a business process; put simply one can reduce the process time line by removing the non-value-added wastes. One of the Wastes Ohno identified is Waiting, typically during the handover from the previous to the next process step.

Identifying and reducing the causes of waiting within a team and their processes is a continuous activity. Although we can approach the structure of our product team with the aim of limiting the amount of handover and, therefore, the waiting time between new feature request or concept hypothesis, through to the point where that concept hypothesis or feature can be tested or used by the intended customer.

Key points:

• Start with the smallest team possible, and grow.

• Try to keep the team stable for the lifetime of the Product

• Co-locate people where possible, to reduce communication overhead

• Reduce waiting time in handover between process steps

References

Brooks Jr, F. P. (1995). The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering. Pearson Education.

Tuckman, B. W., & Jensen, M. A. C. (1977). Stages of small-group development revisited. Group & Organization Management,

Teasley, S., Covi, L., Krishnan, M. S., & Olson, J. S. (2000). How does radical collocation help a team succeed?. In Proceedings of the 2000 ACM conference on Computer supported cooperative work.

Ohno, T. (1988) Toyota Production System, Productivity Press