Extreme Programming Explained

This morning I had the opportunity to read Kent Beck’s delightful work, Extreme Programming Explained 2nd Edition. This is a book by a man who has been in the trenches and has reflected upon his experience for the benefit of all involved in application delivery.

His concern for people is evident throughout, and inspiring.

An effective happy team is the key to productivity, and Kent offers advice on how to create and keep such a team with an emphasis on respect and communication.

There are innumerable nuggets of wisdom, delivered so simply you almost miss them, like “incremental design defers design investment until the last responsible moment”.

A careful look at non-functional requirements can save us from architectural mistakes and address risks early. We must always keep the end in mind, and some prudence is often better than just diving in – how fast do we want the wrong answer?

There is a big difference between refactoring and re-manufacturing because you didn’t think enough about the problem. This book warns against such oversimplification, and raises the distinction between accidental and essential complexity. At the same time it reminds us that knowledge and experience enlighten our decisions and doing just enough now will allow us to capitalise on knowledge accrued during the process.

As a technically inclined person, I am wont to lose myself in technical concerns. This book recommends values, principles and practices which keep the focus on working software, customer requirements, and delivering maximum value to the business.

This is an excellent book and I whole heartedly recommend it.

You can listen to a podcast with Kent Beck here.

Values

Communication:

• What matters most in team software development is communication

Simplicity:

• What is the simplest thing that could possibly work?
• Simple, but not too simple (find constraints, check non-functional requirements, prototype if required)
• Accidental vs Essential complexity

Feedback:

• No fixed direction remains for long
• We may not know how to do it right
• What’s right for today may not be right for tomorrow
• Doing everything “right” may take so long tomorrow’s change invalidates our work
• Improvement to refactor toward goals
• The simpler the system, the eaiser it is to get feedback
• Use feedback to guide the project, if you are getting lots of defects, slow down releases to get back on track
• Is performance going to be a problem? Write a prototype and see

Principles

People:

• People develop software
• What do people need to be good developers? Basic safety, accomplishment, belonging, growth
• Work is still work, keep private matters private

Economics:

• Somebody has to pay for all this
• Business vs technical success
• Solving the highest priority business need first maximises the value of the project
• Economics that affect development are time value of money and option value of systems and teams
• A dollar today is worth more than a dollar tomorrow
• Software is more valuable when it earns money sooner and spends later
• Incremental design defers design investment until last responsible moment to spend money later
• Pay per use provides revenue from features as soon as they are deployed
• Value as options for the future

Mutual Benefit:

• Every action should be concerned about all
• Most important XP principle and difficult to adhere to
• Maintaining working relationships is important
• Extensive documentation slows development
• XP solves the communication-with-the-future problem in mutually beneficial ways: automated tests, refactor to remove accidental complexity, choose names from a coherent and explicit set of metaphors to make code clearer to understand
• If you want people to take your advice, you need to solve more problems than you create

Self-Similarity:

• Cadence
• In a quarter you, you list the themes you want to address and then you address them with stories
• In a week, you list the stories you want to address, write tests expressing the stories, then make them work
• In a few hours, you list the test you know you need to write, then write a test, make it work, write another test, and make them both work until the list is done
• Copy an existing structure you are familiar with and adapt it as required
• Having the system-level tests before you begin implementation simplifies design, reduces stress, and improves feedback

Improvement:

• Perfect is a “verb”
• “Best is the enemy of good enough” suggests that mediocrity is preferable to waiting
• Do the best you can today, striving for the awareness and understanding necessary to do better tomorrow
• It doesn’t mean waiting for perfection to begin
• Translate values to practices

Diversity:

• Teams need to bring together a diversity of skills, attitudes, and perspectives to see problems and pitfalls
• Conflict is the inevitable companion of diversity
• Resolve conflicts productively (creative tension)
• Respecting others and maintaining myself smooths communication in times of stress

Reflection:

• Good teams don’t just do their work, they think about how they are working and why they are working
• No one stumbles into excellence
• Quarterly and weekly cycles include time for team reflection

Flow:

• Flow in software development is delivering a steady flow of valuable software by engaging in all the activities of development simultaneously

Opportunity:

• Learn to see problems as opportunities of change

Failure:

• If you are having trouble succeeding, fail
• Failure may impart knowledge

Quality:

• Sacrificing quality is not effective as a means of control
• Quality is not a control variable
• Projects do not go faster by accepting lower quality

Baby Steps:

• Take small steps, don’t make big changes in big steps
• Big changes are risky

Accepted Responsibility:

• Responsibility cannot be assigned, it can only be accepted
• With responsibility comes authority

Practices (barren without values)

Primary Practices

Sit Together:

• Develop in an open space big enough for the whole team
• Meet the need for privacy and “owned” space
• Facilitates communication and knowledge transfer

Whole Tream:

• Include on the team people with all the skills and perspectives necessary for the project to succeed
• Cross-functional teams
• People need a sense of “team”: we belong, we are in this together, we support each other’s work, growth, and learning
• What constitutes a “whole team” is dynamic
• Twelve is the number of people who can comfortable interact with each other in a day

Informative Workspace:

• Make your workspace about your work
• Story cards on the wall – shows progess/state
• Water/snacks/cleanliness/etc
• Big visible charts

Energized Work:

• Work only as many hours as you can be productive and only as many hours as you can sustain
• Burning yourself out unproductively today and spoiling the next two day’s work isn’t good for you or the team

Pair Programming:

• Keep each other on task
• Brainstorm refinements to the system
• Clarify ideas
• Take initiative when partner is stuck, frustrated
• Hold each other accountable to the team’s practices
• Rotate pairs frequently.
• Personal hygiene and health are important

Stories:

• Plan using units of customer-visible functionality
• As soon as a story is written, try to estimate the development effort necessary to implement it
• Give short story names in addition to a short prose or graphical description
• Every attempt I’ve seen to computerise stories has failed to provide a fraction of the value of having real cards on the wall
• If you need to report progress, translate cards into an electronic format periodically
• Estimates done early gets people thinking
• Adding new constraints clears the picture

Weekly Cycle:

• Plan work a week at a time
• Have a meeting at the beginning of every week:
  • Review progress to date, including how actual progress for the previous week matched expected progress
  • Have the customer pick a week’s worth of stories to implement this week
  • Break the stories into tasks. Team members sign up for tasks and estimate them
  • Start the week by writing automated tests that will run when stories are completed
• Spend the rest of the week completing the stories and getting the tests to pass
• The goal is to have deployable software at the end of the week, everyone can celebrate progress
• Everybody is focused on Friday
• The team’s job – programmers, testers, and customers together – is to write the tests and then get them to run in five days. If you get to Wednesday and it is clear that all the tests won’t be running, the stories won’t be completed and ready to deploy, you still have time to choose the most valuable stories and complete them
• Planning is a form of necessary waste
• Work on gradually reducing the percentage of time you spend planning
• Break stories into tasks that individuals take responsibility for and estimate
• Ownership of tasks goes a long way towards satisfying the human need for ownership

Quarterly Cycle:

• Plan work a quarter at a time
• During quarterly planning:
  • Identify bottlenecks, especially those controlled outside the team
  • Initiate repairs
  • Plan the theme or themes for the quarter
  • Pick a quarter’s worth of stories to address those themes
  • Focus on the big picture, where the project fits within the organisation
• The separation of “themes” from “stories” is intended to address the tendency of the team to get focused and excited about the details of what they are doing without reflecting on how this week’s stories fit into the bigger picture
• Themes fit well into larger-scale planning such as drawing marketing road-maps
• Quarters are a good interval for team reflection

Slack:

• In any plan, include some minor tasks that can be dropped if you get behind
• You can always add more stories later and deliver more than you promised
• It is important in an atmosphere of distrust and broken promises to meet your commitments
• A few met commitments go a long way toward rebuilding relationships
• Avoid Overcommitment, unmanageable defect loads, dismal morale, and antagonistic relationships
• Meeting commitments, even modest ones, eliminates waste
• Clear honest communication relieves tension and improves credibility
• One week in 8 could be “geek week”
• 20% of budget could go to programmer-chosen tasks

Ten-Minute Build:

• Automatically build the whole system and run all of the tests in ten minutes

Continuous Integration:

• Integrate and test changes after no more than a couple of hours
• Team programming is a divide, conquer, and integrate problem
• The longer you wait to integrate, the more it costs and the more unpredictable the cost becomes

First-Test Programming:

• Write a failing automated test before changing any code
• Avoids scope creep-”just in case code”. You state explicitly and objectively what the program should do
• Improves coupling and cohesion – if it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem
• Trust = clean code that works and demonstrates your intentions with automated tests
• Rhythm – avoids getting lost in code, it’s easy to see what is next

Incremental Design:

• Invest in the design of the system everyday
• Strive to make the design of the system an excellent fit for the needs of the system that day
• When your understanding of the best possible design leaps forward, work gradually but persistently to bring the design back into alignment with your understanding
• XP teams work hard to create conditions under which the cost of changing software doesn’t rise catastrophically
• The last responsible moment
• Keep the design investment in proportion to the needs of the system as is
• Incremental design suggests that the most effective time to design is in the light of experience
• DRY – Don’t repeat yourself

Corollary Practices

Real Customer Involvement:

• Make people whose lives and business are affected by your system part of the team
• Visionary customers can be part of quarterly and weekly planning
• They can have a budget, a percentage of the available development capacity, to do with as they please
• The point of customer involvement is to reduce wasted effort by putting the people with the needs in direct contact with the people who can fill those needs
• Whole Team implies customer involvement

Incremental Deployment:

• Every once in a while a big deployment works
• Find a little piece of functionality, or a limited data set you can handle right away. Deploy it

Test Continuity:

• Keep effective teams together
• Value in software is created not just by what people know and do but also by their relationships and what they accomplish together
• Ignoring the value of relationships and trust just to simplify the scheduling problem is false economy

Shrinking Teams:

• As a team grows in capability, keeps its workload constant, but gradually reduce its size. This frees people to form more teams
• When the team has too few members, merge it with another too-small team. This is a practice used by the Toyota Production System

Root-Cause Analysis:

• Every time a defect is found after deployment, eliminate the defect and its cause

Shared Code:

• Anyone on the team can improve any part of the system at any time

Code and Tests:

• Maintain only the code and the tests as permanent artifacts
• Generate other documents from the code and tests
• Rely on social mechanisms to keep alive important history of the project
• Customers pay for what the system does today and what the team can make the system do tomorrow
• Code and tests, everything else is a waste

Single Code Base:

• There is only one code stream
• Never let temporary branches live longer than a few hours
• Don’t make more versions of your source code

Daily Deployment:

• Put new software into production every night
• Any gap between what is on a programmer’s desk and what is in production is a risk

Negotiated Scope Contract:

• Write contracts for software development that fix time, costs, and quality but call for an ongoing negotiation of the precise scope of the system
• Reduce risk by signing a sequence of short contracts instead of a long one
• You can move in the direction of negotiated scope

The Whole XP Team

Testers:

• Testers help customers choose and write automated system-level tests in advance of implementation and coach programmers on testing techniques

Interaction Designers:

• Choose metaphors
• Write stories
• Evaluate the usage of the deployed system to find opportunities for new stories
• Addressing concerns of eventual users is a priority for the team

Architects:

• Look for and execute large-scale refactoring
• Write system-level tests that stress architecture
• Implement stories
• Gradual persistent changes
• Partition systems upfront

Project Managers:

• Facilitate communication inside the team and coordinate communication with customers, suppliers, and the rest of the organisation
• Team historians
• Progress tracking
• Present material to stakeholders, executives, etc.
• Planning is an activity, not a phase
• Keep plans realistic

Product Managers:

• Write stories, pick themes and stories in quarterly cycle, pick stories in weekly cycle
• Answer questions as implementation uncovers under-specified areas of stories
• Stories should be sequenced for business, not technical reasons
• The goal is working software from the first week
• System should be “whole” at the end of the first weekly cycle
• Pick stories to make this happen

Users:

• Help write and pick stories
• Make domain decisions during development
• Must speak for entire community, not self only

Programmers:

• Estimate stories and tasks
• Break stories into tasks
• Write code to implement features
• Automate tedious development process
• Gradually improve the design of the system
• Close technical collaboration with each other

Planning

• Planning makes goals and directions clear and explicit
• Start with current goals, assumptions, and facts on the table
• Budget is the amount of available time – how many stories can you buy?
• What to do next?
• Planning is daily, weekly, quarterly
• Make scope variable
• Plan at each timescale with these 4 steps:
• List the items that may need to be done
• Estimate the items
• Set a budget for the planning cycle
• Agree on the work that needs to be done within the budget. As you negotiate, don’t change the estimates or the budget
• Everyone on the team needs to be heard, planning is a forum
• “Complete” means ready for deployment: testing, implementation, refactoring, and discussions with users
• As knowledge increases, estimates will improve
• Estimates based on experience are more accurate
• Get feedback on estimates ASAP
• If you have a month to plan a project in detail, spend it on 4 x 1-week iterations developing while you improve your estimates
• If you have a week to plan a project, hold 5 x 1 day iterations
• Gain this experience as soon as possible so your estimates improve
• This provides the items (stories) and prices (estimates)
• How do you establish the budget (time to completion and size of team) – Measure how many productive programmer hours in an average week, divide by 2 for pairing
• “yesterday’s weather” – plan according to last week’s velocity
• If progress is slower than planned then look for ways to realign the plan. keep it real
• Inaccurate estimates are a failure of information, not of values or principles

Designing

The Value of Time:

• Incremental design is a way to deliver functionality early and continue delivering functionality weekly for the life of the project
• Experience creates the most value, do just enough today to leverage experience tomorrow

Advertisement