Finsys Inc. is a software products and services provider in the insurance and financial services space based out of Boston, MA. Product teams in India for Finsys have been working for the international market using Agile/Scrum during the last two years. The product teams have faced some major delivery challenges, struggling to meet release commitments with the required quality. You are hired as an Agile coach to help the teams deal with the challenges, and your first question relates to the current organization structure and the structure of scrum teams. The current structure of Finsys is as follows:
- Engineering teams headed by a development manager for each product line responsible for delivery – there are three such product lines
- Scrum teams (3 to 4) for each of the product lines which are cross-functional
- Test engineers reporting into a separate test organization headed by a test manager – and allocated to each scrum team for the various product lines based on need
- Both development and test engineering report into a Product Engineering Head reporting into the Technology Head who reports into VP of Products Business in the US
- UxD (User Experience Design) engineers as part of a separate organization (outside of Product Engineering) reporting into the Technology Head
- BAs/Product Owners / Managers allocated for each product line under a Product Management Organization reporting into the VP of Products Business in the US
Scrum teams have representatives from UxD and Product Management (both BAs and PO) in addition to the dev and test engineers. The BAs / PO and dev and test engineers are co-located while UxD sits in the same building in India but in a different floor.
While functional requirements are often clear, Scrum teams have a challenge of delivering committed stories in a sprint since UxD invariably does not have final layouts of screens / wireframes at the beginning of sprint. UxD needs to work with POs on this. Dev teams have to give a commitment on the stories at the beginning of the sprint. The screen layouts and wireframes also undergo some changes during a sprint causing an additional challenge in meeting commitments.
As the Agile coach for the team, what would your recommendations be to deal with this situation?
Suggested Solution:
The first challenge relates to the structure of the teams and their reporting. Dual reporting is a necessity with any matrix set-up and obviously comes with related challenges. In a delivery focused set-up, it is necessary for delivery teams to get the required autonomy, with all the functional units providing necessary support for delivery. Ideally it may be a good idea to ensure every product line has their own set of UxD engineers and concerned POs/BAs so there is tighter integration between them and the dev/test engineers in a scrum team. However, there are other challenges such as competence building, career planning for them as well as recruitment and providing replacements when someone leaves, that require the support of a focused functional set-up for each of these functions (such as UxD, Product Management).
So even if we assume the fact that UxD and Product Management belonging to different organizations compared to Engineering cannot be changed, the UxD engineers and the POs/BAs still need to get strongly integrated with the delivery teams (Scrum teams). The UxD and the Product Management heads need to ensure they provide the required support and ensure delivery commitments are not compromised whatsoever. To this end, heads of those organizations are accountable for product delivery to customers. One change I would like to see in this regard that helps integration with delivery teams is co-location of the UxD engineers and the POs/BAs with the dev and test engineers. This in my opinion is mandatory for effective cross functional collaboration. As a coach I would strongly recommend this as the first step for better cross-functional integration.
Now the second challenge relates to story readiness for development and the role UxD and the POs play in this regard. The question is what defines a story as ready for being taken up in a sprint from a UxD perspective? Wireframes/screen layouts often become a necessary input to start work on a story but can the UxD/PO collaborate effectively with dev and test to complete stories in a sprint even if these details are not available at the start of a sprint for every story? With highly mature teams this may be possible, but to start with, it may not be a bad idea to have the UxD and POs working ahead by one sprint on user experience for stories in the upcoming sprint. Regular backlog refinement sessions in the previous sprint with the scrum teams can be used to ensure the user experience design is discussed and refined for getting stories ready for development in an upcoming sprint. This will also minimize need for changes to UxD when stories are getting developed in a sprint.
