Extreme Programming

We've been doing Test Driven Development and Pair Programming at my workplace for quite some time. They are both part of the methodology developed by Glenn Beck called Extreme Programming (XP). I became curious, are we doing extreme programming? Is there more to it then we do? Let's take a look.

Extreme Programming is sometimes distilled into five values: Communication, Simplicity, Feedback, Courage and Respect.

Communication

From Wikipedia we gather:

Extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.

We do favor collaboration as a knowledge sharing tool in the team, as opposed to extensive documentation explaining everything. We also favor frequent verbal communication through discussing stories at a grooming stage and at a planning stage and whenever necessary. We used to be better with feedback, where we would measure the impact of the features that we had implemented.

One thing, that I believe is part of Domain Driven Design, is called Event Storming, which is a method to make sure that everyone in the project has the same understanding of a project. This has proven great, and has also shown to clarify some misunderstanding.

Simplicity

I really like this one. Simplicity is about: building the simplest possible solution, and not making it more complex until necessary. It is also about refactoring to make sure that logic is not duplicated. This is something I find that we do well.

Feedback

Wikipedia divides into three forms of feedback:

• Feedback from the system: by writing unit tests, or running periodic integration tests, the programmers have direct feedback from the state of the system after implementing changes.
• Feedback from the customer: The functional tests (aka acceptance tests) are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
• Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.

The first part we do really well. We work according to TDD.

The second one we don't really have. I suppose this would mean that our product owner would produce acceptance tests for us. These kind of tests would be created by us if anything. The requirements are communicated by the Product Owner through stories.

The third one we do. We constantly plan and give feedback to the stories, pointing out missing information or possible ways of simplification.

Courage

The courage to throw away code, and to refactor. I think we do this well, with the unit tests in place as well this doesn't become so difficult.

Respect

Everyone should be appreciated and respected for the work they do. I believe we do this as good as we can. From my perspective this also means that you don't necessarily refactor other people's code unless there is a more valid reason than just personal taste.

Summary

I feel we do most of the things. I notice they favor having a system metaphor and widespread conventions that all people follow with the coding. Our coding is performed over many different repositories, some which we don't own, which unfortunately makes coding conventions a bit difficult. All in all though, I find we are working close to the XP process, and I also feel this makes sense, as I find our work process quite good.