Intended audience: Scrum masters, Product owners, Managers and Agile coaches.
I was working with various groups over the last year and noticed some commonalities in the problems they faced. In this blog I want to share some common collaboration problems and solutions I experimented with.
1. Lack of product focus
The lack of product focus is related to a series of underlying product related problems. Firstly, there is often no clearly formulated vision, or a missing plan on how to achieve a vision. The PO’s are then unsure what needs to be developed. Secondly, there usually are too many PO’s having difficulties to align. People then volunteer to fix these problems. For instance, a lead developer or architect prepares the work for sprints ahead, acting as a proxy between the teams and the PO’s, splitting the requirements in tasks per team. Thirdly, I see multiple over-complex jira-backlogs and lastly there is lots of non-product related work on these backlogs.
I advise to start finding one person to be the single Product Owner for all teams. The other “fake PO’s” should be moved inside the development teams as subject matter experts so they can provide detailed requirements. I avoid having the “we are all dev-team members” discussion and let them keep their business title such as “Product Manager”. The Product Owner should develop an inspiring vision and a plan to make it happen. This plan needs to be communicated to the teams by the PO. Consolidate the work into one single Product Backlog with a view for each team. Aim at a visual representation of the work on an office wall representing the single source of truth.
A single source of truth
2. No Release management
Delivering working software is perceived as an IT responsibility instead of a Business-IT collaboration. Many teams are component teams and planning and managing releases with component teams is hard. The content of the release is not understood by the business, and there is an atmosphere of continuous disappointment. To get more grip on delivering value predictably, I advise to first move the focus from component-, towards customer-centric features. This is not a big problem if your teams are end to end capable, but have component responsibility. It takes a couple of iterations for Business and IT to collaborate on defining properly sliced features and to optimise the sizing of a releasable feature. I was successful with optimising for feature size that could be delivered in a two-sprint cadence. The features need to be split and made smaller until the group thinks they can be delivered in two sprints. This approach is ideal to get a cadence from the influx of new features to done, closing the empirical process control loop from design to delivery.
Be very strict on the administration of releases (in Jira) creating a 100% transparency on which items are in or not in a specific release. Ensure Product Owner(s) see the relevance of monitoring the scope and progress. This provides a simple cross-team progress monitor.
3. Poor collaboration between business and IT
In many organisations, there is a very thick invisible wall between Business and IT. I’m sure you have “seen” it before (lol). Two worlds that do not speak the same language and do not communicate at a constructive level. The Business sees IT as an necessary evil where simple ideas become difficult and expensive. Business strategy to mitigate development cost often is many months of preparation with UX before handing off the designs to the IT teams. The waterfall smell is everywhere. The IT teams are not involved in the exploratory phases at all for obvious (business) reasons. Hence, they feel excluded because a solution is thrown over the wall onto their desk. IT people have a hard time accepting designs containing impossible combinations of data and illogical flows, so they start (angrily) asking critical questions. A stance that is answered by the Business people with irritation and disbelief. My approach here is placing the UX-ers visible at desks close to the teams, make the “fake” Product Owners members of the development teams and involve everyone in ideation. Connect the dots by making reporting on market research data and customer feedback data a mandatory item of the Sprint Review.
4. Component ownership
I see many groups building and supporting components in dev-ops teams. Teams inherit support responsibility for “old” components and dev-ops is “the way to go”. However, it creates work on the backlog that is not related to the new product initiative and slows the teams down. The solution is to transfer all work that is not directly contributing to the new product increment to a team outside the product group. Interestingly, I experienced that this intervention initiated a new discussion about decoupling teams and components for operational responsibilities and moving ops-responsibility to group level, making everybody responsible for all components. The underlying conflict was that the teams were not willing to provide operational support on each other’s code, because there was no common coding standard and agreed DoD at group level. This dynamic is very common for component teams.
To create better cross-team collaboration, create a common minimal DoD. Also have each team define their team norms of conduct and organise a workshop to create cross-team working agreements. Stop working in feature branches and work directly on master. This will open up all code for all developers to understand and change. This requires the teams to be prepared to collaborate and to agree on standards. I can recommend to approach the lack of coding standards via the concept of “damage control”: For teams to first protect “their” code, “foreign” code changes were monitored by each team. The teams all created a list of emerging technical debt on their component. These were changes on “their” code that was not in line with “their” (unwritten) coding standard. Note that the list of technical debt is the exact opposite of coding standards. After each sprint, the technical debt issues were discussed among the teams which resulted in an emerging common coding standard.
5. Unsuitable communication practices
Last but not least, watch out for delegated meeting cultures. Delegated meetings is a practice which is based on the assumption that it is more efficient to send a delegate to meetings instead of having the full team participating. This practice is used to fight the “too many meetings problem”. However, this communication structure has downsides. It requires to bring the information back to the teams, which either does not happen or happens but the information is filtered or (mis)interpreted. This is not a helpful practice because it requires good participant scheduling, is time consuming, causes information scatter, lowers productivity and creates misalignment.
On the other hand, killing meetings is hard to do. The belief is that meetings are there for a reason. I start with challenging the teams to try to improve non-valuable meetings, and ultimately stop attending them if that did not work. By consequence non-Scrum meetings will die out. In parallel make everybody in the group participate in the majority of the valuable meetings, rather than having sub-meetings with delegates. Also create more suitable alternatives for “bad” meetings rather than killing them. For example, a top-down driven architectural meeting will lose its value in favour of multi-team design sessions during refinement. In the refinements, the lead architect will serve as subject matter expert to advise the teams. Note that good facilitation techniques (diverge/merge and the likes) are a required Scrum Master skill to handle sessions with larger groups.
our 2-sprint meeting flow
When you want to improve the collaboration between multiple scrum teams, you will benefit from verifying the performance of these areas:
- Product focus: is there one Product Owner and do we know where we are heading for?
- Delivery abilities: do we know when we will reach or next goal?
- Business-it alignment: do we all speak the same language and serve the same goal?
- Team responsibilities: are the teams setup to do what we expect them to do?
- Communication practices: does the way we communicate support our goal?
If you would like to hear more details or learn about other Scrum-related issues, contact me or join my upcoming PSM-II class.