One of the books I’ve read this month is….
Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series)
by Kent Beck, Cynthia Andres
Read more about this title…
I really enjoyed reading this book. It paints a picture of what an ideal XP team can look like and talks about the principals, practices and values of XP. I’d like to share some excerpts from the book that really stuck out and hand an impact on me.
“If you have six weeks to get a project done, the only thing you can control is your own behavior. Will you get six weeks’ worth of work done or less? you can’t control others’ expectations. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It’s not my job to “manage” someone else’s expectations. It’s their job to manage their own expectations. It’s my job to do my best and to communicate clearly.”
One of the things I learned about myself is that I hate being late. This isn’t a great trait to have in the world of software development. When I’m handed a deadline I become so eager to meet it that in the process of racing to the deadline quality is compromised. I can’t control deadlines or others expectations but I can control my own behavior and if I work consistently as hard as I can without letting go of quality.
“I chose practices for XP because they meet both business and personal needs. There are other human needs; such as rest, exercise, and socialization; that don’t need to be met in the work environment. Time away from the team gives each individual more energy and perspective to bring back to the team. Limiting work hours allows time for these other human needs and enhances each person’s contributions while he is with the team.”
It sucks how XP and Agile have become buzzwords in the industry that mean more to the marketing department then to the software developers. I’ve said it before and I’ll say it again…
“You aren’t doing Agile. YOU ARE AGILE!”
“Part of the challenge of team software development is balancing the needs of the individual with the needs of the team. The team’s needs may meet your own long-term individual goals, so are worth some amount of sacrifice. Always sacrificing your own needs for the team’s doesn’t work. If I need privacy, I am responsible for find a ways to get my need met in a way that doesn’t hurt the team. The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together.”
You’ve got to sacrifice something, regardless of context you’re talking about, in order to succeed. What’s important is deciding on what you’re willing to sacrifice in order to get closer to your end goals. I have found that pushing the people outside of their comfort zone a little bit not only helped me in growing but also the team as a whole. I also learned that it’s important to slow down and reflect. The up and down rhythm of an XP team is balanced by the different members of a team, and with trust it’s much easier to maintain that balance.
E.G. Team member A might be a hardcore, heads down, must punch out code as efficiently as possible. Team member B may be more of a let’s take it a little slower and sit back and think about the problem at hand kind of guy. With trust the two team members will be able to develop a rhythm that keeps the project going at a sustainable pace without sacrificing quality.
“I trust two metrics to measure the health of XP teams. The first is the number of defects found after development. An XP team should have dramatically fewer defects in its first deployment and make rapid progress from there. Some XP teams that have been on the path of improvement for several years see only a handful of defects per year. No defect is acceptable; each is an opportunity for the team to learn and improve.”
Test-driven development/design rather then design in your head driven code. The test is a clear statement of truth. It documents the design that would otherwise be locked up in your head and is very black of white about whether or not the subject under test satisfies the test specification or behavior that is expected. If the team is not disciplined even the best of the best XP teams can forget about the principals behind the practices, and stop following the practices. One of the most important things about unit tests is the early feedback. I want to know as soon as possible when a component in the system is not behaving as expected. By waiting for QA to pick out bugs, then log a bug, then assign a developer to look at the bug does not deliver early feedback, I consider this waste! It’s a vicious cycle that can be reduced greatly.
“The problem with reviews is that most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help others if he will be evaluated on individual performance?”
Out of all the chapters in this book I think chapter 3 is my favorite. It’s titled “Values, Principles, and Practices”, and to me it speaks the loudest of what is XP and why would we want to consider using it as a methodology for building and delivering software.
I highly recommend this book!