Moving From Cowboy to Agile Delivery

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.