Artificial Intelligence
Consulting
Development ServicesOne of our clients has recently sent most of his offshore team (hosted by us in Ukraine) to attend a two-day Scrum training externally. While the majority of team members were attending the training, the client's Head of Development (let's call him John) spent some time with those who stayed in the office and voiced his idea of team refactoring as a new way to make teams more engaged and efficient.
"So, guys, do you want me to tell you a fairy tale about developers' Heaven?" John asked while knocking the ashes out of his smoking pipe. The rest of the team nodded languidly as it was very hot on a summer terrace in our Odessa office. Having said it was going to be a long run story, John immersed in a cloud of his Balkan Delight tobacco and started.
"We have 50+ developers scattered around the Globe and we tended to be Agile in all locations. Yet, we still had fuck-ups on the project every now and then! Here in Ukraine we started as a team of 10 people and the early stages looked like a self-organizing chaos we had to move away from. As we grew across all locations and became a global DevOps driven cross-border team of over 50 people, we adopted a Waterfall model as it better matched our project requirements. But no one was quite ready for Waterfall, so we implemented Scrum for the team's convenience. Things seemed to have improved, but still there're issues that obvious to everyone involved in the project. And one of the problems is the lack of proper communication among our several collaborative teams. Testers don't test properly, juniors don't junior-develop well and designers bogged down in micromanagement and became so slow that developers couldn't proceed with their tasks for weeks!
You all understand that our project tasks will have to be completed regardless of a methodology choice, don't you? No matter if it's Waterfall, Agile or XP, their number and quality requirements will stay the same. As such, neither Scrum nor Waterfall will be able to replace our common sense. If production is in fire, we'll have to extinguish it. If something is omitted or screwed up, we'll naturally fall out of the process and lose integrity. And you can't reject communication with your PMs, nor can we get rid of our technology debt, as our support tasks grow in line with the growth of our app user base. And ensuring this growth is one of my key priorities! That being said, neither Scrum nor Kanban will save us from all this mess. Systems can't be closed; they breathe like any living organism.
Considering the fact that each of us wants to evolve and mature, write better and cleaner code and handle more challenging tasks, we need to refactor our team to make it work!"
Having made this statement, John looked around and saw 10 more people from our other teams joining and being all ears. John inhaled his Balkan Delight deeply and continued:
"You know the difference between TCP and UDP, don't you? Although UDP is better suited for streaming, it doesn't guarantee delivery. So, speaking metaphorically, I want you to combine both TCP and UDP to significantly increase the speed of delivery of new features.
Each of our distributed project teams has a Team Lead and this role is often assigned to one of our Senior Developers who, in their turn, report to myself [Head of Development] and I report to our CTO. Plus we have other random people who always interrupt the process and want to make changes. On the one hand, all of our software developers seem busy with their tasks, but on the other hand, there're always guys on the bench and guys who're overloaded with work or interrupt-driven problem solving. As such, most of our project fuck-ups occur because of the processes we, as a client, weren't able to set up properly in our organization from the very beginning. And speaking about the process, we seem to have one put in place, but it doesn't solve many problems. One of the critical problems is - when you want to code you can't code because of interruptions and when you can code you don't want to because you're already sick and tired of solving interrupt-driven issues."
"So, what's the solution you're offering here?" one of our devs asked finally .
"Team refactoring," John replied.
"To cut a long story short, I suggest that teams be structured in a different way. Team Lead can't lead the team, because it's a senior guy whose competence and experiences are needed for project success and whose time is too expensive to be spent on team management. What if we assign this role to a more or less good middle developer or even a prospective junior developer? Have you ever thought about it?"
The guys on the terrace looked at each other wondering what John has just smoked through his pipe to come up with such an idea. But John explained his thoughts further:
"What if we refactor and re-target team management processes? See for yourselves: any senior developer's productivity is a way higher than that of a junior or middle developer. Of course, not all senior guys really want to code by themselves, but the average senior developer does want to deliver code on a daily basis! It's easy to explain - the more work you'll do today, the greater bonus you'll get tomorrow. However, no senior developer can afford to just code due to a huge micromanagement hassle they have to deal with every day (e.g. mentoring juniors, helping colleagues with their tasks, communication with the client, etc). So, senior developers are in fact your key asset when it comes to delivery of truly quality products. Then we have less competent and experienced folks that want to grow and level up. They're middle developers who often lack assistance of their senior team members and appropriate level of respect form company managers. Middle guys rarely understand the processes as well as their senior colleagues do. But I insist that senior developers shouldn't lead the teams! They should program and develop, make decisions and be responsible for these decisions, while middle developers could manage teamwork.
My pro arguments are:
- The more deeply they immerse into processes, the better they understand them;
- To manage properly, middle developers will have to ask a lot of questions and over time these questions will be polished and fine-tuned to be the right ones;
- Middle developers are better motivated to work harder and smarter than the senior developers (most of whom really care about the remuneration only);
- They'll have a good chance to learn lessons from own fuck-ups and failures, which always makes us stronger and more competent in what we do.
If everything goes according to my plan, we'll have at least twice as many home-grown senior developers next year compared to this year. We haven't changed our IT hiring approach for 2 years and it's becoming detrimental for the project. We focus on hiring top-notch senior developers and increase our budgets every six months, while juniors take long to become middle developers and middle developers rarely convert into senior developers on our project. This happens because our bored and tired senior developers overload them with unclear, routine and non mission critical tasks which prevents them from maturing as seniors."
Then John faced Igor, our senior developer: "Igor, imagine being able to code for 30-40 hours a week instead of your current 20! You still have to work for 60+ hours a week trying to handle all those mind-blowing tasks we give you beyond your usual scope."
Igor couldn't agree more, because he's only seen his family sleeping lately and has been dreaming of coming home earlier for ages. Meanwhile, John looked at Oleg, our middle developer.
Would you like to learn more
about talent solutions
"Oleg, imagine being Igor's team lead. Wouldn't you be more engaged and productive if your work were less routine? You'd be able to see Igor's code from behind his back and understand there's no special senior magic behind it."
Oleg's eyes lit up with excitement. Five minutes ago he couldn't even imagine being in Igor's shoes and leading their team. He liked the idea a lot!
Now John turned to see Lana, our middle QA engineer.
"Lana, imagine being able to finally understand all ins and outs of our business processes so that your testers can get quality code and a bonus to salary for all new bugs found and eliminated at production."
Lana was shining, too, because now she knew what was wrong in her work. On the project, she collaborated closely with Mark, a hipster front-end developer (senior) who always delivered a good quality code. But the problem was that he had a very little time to code himself and outsourced most of his coding job to his middle and junior colleagues, while helping marketing prepare specifications for a UI designer (he knew UI design inside out!). He was so busy with communication and other things that rarely had time for a proper Code Review. While the whole team idolized Mark, Lana suffered because he left many bugs she'd found unattended, which prevented her whole team from moving on.
In spite of fatigue, none of them could sleep well that night. They all met on the terrace the next morning to determine a new team structure and create a new memorandum they'd stick to the Scrum board:
Team Lead = Team Manager
Team Manager = Middle Developer
Senior Developer = Code Leader
