Encountering XP

My first experience with agile methodologies was a XP project in a software house (based in Leuven, Belgium) that was implementing a migration of a huge 30 year old mainframe system into Java (jsf, kodo, Oracle, Sun) platform. During that year, back in 2005, I witnessed a fast transformation of a big, old fashioned and slow (RUP) team into an extremely efficient XP machine.

 NB: RUP (Rational Unified Process, IBM) with its iterative approach was, at that time, the “way to go” in software development in western Europe and generally around the world.

What is XP or eXtreme Programming? Lots of literature can be found on internet, and the simplest definition would be that XP is a set of rules programmers need to obey: collective ownership, continuous integration, test driven development, pair programming, daily standup, sustainable pace …

Our team was strict in following all known XP rules at that time. We were led by a man who already had long experience with XP.  As a first XP coach in the project, I had daily brainwashing sessions from him and we all read the Kent Beck’ book in the first few weeks of the project.

We were around 20 programmers (not counting analysts, managers) and in the beginning we functioned as one big team. Later on, as we have grown, we were split into 3 functionally divided teams (around 30 programmers in total).

How does it feel to work on an XP project? I will try to describe the things that impressed me the most in that period - things that made me, and still make me, believe that Agile is the best methodology for successful software development.

Collective ownership. Everyone owns the code. Everyone needs to know everything about the system (code and configuration). Having “indispensable” people is history. Computers belong to everybody. While arriving to the office in the morning, you do not know where exactly you are going to be seated that day since you do not have your own machine (all computers are identically configured and can literally be reformatted every day with identical image). You sit for the first available machine and analyze work you did previous day or plan to do while waiting for the standup meeting (Scrum) to get your assignment for the day or part of the day. Intention is to have tasks divided “vertically” as much as possible and never “horizontally”: if you are developing part of a new page, then you are also developing its business code as well as communication with the database. Classical divisions of type “he is good with databases” or “she is the best in front end development” cease to exist.

Pair programming

XP is loud. If you are not focused on finishing some task with “your pair”, everything sounds extremely messy; there is too much noise in the house. Behind each computer in a big room, there are 2 persons seated that are constantly talking to each other, mostly commenting things they see at the screens. Pair programming is a rule where there are 2 developers behind each computer, a pair: driver, the one that codes (drives) and a navigator, the one that has an eye on the driver, noticing mistakes, thinking of the things ahead of them, things we perhaps did not think about yet. The rule we had was to exchange these roles every 15 minutes. Sometimes this frequency was adjusted to follow the frequency of TDD (test driven development) where one developer writes the test and the other one takes care of the actual implementation. Pair programming is the most efficient way of knowledge transfer. Pair programming is also the most efficient way for creating qualitative software. Code reviews in teams where pairs are exchanged with sufficient dynamics are mostly not needed. Pairs change frequently, if not during one day then certainly in the following day. My job, of an XP coach, was to, among others, argument the need that someone needs to change his/her pair, if that someone haven’t indicated that need him/herself. Sometimes we did the “re-pairing” around noon, to boost the work dynamics. In any case, the “story lead” is the one that is responsible for delivery (and update of the burndown), that remains his/her responsibility while the pairs sitting next to him/her are changing.

Test driven development (TDD) is the principle that impressed me the most at that time and since then I am trying to use TDD on all projects I am involved in. To master TDD means accepting the following rule: not a single change to the source code or configuration or any artifact of the system that is part of the production release, if you first haven’t made a test that shows what that change means to the system. Once written, that test need to fail (“red”) because your change hasn’t been made yet. After that you are allowed to make the change to the system (code, configuration, database etc.) and the test then needs to succeed (“green”). Phase that follows is to improve the code you just wrote by refactoring it in small steps that are, each time, interleaved by execution of the test you have just made and possibly other tests too. Tests being green during refactoring are the guarantee you haven’t broken any functionality during refactoring. Red-green-refactor.

Tests are ideal way of documenting the source code. Methods in the test classes that contain complete sentences in their names are very common because this is the best place to describe what system exactly does – in the test that guarantees that it does what it was supposed to do. Comments (javadoc) in the code were not allowed due to high risk of getting out of date. We even had automatic tests (part of the continuous build, see later) that were scanning the source code and report (fail) when comments in the code are detected.

Continuous build ensures frequent execution of all tests with purpose of controlling the source code that is checked in on a daily base by developers. Before any check in, developer first fetches the “build token” (a little teddy bear in our case) and keep it on a visible place next to his/her machine. Then code is synchronized with the latest code in the repository and the build process is started which needs to be executed successfully in order to be able to check in the changes he/she made. That same build process or mostly a much larger version of it is executed on production-like system (= full build) is executed as part of the continuous build process that runs every night and guarantees the stability of the system after all check ins of the previous day. In case the build has become unstable, central monitor (visible to all developers) shows big red flag as a sign to everyone in the team that they first need to “fix the build” prior to doing anything else (in the morning).

I will mention one more rule that is very important in XP (although it took me long time to realize why): sustainable pace. It is REALLY important not to burn, work long hours. If that is a case, you are not truly following XP game. It can easily burn you (out).

Sounds familiar? You want to hear more from people with similar experiences? Join us!

 

Sejo Ćesić
Certified ScrumMaster® (CSM)

About the author
Sejo Ćesić
Author: Sejo Ćesić
About:
Sejo Ćesić is a Java developer with more than 14 years of experience, mostly as a freelancer working on projects in various business domains such are government, inssurance and automotive. On most of the projects Sejo was and still is involved with, he plays the role of a technical coach or architect. After successful completion of several agile projects, Sejo certified himself as a scrum master in 2012. Sejo holds master degree in computer science from VUB Brussels, Belgium.

Past Events

Our Services

Contact Us

Bosnia Agile
Milana Preloga 12, Sarajevo 71000
Bosna i Hercegovina

This email address is being protected from spambots. You need JavaScript enabled to view it.
www.agile.ba