In this post I will be talking about Kent Beck’s Extreme Programming Explained book, specifically Chapter 7, in this chapter we will talk about XP Practices.
In XP there are several practices that go in line with Extreme Programming, these practices help teams to get the best of them and to produce code in a new way that brings with it a lot of advantages. The XP practices are the following and we will talk a little bit of each one, for this part 1 we will talk about the first 6:
- Sit Together
- Whole Team
- Informative Workspace
- Energized Work
- Pair Programming
- Weekly Cycle
- Quarterly Cycle
- Ten-Minute Build
- Continuous Integration
- Test-First Programming
- Incremental Design
This practice suggests that teams should spend some time face to face programming, many companies have the cubicles and senior offices separated from the rest, this is not wrong but it is good to implement once a week a session of working in a conference room together or being in a space where everyone is together. If the team is ok with it you can always work in this way, but other teams like their privacy when programming in a cubicle, so, listen to your team and implement this practice.
“Sit Together” predicts that the more face time you have, the more humane and productive the project. If you have a multisite project and everything is going well, keep doing what you’re doing. If you have problems, think about ways to sit together more, even if it means traveling.
When building an XP team, you need to find the people with the required skills so that the project succeeds. Everyone will complement each others ideas and strengths, keep in mind that sometime in a project you need an ability or skill at the beginning but after a while this skill is not required anymore, you need to remove that person from the team when this happens, because if you keep it there it will do almost nothing and slow down the rest of the teammates. Also, each team member needs to feel three things when belonging to a team:
- We belong
- We are in this together
- We support each others’ work, growth, and learning
Team size is also important, 12 is the correct size for a team to know each other and work together correctly, have a certain amount of trust and closeness between them and also, organization is still manageable. On the other hand if you have 150 persons, all of the things listed before can get lost and the team wouldn’t work as good. What you should do in this scenarios is fracture the problem and build smaller teams that focus on a branch of the problem.
The office or workspace should also have some regulations for it to be perfect for the team. When someone enters the workspace, this person should be able to know how things are going, the progress and the things the team is stuck in, all of this in 15 seconds after entering the room or place. The workspace should also provide snacks and encourage positive social interactions, it should have both public and private seats because sometimes a programmer needs some alone time to solve something. The workspace should be ordered and clean so that the programmers only have to focus on the problem at hand and not get distracted by their environment.
Working more hours doesn’t mean more productiveness or finishing the project earlier. We are all human beings and have needs, programming requires us to be relaxed and with a healthy mind. If you are sick or not feeling too well, you should rest and not program, because you will start to remove value from the project without noticing and also you can pass the illness to any of your co-workers and slow the whole team more.
Also, not many people can program for long hours without starting to get tired and not think straight. Set a limit for programming and up it little by little. This will help you to give your 100 percent when you are programming and also be in a good mind state.
This practice is widely known and have a lot of positive effects on the team. Both programmers should be comfortable in this space and be able to communicate easily. Pair programmers:
- Keep each other on task
- Brainstorm refinements to the system
- Clarify ideas
- Take initiative when their partner is stuck, this lowering frustration
- Hold each other accountable to the team’s practices
With this you can also work by yourself and then bring the idea back to the team and develop it with your pair. Keep in mind that pair programming is tiring but satisfying. It is not recommended to pair program for many hours. You should also switch you partner every couple of hours.
Also take in mind the different cultures, an Italian will feel comfortable being close to you but a Dane will like a two feet distance, so keep in mind this culture behaviors. Also, hygiene is important so that people aren’t uncomfortable.
Developing stories is key in XP. This will help you to estimate the project length and also have a clear vision early of what the project will require. All of the stories developed for a project will help you take the correct decisions based on the constraints, both cost and intended use. Kent Beck is a firm believer that projecting the stories in the wall is far better than an electronic board that keeps track of them for you. All of this stories should have the description of what it is needed to do and also the time estimate, if you will need any extra tools or support of any kind.