Status Updates From Extreme Programming Explain...

Its all about processes

What a read!

Starting Chapter 14 "Designing: The Value of Time"

Starting Chapter 11 The Theory of Constraints

Start Chapter 10.

I learned of XP a long time ago. I even read portions of it on the c2 wiki. I miss the old language, and find this version wordy. I think I understand why, but I still miss the old language.

Unlike Scrum, XP doesn't have to be "all or nothing" and can start at the team or even individual level. From one perspective, it HAS to start at the individual level.

I've adopted a lot of this over the years but I've never sat down and read the book per se. It's far more humble and human than I expected!

On chapter 10

On Chapter 9

29

Planning and testing the xp way

Rereading
Values, principles, practices, adaptability.

Reading it again

Continuous improvement means continuous awareness, responsiveness to feedback, and openness to improvement

Important activities can become or generate waste if we don't use their output immediately in order to get the feedback we need to eliminate waste

Case study... With Kent Back, Ron Jeffries and Martin Fowler on the team. Wow!

Strong words from a senior VP of an airline - "If programmers won't pair or if they insist on owning code, have the courage to fire them."

Conquer-and-divide rather than divide-and-conquer (large problems). Basis in autonomous teams that work independently (system integrates frequently). Occasional exceptions where teams need to coordinate are managed as exceptions. If too much time spent coordinating, look to how the system can be restructured to support independent teams. Only if this fails is large project mgt overhead appropriate.

100 people can't plan their work in detail in a single weekly meeting. 100 people CAN work together in a spirit of communication, feedback, simplicity, courage and respect.

Design Simplicity = 1) Appropriate for the intended audience (the ppl who need to work with it, understand it); 2) Communicative (system communicates ideas to future readers); 3) Factored (duplication removed); and 4) Minimal (as few elements as possible within the three constraints above)

Database design strategy

Design quality doesn't ensure success, but design failure can ensure failure

Fundamental flaw in the building construction metaphor: it is extremely difficult to reverse progress in the construction world. ... Huge costs in tossing a poured concrete slab; to reverse a day of software you only lose the cost of the day it took to write it.

Plans are not predictions of the future. At best they express everything you know today about what might happen tomorrow ( Kent Beck)


Lowering the quality of your work doesn't eliminate work, it just shifts it later so delays are clearly not your responsibility

Chapter 11 is a great chapter on the Theory of Constraints using laundry as an example

Everyone on the team can recommend changes, but they should be prepared to back up their concerns with action

Valuable employees act respectfully, play well with others, take initiative, and deliver on their commitments

Programmers work in close technical collaboration with each other, pairing on production code, so they need to develop good social and relationship skills

The hum of conversation is a sign of health. Silence is the sound of risk piling up.