Two of the many ways Agile differs from traditional organisation is that Agile teams are a) often not only permanent (rather than project-based) but also b) dedicated to a single product.
In this context, ‘product’ may mean:
- A service or commodity (commercial or otherwise).
- An internal function or service.
- An internal application, architecture or system.
- A support queue.
Although they operate project-like releases and iterations, Agile teams are often most effective when dedicated to a single product. Conversely, product management is often at its sharpest with a dedicated team, because having a dedicated team allows them to build up hands-on mastery of all elements of the entire product cycle:
- Constant interaction with the product’s direct users and, though them (or perhaps even directly) the ultimate beneficiaries.
- Detailed technical knowledge of the systems, data & environments in which they work.
- Broad & deep domain experience of the products, business, organisation & functions the product serves.
- Strong, mutually supportive relationships with any other functions, groups and stakeholders involved in delivering real success.
And all this is built into a single permanent team, not scattered across the typical multi-silo arrangement prevailing in a typical project- and programme-based development.
This in turn will:
- Ensure that the team is constantly aware of – and focused on – outcomes (i.e., benefits realised), rather than indirect measures of success such as stories completed or even outputs.
- Allow instant adaptation to user feedback, field experience, sudden markets shifts, competitors’ moves, business opportunities, and so on.
- All without the elaborate mechanisms of defining, funding and setting up a new project each time.
- Improve the team’s knowledge retention, both as individuals & collectively.
- Regular interactions also mean that knowledge is actively propagated across the group, not limited to in individuals.
- So the team’s knowledge and expertise grow dynamically & multiplicatively.
- This in turn will feed back and forward to other groups – even temporary ones (e.g., project teams).
- Allow the team to propose its own ideas for the product, based on increasingly detailed, in-depth knowledge.
- Bind the team much more closely and dynamically to the line of business they support.
- Accelerate and enrich development, improve flow and increase the team’s productivity and time to market.
- Eliminate much waste & rework.
- Smooth out many of the gaps and conflicts that delay development when teams are assembled for individual projects & then disbanded when the project is over.
- Increase product adaptability.
The relationship between team and product may not be exactly one-to-one:
- A single team may support multiple (often related) products.
- A large, complex product may have several dedicated product teams, each supporting a different aspect of the product.
But whatever its responsibilities and scope, a Product Team can is an enduring component of the organisation – often lasting several years – and unlike other ‘investments’, the older it gets, the more efficient, effective and downright valuable it becomes.
It’s essential to recognise, though, that Product Teams are more than just another way of doing projects. The factors affecting their ability to do their job are as broad as the product itself. So to make the most of the Product Team model, other conditions need to be met:
- The Product Team needs to be run on strictly Agile lines.
- This is probably the only model that truly supports all these benefits.
- Anything less will hobble it to the point of instantly eliminating half the Product Team’s potential value.
- It helps greatly if the product the Product Team are working on is structured so that the team controls as much as possible at every level – not just IT. To achieve this, the product needs a clear space and boundaries within the overall enterprise architecture and product roadmap.
- At the same time, the team needs:
- An unambiguous position within the organisation, including clear lines to a unique authority operating high in the organisation as a whole.
- Well-defined and unobstructed links to its own work pipeline (i.e., not complicated by formal investment and work allocation cycles).
- Clear & unambiguous relationships with all the other functions & groups needed to deliver success for this product.
- Sharing as few as possible of the organisation’s wider business processes with other products and projects.
- Control over clearly delineated elements of the underlying systems and operating data, including systems integration and deployment.
- Assured rapid access to a wider Extended Team of experts and authorities, so ensuring that areas such as changes to business procedure, training and so on do not become bottlenecks in the delivery process.
- Autonomous recruitment processes.
And so on. Building successful Product Teams doesn’t require absolutely all of these factors to be in place – but if you can realise them, success will follow much more easily.