Teams' topography not aligned to product-oriented development
Dear all,
I have recently joined a group of 5 Teams as an Agile Coach. All the Teams operate as per Scrum with 3 different lines of Products being developed. All the 5 Teams use their own Product & Sprint Backlogs to work with. However, I noticed something problematic once I joined the setup - the Teams are structured as per the technology-stacks that they support; 2 AWS Teams, 2 Salesforce CRM Teams & 1 Mulesoft Team. This leads to hand-offs happening between the Teams (one team handing off their piece to another to start with), resulting in no functionally-shippable (potentially)increments delivered at the end of a Sprint.
When I tried having discussions with the Teams regarding this and suggested why can't they structure their Teams as per the lines of Products that they deliver, instead of assembling by the tech-stacks, they resisted saying the Teams are staffed by their own Technology Units and they're happy & content, being the Specialists in their own area, & don't want to change the way the Teams are structured.
However, I can clearly see the delays its causing to the delivery of end to end pieces of functionalities because of several handoffs.
Any ideas or suggestion as to how do I convince the Teams to structure them in a better way, so they can deliver potentially shippable increments at the end of every Sprint? As self-managing & self-organizing entities, I don't want to interfere much in how they group themselves up, so can't force them to take any decision, but I can see the challenges because of this setup. The Teams are now willing to regroup as their motivations lie somewhere else (in being the specialists in their own Units and earn good appraisal ratings for themselves).
Any ideas or suggestion as to how do I convince the Teams to structure them in a better way, so they can deliver potentially shippable increments at the end of every Sprint?
Should you? You're an agile coach and it's probably a great idea, but is it your company to change?
Why are the higher-ups, whose company it is, not convincing people of the urgency for change? If they're too busy doing the same-old-same-old, that's precisely the message and priority they will surely end up communicating to others.
It's important to recognize that these teams are not operating "as per Scrum". A Scrum Team must "have all the skills necessary to create value each Sprint". Although these teams may be able to get tasks done, they can't consistently deliver stakeholder value. Using Scrum terms for roles, responsibilities, events, and artifacts doesn't mean that the team is using Scrum, and that will likely lead to confusion if people assume that you are using Scrum and expect other aspects to hold true.
If you do want to change, you'll need to find someone to champion the change and convince them. Depending on who you need to convince, you can find various arguments. For example, people with T-shaped or comb-shaped skills are often "better" because they promote communication, learning, and problem-solving. Handoffs (between individuals or teams) are considered waste and often decrease throughput and increase the time it takes to deliver work.
Sometimes, the change may be top-down. It may be a better approach to convince senior leadership that a new approach to working is somehow better for the business. Other times, the change may be bottom-up and it would be better to convince the people on the teams that there are advantages for adopting a new way of working. In some cases, it needs to be an individual argument to explain to individuals why it's better for them as a person, while in others it needs to be about the team.
You're the one in the environment, so only you can assess which approach (or perhaps multiple approaches) would be the most beneficial to drive change. Otherwise, all you can do is continue to highlight problems and ways where changes can be made to reduce those problems.
Hi,
I agree with the points mentioned by Thomas and Ian. You should speak to the department heads and point out the issues you see i.e. the antipatterns you see in the current way of working. Request them to give you a feature-based team (having all the cross functional skills required to deliver value in each sprint) for one Product line and show them through results how the new way of working you propose will help everyone. There will be resistance within the team initially and you will go through the Tuckman's team development steps. But once the team sees value and find that shared sense of accountability they will agree with the new way of working. Once a success is showcased others will also join in and adopt the new way of working.
Perhaps you could create a Value Stream Map to make the wait times and the impact on flow transparent due to dependencies and hand-offs. Highlighting cycle time may be another avenue.
Thanks a lot for the valuable comments & suggestions and your guidance, worthy of pursuing!