I am in a Component team setup now where there are only Front-end teams, Business logic teams, SAP teams etc. where they work separately in different Scrum teams, different Sprints, backlogs etc. There is no single feature team that works across the tech stack.
This essentially seems to lead to a Waterfall approach because the only time we can test a feature or a story is when all the teams have completed their work. There is no vertical splitting but only horizontal splitting of the stories – teams essentially do a bunch of tasks rather than real user stories. This also leads to a big Testing effort at the end of the Release because the Individual teams have not tested the User flows because they are focused on only the individual component. This not only takes a lot of time but also results in finding bugs at the end – basically the Waterfall style.
Even if we build some End-End automated tests, they are not stable because the code changes by the component teams keep breaking some or other thing in the full flow. Some are suggesting API testing to solve this but I am not sure if that alone will be sufficient without testing the User flows.
I wonder if this situation is common to component teams and if there is anything that can be done to improve the situation. In particular, I’d like to kow if a feature team with Front-end developers, backend developers, QAs could more easily solve many of the issues because they will deliver a full User story. Any relevant studies or models that can be used to convince the managemnt to move away from this silo based team structures ?
13
If you have only component teams in your project, you’ll get a compartmentalized design, which makes it very difficult to grasp the picture beyond component.
There is a reason for that: Conway’s law will cause the architecture of the teams to drive the architecture of the system. Moreover, some thinkers found out that:
If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins
– Ruth Malan
To get some cross-component alignment requires several component teams to work closely together and for more complex business processes, to even agree on a shared roadmap. This does not require a waterfall approach. Techniques like Scrum of scrums or Scaled Agile are designed to overcome the team boundaries.
Tests and API alone will not break the spirit of component kingdoms. Only humans caring will do. There are several ways out of this situation:
- Read “Team topologies”, a masterpiece about teams organization, and reorganise your teams structure to have some teams responsible for an end to end flow.
- If big reorgs are not an option, start small and create at least some temporary task forces for new end-to-end features, with key contributors of the teams involved. While teams will still focus on their component delivery, the task forces will help teams to work in concert.
- If this is still not an option, you should at least have a lead team for an end-to-end feature, to actively encourage cooperation.
3