My Personal Experience with Extreme Programming

Ben Hur
TribalScale
Published in
6 min readJul 27, 2022

Written by: Ben Hur Martins Carvalho, Agile Software Engineer, TribalScale

📫 Subscribe to receive our content here.

💬 Have any questions about extreme programming? Click here to chat with one of our experts!

My personal experience with Extreme Programming has allowed me to grow from being in a one company developer for 8 years, to now a fast pace software agency developer.

In case you are not familiar with Extreme Programming, here are some good articles to read:

Photo by Goran Ivos on Unsplash

My Background

Before joining TribalScale last year, I worked in a Brazilian bank as a full stack for 8 years. We used some agile principles, but we didn't follow the cadences, sprints and etc. It was more like, "we have a kanban board, we have some tasks here, and, that is it, we are agile!"

So my knowledge with agile principles came from reading and experiencing some cadences. My knowledge of XP was really shallow - it was just what I heard about.

First thoughts

At my first interview to join TribalScale I was told the company follows XP cadences such as Pair Programming and TDD, and without much faith, I was like, "Ok, we follow agile in my current job as well, no problem". But then at the next interview I was told about XP again and I realized that it was a real practice for TribalScale.

When everyone thinks about XP, their first thought is pair programming. I was not different. I decided to embrace it even though I had some concerns like, is this really effective? Tasks will take twice the time to be done! Pair programming may work at the office, but on remote working?

My Current Experience

After almost one year working at TribalScale, I can say, YES! Despite my initial concerns, XP is amazing and it works! At first sight I thought that XP was basically Pair Programming, but I've been learning more and more about its core values:

  • Simplicity — Not much to say, keep it as simple as possible.
  • Communication — A core value, especially when working remotely, over communicate! Everyone in the project should know what the other team members are doing and the status of it.
  • Feedback — So important, it is one of the best ways to improve your work, adjust the directions and stop making mistakes.
  • Courage — This one is special for me, if you notice something wrong in the project, be courageous, tell the team: Hey I have a problem and I need help! Be courageous to give and accept all feedback.
  • Respect — No need to explain, respect your colleagues and their work.
Photo by Jason Goodman on Unsplash

Talking about Pair Programming, I think it is great! At the very beginning of projects you can start to notice how solid the results will be. First of all, when someone is with you, you won't be spending hours looking for a small bug that is a result for lack of attention (and it happens, often). Two brains, one screen - the results are amazing! Your code will be solid and bug proof, with no need of infinite reworks on it.

One of the more important aspects of Pair Programming is the leverage of knowledge when pairing with someone with different skills than yours. The one that is more junior certainly will level up the skills way more faster than working alone, and the more senior dev also gains knowledge and mentoring experience, which is priceless.

Another important aspect is when someone leaves the team, (for any reason, sickness, vacations or just stop working at the same company) we have the knowledge already shared by the pair, so your sprints won't have a slow down period, or at least it won't last too long.

XP also provide us with more methods, like:

  • Testing/TDD: Not only for XP, but here is one of the core things that we have to do, unit tests already saved me countless times. I recommend you do it; never send uncovered code in a PR.
  • Small Releases: We delivery small releases in a weekly basis, so important when in an agile environment.
  • 40 hours week: Well, if your team is doing overtime for a long period of time, something is wrong. The planning part is failing, or someone gave an end time for the project that is not realistic.
  • On-site customer: Very important to have the customer engaged with the project, near of the team, that way the team will have no barriers to contact the customer to ask a questions.

There are more principles and deep understanding of core values, I would recommend the reading of: Extreme Programming Explained: Embrace Change.

Also I recommend a tool for Pair Programming when working remotely: Pop, it allows you to share your screen while the other developer can take control of it and swipe between driving and navigation.

Photo by Scott Graham on Unsplash

Rabbit Holes

  • Focus / Mondays Update: Working remotely, in my opinion, has the problem of not having constant human/peer contact, so what can happen when working remotely is, "Hey how was the weekend?"” and there it is, at least a 30 min talk about the weekend. Or even, you don't talk with someone for two weeks and in the first pair programming session you just want to talk about how life is going. This can cause a lack of focus depending on the devs, which need to be overcome in another way. The company can try to organize more socials online/in person and we should start to connect with friends/colleagues on social media. Talking with each other is alright, but if the deliveries or the product is being harmed we need to rethink how the team building or friendship bonds can be developed.
  • Constant communication while pairing: On the other hand, we still need to keep communication while pairing. For example, the dev that is driving can easily, in a moment of focus, start coding without saying what is being done and the navigator can get lost or just starting to loose engagement. It is important for both to know at what point of the dev process they are in right now.

Conclusion

I deeply believe that XP works when developing software, in office or working remote. After working with this method for a year, I can say that adopting it is a bold move, when we have other methods like scrum widely more used for other companies.

It will not be the solution for all problems in the software developing world, but it can provide a safe path to follow, and is has been a pleasant experience for me as a developer.

Ben is an Agile Software Engineer here at TribalScale and is based in Brazil. He is a front-end developer and his stack today is React Native and ReactJS, before TribalScale he worked as a full stack developer for 8 years. Outside of work he has multiple hobbies, a recent one is leather craft, and loves spending time with his 1 year old son.

TribalScale is a global innovation firm that helps enterprises adapt and thrive in the digital era. We transform teams and processes, build best-in-class digital products, and create disruptive startups. Learn more about us on our website. Connect with us on Twitter, LinkedIn & Facebook!

--

--

Ben Hur
TribalScale

I am a React Native Developer with passion to build things.