XP Principles Part 2

In this post I will be talking about Kent Beck’s Extreme Programming Explained book, specifically Chapter 5, in this chapter we will talk about XP principles.

Flow

The principle of flow suggests that for improvement, deploy smaller increments of value more frequently. Many teams tend to deploy big chunks of progress but not that often instead of small deploys but more frequently.

Also, if your team is not making a correct deployment before the next one comes then you can extend your deployment time but keep in mind that you need to resolve this issue in order to return to the original deployment time, take this time to analyze why do the deploys take so much time and solve it.

Opportunity

Learn to see problems as opportunities for change. To reach excellence, problems need to turn into opportunities for learning and improvement. Turning problems into opportunities takes place across the development process. It maximizes strengths and minimizes weaknesses.

As you begin practicing XP, you will certainly encounter problems. Part of being extreme is consciously choosing to transform each problem into an opportunity: an opportunity for personal growth, deepening relationships, and improved software.

Redundancy

Defects are addressed in XP by many of the practices: pair programming, continuous integration, daily deployment, etc. Even if your partner doesn’t catch an error, someone else sitting across the room might or it might be caught by the next integration. Some of these practices are redundant, because they catch almost the same defects.

Redundancy can be wasteful, but be careful not to remove redundancy that serves a valid purpose. Having a testing phase after development is complete should be redundant. However, eliminate it only when it is proven redundant in practice by not finding any defects several deployments in a row.

Failure

Failure is no waste if it imparts knowledge, if you are stuck in trying to decide which of 3 ways you can implement something, implement all of them, even if they fail, you’ll certainly learn something valuable.

Knowledge is valuable and sometimes hard to come by. Failure may not be avoidable waste. When you don’t know what to do though, risking failure can be the shortest, surest road to success.

Quality

Sacrificing quality is not effective as a means of control. Projects don’t go faster by accepting lower quality or slower by demanding higher quality. Pushing quality higher often results in faster delivery; while lowering quality often results in slower and less predictable delivery.

Quality isn’t a purely economic factor. People need to do work they are proud of. There’s an example of the manager of a mediocre team. He went home on the weekends and made fancy ironwork as a blacksmith. He met his need for quality; he just met it outside of work.

A concern for quality is no excuse for inaction. If you don’t know a clean way to do a job that has to be done, do it the best way you can. If you know a clean way but it would take too long, do the job as well as you have time for now. Resolve to finish doing it the clean way later. This often occurs during architectural evolution, where you have to live with two architectures solving the same problem while you transition from one to the other. Then the transition itself becomes a demonstration of quality: making a big change efficiently in small, safe steps.

Baby Steps

It’s always tempting to make big changes in big steps. After all, there’s a long way to go and a short time to get there. Momentous change taken all at once is pretty dangerous.

Baby steps do not justify slow production. Under the right conditions, people and teams can take many small steps so rapidly that they appear to be leaping.

Accepted Responsibility

Responsibility can’t be assigned, it need to be accepted by that person because if that person doesn’t accepts it then it will not get done correctly. Also, responsibilities should go hand-in-hand, if someone is responsible for implementing a story, they are also responsible of the design, implementation, and testing.