How Nisum activated a cultural shift to break down the silos and build a partnership between the Product Owner and the Engineering teams using Agile.
Business Challenge
A Fortune 500 eCommerce retailer had made significant strides in transitioning from Waterfall methodology to Agile (Lean, Scrum, Kanban). They formed “scrum teams” that had implemented the Scrum meeting structure, set up Agile reporting metrics within JIRA, and reduced their team sizes to 5-9 members. While several people in leadership thought they were nearly complete in their transition to Agile, others disagreed pointing out that the company had several more stages before deriving all potential benefits of an Agile transformation.
In addition, the IT department was facing personnel and political challenges as a result of a new IT VP, upcoming reorganization, and overhaul of their Product Management and middle management leadership structure. There was uncertainty around ownership and responsibilities, there were different levels of understanding of the products, and there was an inconsistency in adhering to Agile practices.
Our Approach
One of Nisum’s Agile experts consulted with the Client stakeholders, development teams, and leadership to understand the challenges of their current processes and the thought processes behind the decision-making that led them there. They quickly discovered that the feedback loops between business and engineering were insufficient. They were Agile in name, but they were not maximizing their benefits.
One area in which the company was already successful was that the Product Owner saw value in business analysis and Agile reporting. This left them with metrics that were up to industry standard and were highly valued by leadership. They researched extensively what users at their retail stores and warehouses wanted, and they understood the need for true benefit analysis.
Additionally, the engineering teams were proficient as true subject matter experts (SME’s), with a deep understanding of the Client’s complex systems in an ever-evolving enterprise ecosystem. The engineers were a very efficient team, working collaboratively to deliver the best possible product.
Despite this, silos were pretty extensive. There was little buy-in from the Product Owner on frequent check-ins and with communication between engineering and leadership, a less easily understood strategic piece of gaining the benefit of an Agile approach to development. The Product Owner did not see how this contributed to rising costs and diminished value. Contributing to this, leadership was spread thin during the reorganization transition phase, leaving the Product Owner often wanting engineering teams to get started on features without a full understanding of the scope and criteria to get there. As a result, the Product Owner was often non-communicative and unavailable for story requirements clarification or acceptance criteria, much less day-to-day product direction, and simultaneously, the engineering teams were unclear of the scope and success criteria of the stories and ultimately refused to work on these features. The teams were concerned they would be blamed for the lack of quality when they felt they were set up to fail from the beginning. They were at a standstill and miscommunication was plentiful.
Our Solution
Nisum rightfully assessed that there was a need for a cultural shift – to break down the silos and build a partnership between the Product Owner and the Engineering teams. They did not trust each other and were accustomed to a hands-off, directive type of approach instead of the collaborative, fluid, and expedient nature associated with the Agile framework.
The first approach was to individually educate the Product Owner and the Engineering teams on how they could work together, what Scrum looked like for them, and what benefits they could expect for themselves, the team, and the company. This was only semi-successful. The engineering teams were encouraged by the prospect of better feedback loops and they agreed to move forward if there was better input from the Product Owner. The Product Owner was concerned this would add responsibility to their very full plate, and they did not believe it was where they should spend their time.
Realizing that this needed to be escalated, Nisum then pursued a threefold approach: 1) build alliances with influential people at different intersection points in the company, and 2) use this to create buy-in by explaining the disconnect in communication and a need to re-establish expectations for the workload and responsibilities of the Product Owner, and 3) establish agreements among all parties involved on what this means moving forward strategically.
Tools & Technologies
Building alliances proved to be the key to the success of this initiative. Meeting individually with leadership at different levels, including the Domain Stakeholders and IT Director, Nisum was able to sell the stakeholders and leadership on the current problem, including the cascading impact on the productivity of the engineering teams and the negative results they were garnering. Once they understood, they agreed to use their influence to improve the situation.
From there, Nisum facilitated alignment and created consensus on a working agreement among all parties, including the Domain Stakeholders, IT Director, Product Owner, and Engineering Teams. They synthesized the needs expressed by all parties and formed a new set of expectations regarding story sign-offs, role responsibilities, and check-in cadence.
As an output of these discussions, a user story template was created, outlining a series of questions that focused on future collaboration between the business and engineering teams. This minimized the one-off questions that derailed the Product Owner while giving enough scope and acceptance criteria to the teams to assure them they were on the right track. The workload pressure for the Product Owner was also relieved as a direct result of these discussions.
Client Value
Through all these efforts, Nisum was able to bring tremendous value to the teams and this project. The engineering teams were at a disappointing 0% productivity on these features and were refusing to move forward. The distrust among all parties was high and the Product Owner was frustrated they were not getting the products requested. Leadership was concerned about the rising costs and all parties were talking without communicating.
Through the use of the techniques mentioned above, the situation improved dramatically. Almost immediately, the teams and Product Owner established a new structure to unblock the team, returning to their original productivity and thereby minimizing what could have been a significant hit to the project timelines and budget. Additionally, the Product Owner benefited from what was ultimately a reduced workload, gaining visibility into their individual circumstances, and ultimately there were elements of reassurance to leadership that the costs are more directly tied to the future product value. Through the use of frequent feedback loops between business and engineering, the parties were able to eliminate wasted time and increase occurrences of usable, valuable functionality.
Intangible benefits include a more collaborative team dynamic, bridging the gap between previously siloed groups. Trust gradually increased as they learned and experienced the new processes benefiting everyone, and as a result, morale increased as well.
All of this translated into improved value and quality of the features developed while respecting the time and needs of all parties involved.
