Back to resources

Moving From Cowboy to Agile Delivery

Scaling Team
Team Processes
Career Path
Agile / Scrum

15 July, 2021

Catalin Stoiovici
Catalin Stoiovici

Head of Scaled Engineering Delivery at Capco

Catalin Stoiovici, Head of Engineering Delivery at Capco, shares how he helped his team transition to a more mature operational practice and replace their ad hoc, cowboy style of delivery with Agile.

Problem

Years ago, I joined a team that I felt was entangled in a number of problems. Three that stood out from the start were:

  • There was no career development plan for engineers on the team. For engineers to be happy, they need to have clear expectations on how they could grow and how their employers could help. Moreover, time-crunched as most engineering teams are, we were not spending enough time discussing with engineers what they wanted to do next and what their goals and aspirations were.
  • The structure I encountered was not matching our needs. It was evident that the reorg was long overdue. Most of the team leads neither wanted to manage people nor had the skills to do that. In addition, I noticed some personal animosities among people on the team, which is not uncommon for a team of any kind but should be dealt with before it escalates.
  • There were no metrics for team success or team health. Without metrics in place, it was hard to tell if the team was doing a good job or not. In most cases, without reliable data, people tend to resort to pointing fingers and blaming others. Also, we didn’t have sprint goals and were not tracking delivery speed by keeping tabs on velocity or lead time and product alignment by keeping tabs on OKRs.

Actions taken

I addressed each of those problems separately. I understood that they were manifestations of a deeper structural problem: a lack of a proper development process. By introducing Agile and being more responsive to the team’s needs, I managed to move the needle in the right direction.

I allocated ample time to understand the career goals of every individual on the team and then assess if those were aligned with organisational objectives. I would help engineers draft a document on what their career development plan should look like and have them identify how I could help them move faster toward their career goals.

I decided to do a complete overhaul of the organisational structure. I made everyone report to me because I didn’t want to force team leads to do anything they didn’t want to do. We were lucky that I had the bandwidth to cover for them and take on myself managing all the team.

Also, I had to figure out how to re-shuffle people and minimise the impact of those intra-team animosities. If all senior people would be kept on the same team, the tension between them would likely appear. As seniors, they would have strong opinions about decisions and pick up a fight over minor matters. By mixing up seniors and juniors, I created a more balanced team and healthier atmosphere. I encouraged mentoring, good practice exchanges, brainstorms on technical solutions, intensive technical discussions, etc.

I managed to visualise our success from one sprint to another and ensure the alignment of priorities by creating the right metrics and dashboards. I also introduced metrics that could help us improve the quality of our work. In the past, all of our incident management was handled over email, and we were not tracking our production incidents diligently. I introduced level one to three production support that allowed us to visualise incident metrics.

Finally, I had to introduce some metrics that would measure the health of the team. The team did annual 360 reviews, but that felt like coaching someone tennis and giving them feedback on their serve once per month. The team needed more frequent feedback to be able to act on it. I introduced Officevibe, a team engagement platform that helped me track and improve the team’s health. My team members could fill in anonymous surveys and share their thoughts, and I would make sure to convey their feedback to the leadership.

Lessons learned

  • People need to be supported. Allocate enough time to the different types of support they need. Career development is massively important for every engineer, so you need to dedicate time to career development discussions. One of my primary responsibilities would be to help my team identify their Ps (Purpose). According to Daniel Pink, the purpose is one of the three main components of motivation, a prerequisite for one’s growth. If the only reason why your engineers come to work is to deliver code, they will not be happy. But if they feel that they are part of a bigger picture or a greater purpose, they will find their work more enjoyable.
  • I always encourage people to do better and continuously improve their skills by understanding the impact of continuous improvement (kaizen). For a team to be truly agile, it needs to consist of individual minds that embrace the growth mindset.
  • You have to choose the team structure that will not impose the responsibility of managing people on those who are unwilling to do it. In general, I would always try to replace imposing with encouraging.
  • Differences of opinion are normal and even healthy. People should feel free to disagree, vent off, and even decide with whom they want to work. That will make them more productive.
  • Having metrics in place is a precondition for understanding if someone is doing a good job. Metrics are like a compass that helps you understand in which direction you should be going. They allow you to make the right business or personal decisions, and one can’t be agile without being committed to measuring things.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How to Enter QA With a Non-Technical Degree

2 August

Lewis Prescott, QA Lead at Cera Care, explains his journey from a degree in psychology to learning test automation and computer programming.

Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Career Path
Lewis Prescott

Lewis Prescott

QA Lead at CeraCare

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How Product Management Chose Me

23 June

My accidental journey into product management

Product
Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One