In today’s fast-paced business environment, underperforming engineering teams can impact business growth.
This case study outlines how K&B 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.
Speak with a data expert
Background
Our client is a high-end, publicly traded, consumer product manufacturer with 1.5 billion in sales annually. They were ready to disband the analytics engineering team as the team had a long history of underperforming. The business felt the data engineering team couldn’t get anything done, data quality was questionable, and the team was unable to keep up with the needs of the business. The engineering team felt they were doing necessary work in supporting the business. K&B was brought in to evaluate the team and the situation.
Key Challenges
The initial assessment determined there were three major issues which could be addressed without assessing technology usage or the skill level of the team members. The team which proclaimed to be agile, had been using Jira, and participating in sprints was still really working, thinking and delivering in a waterfall manor.
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 were resistant to the proposed change to agile scrum teams or ‘pods’. We spent many hours working with the managers discussing topics like:
- How to build out teams
- How many teams
- How many people on each team
- Should the nearshore contractors 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 3 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 in Jira 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
- The stories did not have story points.
Again, after much discussion and negotiation, the team agreed as a first step to add story points to the 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 provided the team with the ability to quantify their work in some fashion. It was a valuable step forward. Adding story points also enabled measurement of the velocity of the team. This exemplified while work was getting done, it didn’t necessarily mean it was the work the business was expecting.
After the initial change of story points the team then started adding the business owner to the tickets. This change allowed visibility of the alignment of the work to the business and ultimately the initiative driving the work. In this part of the assessment, it 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 the team the ability to quantify the large amount of support necessary for the legacy system.
The final issue of carrying stories across sprints leads into the lack of attention to agile practices. Procedural and agile practices are a longer challenge to tackle. The change of the team’s structure from two large waterfall focused teams to three agile sprint teams improved the closure rate of tickets in a sprint to a small degree. Addressing the agile practices (details below) within these new scrum teams has also contributed to the improvement of the ticket closure rate.
Agile Practices
The team needed direction in agile practices. The original team structure as a one developer group and one QA group had not lent itself to good agile practices. There were internal demos, but not external. The manager of the team oversaw assigning work, person by person and story by story. This practice alone created a large bottleneck. Often team members were not sure which story to pick up next and what work they should be performing. There was also very little interaction between business stakeholders and the team about work intake, priorities, and goals.
Trainings for the teams were conducted in a lunch and learn fashion in:
- Proper use of Jira
- Agile ceremonies
- Sprint demos
- Story creation
- Story refinement
As the teams have started to mature, we have continued to promote increased stakeholder engagement and communication. In the last sprint there were demos for the business!!! The teams have started to get support from the business and increased engagement with priorities. The business is starting to see real work done and has even been complimentary of the teams.
Measuring the Impact of Agile Transformation
Story points were implemented in November 2023. The team size has not changed, and as of this writing, the team was down 1 very senior developer and a data architect.
As the chart illustrates, the 3 pods have seen a month over month increase in points completed. Six months into the change, the team’s velocity has increased five times. The one change of adding story points allowed the development managers to quantify results in a way the business can see and understand. This measurement also means the team can prove work is being done. This is the start of the ability of the team to become predictable and sustainable in their work.
The agile teams have all started meeting with their stakeholders on priorities and requirements. These meetings have improved the interactions and communication between development and business. Stakeholders are now attending sprint demos and are starting to communicate a more positive view of the team. One of the stakeholders has reached out to the engineering director with positive feedback about the productivity of the team and the quality of the work being completed. This is a full 180 degree turn from 6 months ago.
Ticket quality overall has improved dramatically. Owners on the tickets have increased from 20% populated to 80% populated. Story points are now on almost 100% of the tickets and stakeholder identification on tickets has gone from 10% to 50% populated. All metrics are improving for the team.
Summary and Lessons Learned
K&B’s data-driven coaching and collaborative approach enabled significant improvement in an Agile team without technical overhauls. Not all changes and improvements have to be technical in nature. K&B has dramatically improved the tracking, communication, and structure of the client’s data engineering team by coaching them to align more to agile practices. Small steps forward have made great leaps for the team. All metrics are trending positively, and the team now has a stable base to start to look at more technical and complicated issues.
For more insights and to explore how our solutions can benefit your organization, speak with an expert today!
