In the final session of the day, I chose to attend “By Our Powers Combined! Cross Team Collaboration Around Central Initiatives” led by William Kammersell. William is a product owner at CA Technologies.
He explained some of the elements in his product development around bigger product initiatives which weren’t working well, using the SAFe framework and the common roles (PO, PM, UX, Architects etc.). His team would have a quarterly planning meeting to kick off the quarter, with a number of activities happening afterwards per the calendar below. Of course, they are continuously developing while they are planning, and engaged in cross team collaboration at several key steps in the journey.
Similar to other definitions I’ve heard, according to William, POs work with the team, are on the stand ups and are the voice of the team and of the customer. The PM (product manager) is coming up with a higher level roadmap, doing exploratory research, and focus on what the problem is. They are leaning towards having a shorter roadmap so they have more time to change, and have a feature and a technical roadmap.
The challenge for the team after getting the high-level roadmap from the product manager is that the to-do list is literally everything at the beginning of the planning. This created some anxiety and also morale problems.
One specific factor that his team decided to focus on was wait time. The wait time for something to go through the system depends on the length of the queue and throughput of the items (W=L/T). One of the strategies his team took to tackle the issues on large features was to shrink the length of the queue by breaking things down more granularly, which also helped increase throughput. They started at Initiatives, which decomposed in to features, which breaks down in stories which flow in to the team.
On a Release train during cross team collaboratoion, there would be multiple initiatives, with multiple teams assigned to each initiative. Initiative teams led by product managers would often do their own planning. The composition of the development teams including the product owner was pretty consistent quarter to quarter, and they purposely tried to keep teams together. Team changes led to churn, inconsistency, and unpredictability due to having to move through Storming, Norming, and Conforming again before reaching Performing. That said, developers were allowed to move to different teams or initiatives based on passion or career growth. A scrum master would have 2-3 teams. Team sizes are typically 4-8 developers, 1 QA, 1 product owner.
PMs and POs are separate but equal tracks that have separate directors but report to the same VP. Product managers come in more at the beginning of the planning cycle quarterly and elevating the “why”, and Product Owners take more of the responsibility of the middle, which is the “how”.
William then led us through a working example on Swarms and getting people together around an idea to brainstorm or build something quickly. We broke up in to groups and built pipe-cleaner animals in 5 minutes. Our group was assigned a lion.
Some lessons learned from William’s implementation of cross team collaboration swarming on an initiatives at CA Technologies:
- Extensive cross-team collaboration led to cumbersome refactoring (more stepping on toes).
- Focus needed more focus
- Over-featured products got created
- Some people liked it, some didn’t
- Too many teams working on an initiative. Best to cluster by geography.
- Switch lead devs occasionally to upskill and break down siloed knowledge
- Smaller teams are needed
- Prioritizing work an ongoing challenge during cross team collaboration
- Identified specific teams that knew they would have a lot of dependencies, and had them focus on this
- Allowed for daily releases at 2PM
William likes to run things at least 3 times before changing generally. After 3 quarters of running a concept through his cross team collaboration initiative, they refined the process based on feedback (NPS based on team surveys). Generally, they were very happy with this cross team collaboration process and they solved the problem of big features taking too long and being too complicated to build.
Even though this was the final session for the day, the Travelport team stayed on networking and hanging out.
Fun and inspiring day!