Top Tips for Aligning Teams Around Products

Forming multi-skilled product aligned teams

One of the biggest implementation challenges being faced is, why do you group individuals aligned around a product, service or customer journey? We have found that many IT professionals don’t naturally think in terms of customers or the products and services offered to them. Leaders should be encouraged to identify the end customer and the product that is being offered to them. Once encouraged to think this way, teams get closer to the customer quicker and begin to understand the value of delivering great features and quality products.

We have observed that teams may not understand who the true customer is, let alone interact with them. It is not unusual to see seven roles or layers between the product owner and customer. It is vital to foster closer relationships with the end customer and this can be achieved by:

• Introducing 'Back to the Floor' type initiatives, where product owners, marketers and designers spend time with the end customer.
• Customers attending sprint planning, and show and tells.
• Employing 'Hot Houses' to quickly bring together the customer and product team to rapidly deliver a minimum viable product (MVP) for iteration outside this type of environment.

Incorporating specialist roles into product teams 

Within most organisations, it's common to find technical resource pools, which can lead to capacity issues. Take database administration teams, for example, the resource is already scarce and there may be concerns that distributing these highly specialised people into product teams, or when introducing DevOps, will only make the problem worse. The overall aim when distributing specialist resources is to achieve the optimum balance between specialist skills, domain knowledge and automation: this ensures a truly cross functional team. The problem needs to be addressed in a number of ways:

• Aligning individuals to a primary product team, where majority of their time will be utilised effectively and aligning to a secondary product team with less demand for that skill.
• Prioritisation, traceability of work and dependency management are key enablers in making this work, which is best supported by using a dynamic prioritisation list (DPL). This avoids the need to create liaison or project admin roles and unnecessary bureaucracy.
• Product teams are meant to be cross-functional and multi-skilled, so leaders need to rapidly address skills scarcity and help create "E - shaped" people.
• Gradual transition helps embed support engineers into product or DevOps teams, learning their role as an DevOps engineer through rotation in the team.
• Automation helps address scarcity, reducing dependency on resources and freeing them up from repetitive and manual tasks.
• Always distribute architecture and security through the product teams.
• SMEs can be in short supply and are often in high demand, leading to delays in decision making. To avoid this, schedule SMEs to always be on the highest value work and encourage them to continually codify their knowledge, helping to reduce over-reliance and increase accessibility for others.

Handling segregation of duties

Many of our clients are subject to strict regulation and we have heard from many different teams that segregation of duties prevents product teams being able to do both Development and Operations – clearly a fundamental blocker for true DevOps working!

To avoid this, we recommend:

• - A very clear policy statement is required, quite often urban myth is quoted as a reason why DevOps principles cant be applied.  A clear statement will let teams know exactly how much flexibility is possible when implementing true DevOps practices.
• - These can be enforced and validated in the CD pipeline using the 'four eyes' principle.

Project managers and Agile (team) leads

In our experience, there is often the assumption that existing project managers will be natural candidates for Agile leads in new product teams; this should be carefully tested. The best Agile leads tend to be engineers with recent hands-on experience of development and strong domain knowledge. Traditional project management skills have only partial relevance to working in an Agile/DevOps way.

To ensure strong leadership we recommend:

• Product owners combining the technical lead and Agile lead roles, if the value of appointing a specific individual to be Agile lead is not recognised
• An Agile lead having the necessary Agile, DevOps and engineering skills and experience to undertake the role effectively
• People in product teams should not normally report (functionally) to an Agile lead but rather to the technical lead. 

What if it's not working?

If adoption problems exist, product teams should be coached in continuous improvement activities and encouraged to:

• Identify bottlenecks and waste, which are frequently found in the form of rework and sometimes unnecessary work
• Analyse and change the organisation to minimise handoffs
• Invest in automation to avoid repetitive tasks and reduce human error
• Share information to eliminate knowledge bottlenecks
• Re-validate current plans in that context
• Establish 'Communities of Practice' for knowledge sharing and to create a culture of continuous learning

Being overly focussed on organisation design can sometimes lead to analysis paralysis. It is much better to recognise the true end-state could be many years ahead. When creating the product team ensure you listen to feedback from the individuals likely to be impacted, don't just do a paper exercise of moving people into new organisational structures. The teams on the ground know what skills and resources they need in their product teams, they know the issues they face and will have good ideas on how to address them, the key aim is to maximise the flow of valuable work into the team. 

To make sure you're on the right track, you should:

• Ensure that when a product team is created, it is as cross-functional as possible, it is created for the long term, and has a clear and meaningful scope, even if starting from a compromise position
• Force the issue early and remove the separation between design, development and testing teams completely, while noting that the roles can remain separate in certain circumstances
• Accept that you will not define the perfect product team structure first time around. Once you feel your design is "good enough", implement it, but observe the results closely, and expect to tweak your designs regularly in the coming months.

When creating the product team ensure you listen to feedback from the individuals likely to be impacted, don't just do a paper exercise of moving people into new organisational structures. The teams on the ground know what skills and resources they need in their product teams, they know the issues they face and will have good ideas on how to address them; the key aim is to maximise the flow of valuable work into the team.