With this installment of our re-read of Extreme Programing Explained, Second Edition (2005) we are exactly halfway through the book. We will have seven more installments including one week for an entry for overall reflections on the book. It is time to start thinking about what is next; a re-read or a new read? Thoughts? In this week’s we tackle two concepts central to XP; planning and testing, both done the XP way.
Chapter 12 Planning: Managing Scope
Beck begins chapter twelve by pointing out that the state of a team’s shared plan provides clues about the state of the relationship between people affected by the plan. This is a new statement in this edition; however, even during my first read of XP Explained the approach to planning was radical in its inclusiveness. Well before I learned Scrum, XP planning began to rewrite how I worked with teams.
In XP, planning is a tool to make goals and directions clear. Plans are a tool to help a team organize and communicate the team’s intent for addressing the future based on variables such capabilities, cost value and duration. Plans reflect what we want the future to look like rather than exactly how they will unwind. XP Explained uses the metaphor of grocery shopping with a fixed amount of money to explain planning in XP. Doing your weekly shopping with a fixed budget constrains what you can buy. This hits quite close to home. A few times in my life my wife and I have created a weekly budget for food in which we would take cash money out of the bank and put it into an envelope. In this scenario when the envelope is empty, we are done shopping. If we decide while walking down the aisle of our local grocer to have a dinner of pâté de foie gras and caviar most everything else in the cart would have to go back on the shelf. In a less extreme scenario, my wife and I decided to invite several people for hamburgers on the grill (actually a true scenario). In order to get the extra few pounds of ground beef and stay within the budget, we traded the grade of ground beef for one with a higher fat content. A substitution of quantity for quality. Planning in XP is no different. XP teams plan within a set of fixed constraints. In XP, the planning constraints include a fixed team size and a fixed weekly cycle. The primary variable an XP team has in planning (in our example, a number of groceries they can buy) is the amount of work they can do. In software development, unlike my grilling party, tweaking quality in software development is generally a fool’s errand. Albeit if effort, date and work required are all fixed, quality is the variable that gets tweaked so the team can deliver. When teams take shortcuts that affect quality they are merely postponing work (or sloughing it off on someone else – a moral hazard).
The XP Planning process is:
- Develop a backlog of work that may need to be done.
- Estimate the items on the backlog
- Set a budget for the planning cycle (this is the amount of work the team can commit to delivering during the cycle)
- Agree on the work that needs to be done within the budget, as you negotiate don’t change the estimates for the budget.
What gets agreed upon in the planning process will be shaped by a number of things. In a perfect world the stories with the highest value would always be done first; however, risks, technical constraints, and even office politics can impact the order a team pulls work into a cycle. That said, the team should not change estimates during planning, change their budget of work to accept or change the duration of the cycle. As with shopping for groceries, stretching the constraints in the short run will always have some impact down the road.
One the most powerful statements about the planning process is Beck’s assertion that planning is an exercise in which everyone on the team participates. Participation includes listening, speaking and learning. Once the plan is established, the plan is not carved in stone. As teams assess their progress they are generating feedback that should be used to guide the team and to make future estimates and plans more useful. Beck references Martin Fowler’s concept of “yesterday’s weather” as a tool for improving estimation. Yesterday’s weather is a planning strategy in which a team uses the amount of work completed in the last cycle to plan the next cycle as a technique to leverage feedback and new information.
As Chapter 12 concludes, Beck makes the case for the team to plan using analog cards placed on a wall in a team room (or another area). Transparency in the process is useful to making sure the whole team is involved and the tension between those who want work done and those that have to do the work is continuously tuned and balanced.
Chapter 13 Testing: Early, Often, and Automated
Defects are bad. Defects are bad for lots of reasons. Beck highlights the fact that defects destroy the trust needed for effective software development. I once went on a job interview where the CIO had four pagers (it was a few years ago). When I asked about the collection of hardware on his belt, he indicated that each major department wanted to be able to get his attention when (not if) they had problems. The inability of the business to trust that they would get functional software caused everyone in the department including the CIO to create mechanisms for defending themselves against the eventuality that someone would make a mistake. Defects represent a HUGE time sink and testing defects out just adds to the expense.
Two of the goals of development in XP include reducing the occurrence of defects to an economically sustainable level and to reduce the occurrence of defects to a the level that trust can be established. Reducing the occurrence of defects is a balance between the costs of the tasks needed to avoid defects and the costs to fix them after they occur. Costs include money, effort and calendar time. Another goal of XP development is to reduce the occurrence of defects to a level where trust can reasonably grow on the team. The occurrence of defects makes it difficult to meet commitments between team members and with the business. Improving trust energizes everyone involved with a project. Based on these goals XP uses two principles as tools to increase the cost effectiveness of testing (the term testing is being used in its broadest technical definition). The two principles are double checking and the concept of Defect Cost Increase.
Double checking is a fairly simple concept that every person has used. Adding a column of numbers up twice is a form of double checking, as is testing (the developer writes a code and reviews it and then unit tests the code). Double checking works under the principle that checking the work two different ways significantly increases the chance of finding defects.
The second principle XP leverages to attain its goals for reducing defects and increasing trust is Defect Cost Increase (DCI). DCI posits that the sooner you find a defect, the cheaper it is to fix. The reason defects are easier to fix when they are discovered earlier includes a lower chance that developers will forget where the fix should be made and reduction in the chance that other changes will need to be rolled back (we will review this assertion in the future). DCI suggests that establishing shorter cycles and faster feedback loops will make finding and correcting defects less expensive while weeding out many residual defects.
Double checking and using shorter cycles and feedback loops to reverse DCI provides the basis for incorporating test-first development in XP. Test-first development (TFD) is an approach to development in which developers do not write a single line of code until they have created the test cases needed to prove that unit of work solves the business problem and is technically correct at a unit-test level. TFD creates a double-checking learning cycle so that defects are found quickly and so that the team learns fast.
Writing tests before writing code involves testers earlier in the life cycle, which allows testing resources more leverage to improve the code. There are numerous additional reasons why TFD and its cousins test-driven (TDD), acceptance test-driven (ATDD) and behavior-driven development (BDD).
Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday: