Transforming Agile Performance: How I Revitalized an Underperforming Data Engineering Team

In today's fast-paced business environment, underperforming engineering teams can significantly impact business growth. This case study outlines how I helped a global consumer product manufacturer optimize its data engineering team's performance. Within six months, the team's velocity increased fivefold, stakeholder satisfaction soared, and their performance metrics showed consistent improvement.

Client Overview

Our client is a high-end, publicly traded consumer product manufacturer with $1.5 billion in annual sales. They were ready to disband their analytics engineering team due to a long history of underperformance. The business felt the engineering team couldn't get anything done, data quality was questionable, and the team was unable to keep up with business needs. Meanwhile, the engineering team felt they were doing necessary work in supporting the business. I was brought in to evaluate the team and the situation.

Key Challenges

The initial assessment determined there were three major issues that could be addressed without assessing technology usage or the skill level of team members. The team, which proclaimed to be agile and had been using Jira and participating in sprints, was still really working, thinking, and delivering in a waterfall manner. The issues identified were:

• Team structure

• Proper use of Jira

• Agile practices

Solutions and Actions

Team Structure

The original team structure was one monolithic team with one "scrum team" for development and one for QA. The team did not understand the need for change and was resistant to the proposed shift to agile scrum teams or "pods." I spent many hours working with the managers discussing topics like:

• How to build out teams

• How many teams and how many people on each team

• Whether nearshore contractors should be their own team

• Best alignment with the business and what each team should own

• Based on skill level and experience, who was best suited for each team

After much discussion and negotiation, the managers agreed to try the new structure. The two large teams were broken into three agile teams, each aligning to one or two stakeholders. These stakeholders aligned with the business units already supported by the team, with the goal being deeper stakeholder engagement and interaction.

Proper Use of Jira

In reviewing Jira, it became evident each story had a very limited amount of data. The tool was in use, but not in a manner benefiting the team or the business. The biggest issues identified were:

• Stakeholders were not identified on tickets

• It was not apparent who and which business unit owned each ticket

• It was difficult to identify who to go to for clarification on requirements

• Most stories carried across many sprints

• Stories did not have story points

After much discussion and negotiation, the team agreed as a first step to add story points to stories. This one change made the team's work measurable going forward. It didn't change the work performed—instead, it provided visibility to show work was getting done. This change also gave the team the ability to quantify their work. It was a valuable step forward.

Adding story points also enabled measurement of team velocity. This revealed that while work was getting done, it didn't necessarily mean it was the work the business was expecting.

After the initial change, the team then started adding the business owner to tickets. This allowed visibility of the alignment of work to the business and ultimately the initiative driving the work. It also became apparent that the perceived lack of development was in part driven by the high volume of support tickets caused by maintaining a large, complicated database and ETL structure. While the team had repeatedly voiced concerns about the level of support necessary for the legacy system, the addition of story points and story owners gave them the ability to quantify this burden.

Agile Practices

The team needed direction in agile practices. The original structure—one developer group and one QA group—had not lent itself to good agile practices. There were internal demos but not external ones. The manager oversaw assigning work person by person and story by story, creating a large bottleneck. Often team members were not sure which story to pick up next or what work they should be performing. There was also very little interaction between business stakeholders and the team about work intake, priorities, and goals.

I conducted trainings in a lunch-and-learn fashion covering:

• Proper use of Jira

• Agile ceremonies

• Sprint demos

• Story creation

• Story refinement

As the teams matured, I continued to promote increased stakeholder engagement and communication. Within months, there were demos for the business. The teams started getting support from stakeholders and increased engagement on priorities. The business began to see real work getting done and even became complimentary of the teams.

Measuring the Impact

Story points were implemented in November 2023. The team size did not change, and at the time of this writing, the team was actually down one very senior developer and a data architect. Despite this, the three pods saw month-over-month increases in points completed. Six months into the change, the team's velocity had increased five times.

The one change of adding story points allowed the development managers to quantify results in a way the business could see and understand. This measurement also meant the team could prove work was being done—the start of their ability to become predictable and sustainable.

The agile teams all started meeting with their stakeholders on priorities and requirements. These meetings improved interactions and communication between development and business. Stakeholders now attend sprint demos and have started communicating a more positive view of the team. One stakeholder reached out to the engineering director with positive feedback about productivity and quality—a full 180-degree turn from six months prior.

Ticket quality improved dramatically:

• Owners on tickets increased from 20% to 80% populated

• Story points are now on almost 100% of tickets

• Stakeholder identification went from 10% to 50% populated

All metrics are trending positively.

Summary and Lessons Learned

This engagement demonstrated that significant improvement in an agile team is possible without technical overhauls. Not all changes have to be technical in nature. By coaching the team to align more closely with agile practices, I dramatically improved tracking, communication, and structure. Small steps forward made great leaps for the team. All metrics are trending positively, and the team now has a stable base to start addressing more technical and complicated issues.

Key Takeaway: Sometimes the path to high performance isn't new technology—it's helping teams work better with what they already have.