I was familiar with the term synchronized sprint in agile jargon, but until recently, I had not given it much thought.

At my current job, we have three distinct teams within a particular product area. One handles the web and mobile apps, another manages a group of microservices for the backend, and the third is responsible for a stateless service that performs transformation and unification of specific operations.

Several months ago, we received a feature request from one of our clients. This was a cross-functional feature that required implementation by all three teams mentioned above. A general architectural concept was created, and the analysis for each component was completed.

The feature was added to the sprint board of, let’s say, Team 1. Implementation began, and within two weeks, everything appeared to be on track. A couple of weeks later, Team 2 started their part, and again, everything seemed fine.

However, since the priorities among teams differed, the feature wasn’t added to the sprint board of Team 3 (the UI team) until two months later. Development continued. And continued. And continued. Significant inconsistencies in the implementation of the feature across the first two components soon became apparent. Additionally, there were misunderstandings regarding the client’s specific needs in the architectural concept. This led to numerous calls and discussions between teams and the client. Clarifications were made, the feasibility of certain functions was questioned, and changes were required in both the code and the architecture. As of now, the feature is still not fully functional.

What went wrong? Was the original design not meticulously crafted? Perhaps, to some extent. Was there an issue with sprint planning across the different components?

The fact is, we had implemented cross-functional features across teams many times before, but this one was different. It was heavily reliant on UX/UI and required real-world testing of the interaction between users, devices, and our feature. The information we received from the client also needed reassessment and updating to address what could be improved and what turned out to be unrealistic.

A synchronized sprint among the three components for this feature would, in my opinion, have alleviated many of the challenges we faced. Testing should have been conducted incrementally and simultaneously across the three components.

This is one of those cases where the importance of the term “agile”—which may be one of the most overused terms in our industry—should have been given the rigorous attention it deserves. You could argue that careful design of the feature would have led to a successful outcome. To some degree, yes, but keep in mind that certain factors are beyond your control: the client’s communication capabilities, their ability to build a robust, consistent API, and other factors, such as the feature involving real-world devices and user interaction, for which we had limited information without testing.