This university session given by Yves Hanoulle and Jef Cumps was covering two main topics: an introduction to Xtreme Programming and an overview of the very popular SCRUM agile methodology. In this post we delve deeper into Xtreme Programming. A detailed Scrum post will come soon.

Xtreme Programming

Three loops were described where an XP team loops through endlessly: the organisational loop, the team loop and the code loop. Below we give a short introduction of the 3 loops.

Organisational loop

The outer loop is the release loop, which interacts with the outer world, and which will let a predefined amount of requirements come in and working quality software pop out of the team regularly.

The organisational loop consists of 2 main values: close collaboration with the customer and small releases.

An XP project generally has an onsite customer who’s able to take business decisions. The technical decisions are taken by the developers.

Small releases are iterations of 2-to-4 weeks of coding work which consist of a number of finished user stories. Stories describe the requirements (high level – as the cards are not big enough to tell it all. But they enable communication with the business.) Besides that the stories are also ordered by the team in function of complexity, while the onsite customer will assign a business value. Together they’ll form the priority of taks to execute.

The fast releases allow for fast feedback cycles, allowing the customer to change direction faster if needed.

Team loop

The middle loop is the team loop, which handles day to day team activities.

The idea is that the developers work in a sustainable pace and as a team.

A daily standup meeting is organized. Because it’s standing the meeting doesn’t last too long (should be max 15 minutes). Here the team talks about 3 things:

• what you’ve done the previous day
• what do you commit to do today (it is a small line between what you’ll do and what you’ll commit to finish today, but it is a very important one)
• tell others: “I need help with …”

It’s very important todo it every day, for it to work well.

Code loop

The inner loop is the coding loop, where two programmers, sitting side by side, produce a unit of tested code.

Pair programming, programming with two together, in the long term costs less then not doing it. Switching keyboards every 10-15minutes work best. (should not be longer then 30 minutes). One of the positive effects of pair programming is that you get instant code review and generally the code will look a lot different (read better) then if the two would have implemented the task alone.

Unit tests, are a safety net as you’ll know what is working / what’s not working. It’ll also make refactorings easier, less dangerous because of the safety net. They assure the quality of your code.

Test driven design, means writing your unit tests first. It’l make you think about the problem and how you’re going to implement the solution. As a result the design of your code will be better.
Continuous integration, is also very important for an XP project. Fast and automatic integration means that you’re project doesn’t stay stuck at 90% finished and just some integration work to finish (which you have no idea how long it’ll take). Automating everything can be a huge investment, but generally pays off in the longer term.

Collective code ownership, means anybody can change anyone’s code as long as the rules are followed. Those rules are defined by the team itself and could eg. be “tests not failing”, “no findbugs errors”, … Sometimes collective code ownership is hard but this generally indicates an underlying problem of Trust.
Acceptance tests, are defined by the proxy customer. It defines when are we done? => When all acceptance tests pass. The customer should write it just-in-time. (eg. for the next iteration when the developers are currently working on the current iteration).

That ends our little overview of Xtreme Programming. Retrospectives and Velocity we’ll leave for our coming Scrum article!

You can find the slides from this Xtreme Programming talk at Yves Hanoulle’s blog