Using 'Center Peel' strategy in Software development

How to focus and attack problems quickly with intensity.

Center peel,”Australian peel”, or simply “peel” for short, is a type of retreat practiced by modern-day infantry. This particular tactic is more specifically designed for situations where smaller groups of infantry withdraw from an engagement of a much larger force. 

I have borrowed the name to use it for a strategy that I use regularly when managing software development teams. This is not a new concept. A very similar concept called Mob Programming has been around for over a decade. The term “Mob Programming” was coined in 2003.

My particular version of Mob Programming is different in a few aspects. First, it’s more structured. Like the infantry tactic, team members must (not optional) take turns “on point” or on the keyboard. Once that team member is losing velocity or getting tired, the team leader will rotate that team member to the back of the line. The team leader chooses the next team member to take his place. This is done to keep up the intensity, focus, and velocity. The team leader must know when to allow the team to learn on their own and simply give pointers or suggestions. 

Leadership

The leader must also know when to jump in and show the team how to do certain things. The leader is also making sure that the team is focused on one thing. He must identify members who are drifting off or not paying attention. He or she must call on these team members to participate and provide value to the team. The leader is responsible for identifying high performers and low performers and making the necessary corrections.

At first glance, my method might seem overly militant. Most programming teams who do mob programming rely on good hiring practices, genuine collaboration, motivation, teamwork, and great interpersonal skills by all team members. That’s awesome if every team member has that. That’s when a team can really do awesome things. Often times that’s when reality punches you in the face. Because most of the time, you will not have an entire team full of motivated and skilled team members.

 

(Photo: Austin Distel Unsplash)

Our Company Has High Growth Goals. 

We’ve grown over 700% in the last year in both revenue and size. We plan to double our size again in the next 12 months. We need to build teams and leaders quickly and efficiently. We need to weed out the unmotivated, the slackers, and the low-performers quickly. We need to identify the leaders and top performers so we can double down on them and help them achieve their goals. We don’t have time to wait for teams to become super productive. To grow at the speed we have been, we must find ways to build new teams and make the super-productive right away.

With this method, the unmotivated, low-performers can’t hide. They are exposed quickly and removed quickly. But what brings the most value is that the highly motivated and high performers are quickly identified. Those in between are quickly trained and made into better programmers and team members due to a constant cadence of highly focused problem solving reviewed by peers and a team leader. Problems between different disciplines such as frontend and backend are quickly brought to the surface.

Generally, I will put together a new team and personally lead that team for a while. I will try to identify someone in that team who has the attributes to be a leader. I will slowly give more and more responsibilities to that person. Slowly, I will phase out my participation by deferring to the chosen leader. We prefer to promote from within and not hire leaders from outside. People who get promoted from within are respected by their teammates. They have proven themselves and have a rapport with the team.

 

(Photo: Mimi Thian Unsplash)

New Team Members 

They are welcomed to the team by being put on point on their first day. It’s sink or swims in our company. We won’t let you drown, but we will watch you struggle and see how you react. We want motivated people who don’t give up. And this system quickly identifies those people to the management and to the team members themselves. Those who prove themselves, get our full support to grow to the next level. Most of our best leaders have come up through the ranks this way.

Almost every place I have worked at has its people working on tasks individually. That might work if you have a very high performing team and highly motivated team members who have excellent communication skills. Unfortunately, this is not always the case.

There maybe junior devs on the team. Or more senior team members may be busy and focused on their own work. Things tend to get lost in communication or the lack thereof. The tiny miscommunications or lack of focus, motivation, and drive add up over time. Deadlines are missed. Projects are delayed. Clients and customers get angry. 

As I learned from motorsports, every 1/100th of a second count. Races are won and lost in hundredths of a second. Every minute that a team member is waiting for another team member to respond to an email, provision another VM on the cloud, or modify a JSON API payload, is a minute the project is getting delayed, and the company is falling behind the competition.

This is not the silver bullet and things can and do go wrong. In order to quickly create team leads, we must give have a lot of trust in our team and our leaders. Sometimes the people we give a chance to lead end up not having what it takes. We have to quickly set expectations and/or make adjustments quickly.
Some times the leader doesn’t see the value in this method or is not strong enough to enforce it. Usually, project timelines slip because of this and we have to adjust it and employ the Center Peel strategy again to get things back in line.

In One Of Our Recent Projects, A Perfect Storm Happened. 

We promoted someone to a leadership position that they were not ready for. We then tried to salvage the situation by hiring a leader from the outside. The team also preferred to work in silos of frontend and backend. They also preferred to work on tickets individually. This leads to 20-40 tickets being completed but zero features passing UAT. This also leads to incredible inefficiencies and delays. Something had to be done.

I tried to convince the existing team and team leads to start off with paired programming. The team resisted. I then tried to go all out with Center Peel Programming for one week. Unfortunately, I was also very busy with sales meetings and writing proposals. This method requires constant supervision and leadership. I simply didn’t have the time.

I tried over and over to convince the Project Manager, Solutions Architect, and Team Lead to focus on delivering features and to work in teams of at least two(with one keyboard per team). People were still resisting. They wanted to zone out and focus on their “own” tickets individually. Timelines kept slipping. Dates kept getting extended.

Finally, a breakthrough happened and the Project Manager and the team started working in one room. I think they were sick of my repeated hounding of them to change the way they work. That and the fact that they missed many deadlines. I also held a meeting and made sure that the Project Manager, Solutions Architect, Team Lead, and the whole team knew that the PM, SA, and TL were all responsible and accountable for making the project turn around and meeting deadlines.

(Photo: You X Ventures Unsplash)

Higher Pace, More Focus, Higher Cadence

The team started working at a much higher pace, with more focus, and higher cadence. Everyone knew what everyone else was working on and when it was supposed to be delivered. The Project Manager asked for updates continuously throughout the day. The project slowly, but surely, started to turn around and meet deadlines and client expectations.

God helps those who help themselves.

Center Peel Programming Doesn’t Need to Be Used All The Time. 

I suggest using it initially on a new project so that everyone gets a feel for their fellow teammates. It’s also very good to use when new team members join. I also use Center Peel Programming when there’s a difficult problem to solve or when schedules start slipping. Once a team is good at Center Peel, I prefer to break up into paired programming or individual programming during normal conditions.

This approach is not for everyone. Each company, each team, each leader is different. I have used this successfully to grow my company 700% in the past year. You can try to hire the best people and hope your teams perform well. I prefer to not leave those things up to chance. I use Center Peel Programming to:

• Get the entire team focused on the same thing.
• Motivate team members.
• Quickly expose team (collectively) and team member (individually) weaknesses and strengths
• Identify top and bottom performers
• Identify those with leadership attributes
• Increase cadence of work
• Minimize slack, delays, and other overhead that can cause delays in project timelines
• Quickly onboard new team members

I highly suggest you try it out for at least 2 weeks. Remember, you must have a strong experienced leader to initially pull this off. But once you get a team working in this manner and you put the right people in charge, things will start to run on cruise control. Please let me know if you do try this and if it works for you and your team.

Also, a colleague of mine, KwangTung Taesuji, wrote a blog article "Hello CenterPeel in Software Project" in Thai. You can check it out.