Tag: extremeprogramming

In my previous post, I shared with you how Philippe and I prepared for our talk “Extreme Practices.” In this post, I will be briefing the talk’s content; starting with the pitch and ending with the feedback! Philippe has already posted a blog on the talk that you can read here.

Pitching

Each of the speakers had to brief their session in a thirty seconds pitch. This was mine:

This is unusual for me, because my co-presenter is in Paris! Philippe and I will demonstrate how we adopted the practices of Extreme Programming in our distributed team. We will also have two live demos; the first on remote pair programming and the second on remote meetings.

The talk

The audience started taking their seats; and in a couple of minutes, the room was full! We started by engaging the audience with three simple questions!

Who goes to work by car?

Who goes to work by bus?

Who goes to work on Skype?

Extreme programming

After introducing ourselves, our team and Murex, we spent the first half of the talk discussing four of the XP practices and their benefits.

Only coding what makes tests pass decreases the possibility of generating bugs

In most cases, a failing unit test is enough to detect where the bug is and thus reducing the need for debugging

The refactoring step drives to clean code

Finding difficulty writing a test is an indication that refactoring is required

Pair Programming

Benefits:

Newcomers tend to learn faster and submit on their first day

The quality of our code has increased

We didn’t notice any negative any impact on productivity

It helped us build a bonded team

Difficulties

It is very tiring for both the driver and navigator

It is risky because some developers prefer to work alone

Retrospectives: For this part, we explained the five stages of our retrospectives

Check-in/energizer

Throwback

Collect insights & discuss

Actions

ROTI

Extreme programming in remote mode

Our second half of the talk was dedicated to sharing how we are applying XP in a remote mode, mainly focusing on Pair-Programing and Retrospectives. The discussion included the difficulties we faced at the beginning and how we managed to solve them. We ended the discussion on both topics by a live demo!

Remote Pair Programming

To overcome the problem of time difference between the two cities, the pairs tend to share their calendars as well as an online document with the detailed tasks required to finish the story

The navigator might easily lose focus; that is why we try to submit frequently and switch control as much as possible

It is more tiring than local pair-programming especially if you have the headset on all day long. We agreed that anyone is free to ask for a break at any time

Remote Retrospectives

The whiteBoards were located in Paris, and thus it was hard for us in Beirut to effectively contribute to the meetings. We managed to solve this problem by replacing our the whiteboard with an online Trello boards.

Initially, our meetings were held over the phone lacking any visualization of the team on the other side which caused a lot of frustration. To overcome this problem, our IT team installed Visio Conference rooms in both cities!

Here is a short video of the PairProgramming demo we did!

Main message

“You don’t have to move abroad for your dream job!“.

Remote work is becoming the trend! The advancement of the collaboration tools and technologies is making it easier for companies to adopt. In the future, you will see more and more developers working from home.

That was our message to the audience! We concluded that there are three ways to organize your team when working remotely:

Split the team in two if there are enough members in each city

Work in open-source mode if team members are distributed over many cities

Finally, adopt our remote XP practices if it is not possible to split the team in two

Feedback

In addition to the above two Kudo cards, I received several positive verbal feedback at the end of the session. All that was a sign that our talk was successful!

Dev Tools: Configuring some dev tools on their machines was the second step. This involved the installation and configuration of Java, IntelliJ, Maven and Perforce. Some of those tools such as Perforce and Maven were relatively new to them; so they took some time to learn more about it.

TDD: By now, they were ready to write some code! And what would be better than following TDD to do that? Most of our teams started adopting TDD, thus coaching newcomers on TDD for simple dev problems is a must! For that purpose I picked the following two problems:

Mars Rover: This might be an easy problem, but I find it well suited to practice TDD especially for TDD newbies as it has a lot of cases to be covered by tests.

Coffee Machine: The beauty of this problem, is that it simulates what happens in the life cycle of an agile project, such as:

Defining new requirements at the start of each iteration

Writing the minimum code to implement the required features

Continuous code refactoring

Write the sufficient tests at each iteration

Design Pattern and Code Refactoring: The two problems above may not be complex and can be solved in a short time, but the solution wasn’t the primary purpose rather it was introducing new concepts and practices to them. To make sure this purpose was achieved, I was performing multiple code review sessions during each iteration and suggesting enhancement at each time. This process elongated the time for each iteration, but it was worth. Some of the concepts I focused on were:

Test coverage

Builder pattern

Visitor pattern

Factory pattern

Bad and good code practices

Mocking

Maven: They used Maven to build the code they wrote previously, but it was only maven’s basic commands. At this phase of the training, I asked them to dig deeper into maven to have a better understanding how it works; mainly focusing on:

Phases of build lifecycle

Dependency management

Plugins

Local and remote repositories

SCM: Whether it is Git or Perforce, there are a couple of must know operations for any developer to be part of a development team. As a practice on those operations, they simulated a real dev cycle scenario by:

Sharing a common working directory on Perforce

Creating branches

Merging/Integrating changes

Resolving conflicts

Continuous Integration (CI)As fresh graduates, the continuous integration was a new concept for them. Whereas for us, it is an essential process of our development cycle. It wasn’t possible to use an existing Jenkins instance to perform their testing; thus they executed the below steps:

Download and configure Jenkins locally on their machines

Submit their code to Perforce

Add a new job that syncs, compile code and execute the tests

I noticed the benefit of this training from the emails they sent me at the end of the program. They detailed what they learned and most importantly they were able to highlight the advantages of those practices and tools.

While reading the book “Extreme Programming Explained,” I came across an interview with Brad Jensen a Senior Vice President of Airline Products Development at Sabre Airline Solutions. During the interview, Brad explained how he applied XP within his company and some of the difficulties he faced.

In this blog, I will be sharing my takeaways from this interview; because I thought it is worth sharing with others especially those willing to apply XP.

The Interview

Brad explained that he was able to apply XP in his company that consisted of 300 employees, 240 of which are developers, 25 in management and 35 in testing. His primary purpose was to bring 13 products into one organization with one architecture and one UI.

They started by giving a one-week training for each of the 13 groups then followed by coaching when they started applying XP. But, he advises on doing the training for one team at a time (making sure each time that the team got the concept of XP)

My Takeaways

How he made it work

XP was a perfect fit for Java projects with a motivated team

Testing and refactoring of C++ legacy code were very hard due to the complex design and lack of refactoring tools. Thus, XP had to be applied in a waterfall-ish way for such projects. Which meant:

more design and requirement gathering up-front

formal testing phase before deploying

Using XP decreased the number of defects to zero in some Java projects. For the C++ legacy, the defects dropped to a ratio of one to two per thousand lines of code

They noticed a 40% increase in productivity

It wasn’t easy to adopt XP! At first, only a third buy-in whereas the rest either are skeptical or just wait and see. Eventually, 80-90% buy-in, 10-20% use XP grudgingly and 3-5% never buy-in

If programmers don’t pair or insist on owning code have the courage to fire them

On-site Customers

A project manager should represent all of his customers

Having on-site customers is the most valuable part of XP because it gives you the ability to manage properly the scope and visibility on whether you are going to make it or not.

Without careful watching, on-site customers can cause the most problems as scope management can turn into scope creep

Advice for Executives

Plan by feature

Plan release once a quarter

Plan fixed-iterations more frequently

Have customers sit with the team

Put team in one open space

Give It a Try

In my team, we’ve been using this methodology for a while now, and it is working perfectly for us. We maintain clean code with test coverage up to 85%. We also managed to tune it to fit our needs, for example doing remote pair programming (you can check some of Philippe’s posts for more insights on the way we work.)

The importance of this interview is that it provided a real example of applying XP not only theories. Thus, it might encourage leaders to give XP a try!

I highly advise you to read this book. If you are new to XP, this book will give you insights on what this methodology is, why is it important and how to adopt it within your team. If you are already an XP developer, this book is your reference to know whether you are applying it correctly or not.

Two weeks ago we started running coding dojo sessions at our offices in Beirut, the first sessions we had so far were much better than what we expected. In this article, I will be sharing my experience (as the one running those sessions) starting from the preparation and ending by the feedback on those sessions.

What is CodingDojo?

CodingDojo is a meeting where a group of people gets together to solve a programming challenge following TDD. We select those challenges from several online sites like Google Code Jam and Cyber Dojo.Each dojo session is planned to take 2 hours including a 15-minute retrospective at the end and is scheduled once every week. All the participants are contributors, as we rotate on the driver (one who is coding) every 5 minutes. Thus, it is important to limit the number of participants per session to a maximum of 8. We carefully chose the session timings to be during lunchtime from 12:00 to 14:00 in order not to interrupt participants’ usual tasks. Finally, it is important to note that the participation to those sessions is not restricted to specific teams, rather anyone regardless of their programming expertise is welcome to join. After all, codingdojo is a place where we take knowledge sharing to the extreme.

From Paris to Beirut

It started almost 2 years ago as an activity within our team members only, but 8 months ago it was changed to involve interested people from other teams (in Paris only) as well. By the end of each session a 15-minute retrospective was held, during which we have always received positive feedback from the participants. For them, it was a chance to learn how to write code following TDD, learn new programming languages and techniques and enjoy a teamwork spirit to solve a programming challenge. We decided to leverage on the experience we gained in Paris and start similar sessions in Beirut. At that point, we had no clue on the participation level or its success rate but it was a risk we were willing to take.

Preparation

The first step of the preparation was to contact the HR team asking them for sponsorship as such an activity involves communication and involvement of many teams. We had a meeting with them, explained what codingdojo is and what is expected from those sessions; as expected, they were very supportive to such an initiative. They granted us their sponsorship and offered their help in global communication, coordination with the administration to provide lunch for participants and whenever needed later.

Second came the technical preparation for better running and managing such an activity. Writing code following TDD became a habit as I have been doing that for more than a year and a half (since I joined my new team). But still I decided to practice more by solving some challenges outside working hours.
For me managing such sessions was the main challenge and a new experience. For that, I started attending (via Visio conference) the sessions managed by Philippe (my teammate in Paris). During which, I tried to benefit from Philippe’s experience and save tips and advice he provided. Finally, we also agreed with Antoine (my teammate in Paris) to visit Beirut and assist me in running the first two sessions.

Communication

After setting the start date to be on Wednesday, July 15, 2015, we sent a communication email to all Beirut employees announcing the kick-off of codingdojo and opening the door for registration. In less than one day, more than 30 participants were registered. That was a surprise!!! We weren’t expecting that many participants, especially that many of them were not developers. Since running a single session with 30 participants was impossible, we decided to divide the participants into 4 groups/sessions over the following 4 weeks.

First Two Sessions

For the first 2 sessions, Antoine and I prepared very well by selecting and solving the problems ahead of time. Despite that, we made sure not to impose our solution, rather we tried to have an open discussion and agree with the rest on the next tests to write.The first 30 minutes of both sessions were the hardest. Almost all participants were not familiar with the concept of writing the test before the code that is why we made sure to be the first 2 to drive the code and when someone was coding you would hear us saying “That is correct, but you forgot to write the test!” when others were coding. After that, things started to go smoother! Participants got acquainted with the concept and were aware when they missed the tests. For us, the first two sessions were great and much better than what we expected. We expected to have someone trying to control keyboard or dictating his solution. On the contrary, everyone respected the 5-minute limit they had. They were all sharing the solution with others. It was clear to us, from the feedback (listed below) we got from participants during the retrospective, that they enjoyed their time and are willing to attend future sessions:

Nice, good experience; you learn from others

Nice technique to learn when trying to write the first test and nice way to think incrementally

It is hard to do it alone; it is easier with a group

I am not a developer and not familiar to Java, but it was good to see the mindset of the developers

Nice to meet people from other teams

Nice practice because you are enforced to follow a convention; taught us new best practices

I like the idea of refactoring; the complex code was refactored into couple lines of code that made it more readable

TDD is a bit slow; the pros are the interaction between each other

My Feedback

Running those sessions is not an easy task, it requires a lot of effort before and during each session. Before any session, the leader should prepare the right environment for the participants. During the session, the leader should always be focused on what the driver is writing and at the same time listen to suggestion proposed by others and answer the questions raised.
Despite that, it is a great experience from which you learn and gain a lot.
Later in coming sessions we might be introducing some new challenges like increasing the problem complexity or trying new programming languages. I hope that people will remain motivated and enthusiastic to attend the coming sessions!

P.S: The code we write during those sessions will be committed to this GitHub repository.