About two years ago, when working for Net-a-Porter, I met a XP coacher. He came to help us because the team had been failing to deliver on time for several continuing weeks. We had already tried Scrum and Kanban, and neither of them seemed to solve this situation. I don’t blame Scrum or Kanban, but the poor knowledge the team had about them at that time. Therefore, the XP coacher (Ivan Moore) came and introduced us to the XP methodology. It was unbelievable what a positive effect it had on the team. After a few days, the methodology came clear to us because it was explained neatly and simply. The team started focusing on the most valuable end-to-end features for the business, as a result we were able to deliver in two weeks. For the first sprint, I think we put only a couple of end-to-end features. I placed emphasis on the “end-to-end” because that was one of the positive changes we made with XP. Before, the team got lost in many infrastructures, maintenance and other features that came out as a result of working on a business feature. With XP and focus only on a couple of business features, it was easier to deliver them, and so the team was successfully able to deliver value to business again, and we all felt confident and worthy for the business.
Ivan Moore recommended me the book above to learn more about the XP, and I have read it, and here I leave the most important details about the XP methodology according to the book.
Section1: The Problem
Chapter 1. Risk: The Basic Problem
“Software development fails to deliver, and fails to deliver value. This failure has huge economic and human impact. We need to find a new way to develop software”.
- Schedule slips. XP calls for short release cycles. A few months at most, so the scope of any slip is limited.
- Project cancelled. XP asks the customer to choose the smallest release that makes the most business sense, so there is less to go wrong before going into production and the value of the software is greatest.
- System goes sour. XP creates and maintains a comprehensive suite of tests, which are run and re-run after every change (several times a day) to ensure a quality baseline.
- Defect rate. XP test from both programmers writing tests (function by function) and customers writing tests (feature by feature).
- Business misunderstood. XP calls for the customer to be an integral part of the team.
- Business changes. XP shortens the release cycle, so there is less change during the development of a single release.
- False feature rich. XP insists that only the highest priority tasks are addressed.
- Staff turnover. XP asks programmers to accept responsibility for estimating and completing their own work, gives them feedback about the actual time taken so their estimates can improve, and respects those estimates. The rules for who can make and change estimates are clear. Thus, there is less chance for a programmer to get frustrated by being asked to do the obviously impossible.
Chapter 2: A development episode
- Development is driven by tests. When all your tests run, and you can’t think of any more tests that would break, you are done.
Chapter 3: Economics of Software development
- We need to make our software development economically more valuable by spending money more slowly, earning revenue more quickly, and increasing the probable productive lifespan of our project. But most of all we need to increase the options for business decision.
Chapter 4: Four Variables
- We will control four variables in our projects – cost, time, quality, and scope. Of these, scope provides us the most valuable form of control.
- Cost: All the constraints on cost can drive mangers crazy. Especially if they are focused on an annual budgeting process, they are so used to driving everything from cost that they will make big mistakes ignoring the constraints on how much control cost gives you.
- Quality: Temporarily sacrificing internal quality to reduce time to market in hopes that external quality won’t suffer too much is a tempting short-term play. Eventually, though, internal quality problems will catch up with you and make your software prohibitively expensive to maintain, or unable to reach a competitive level of external quality.
- If you deliberately downgrade quality, your team might go faster at first, but soon the demoralisation of producing crap will overwhelm any gains your temporarily made from not testing, or not reviewing, or not sticking to standards.
- Focus on Scope: Less snakes it possible to deliver better quality (as long as the customer’s business problem is still solved). It also lets you deliver sooner or cheaper.
- For software development, scope is the most important variable to be aware of.
- The requirements are never clear at first. Customers can never tell you exactly what they want.
- What if we see the softness of requirements as an opportunity, not a problem?
- If you dropped important functionality at the end of every release cycle, the customer would soon get upset. To avoid this, XP uses two strategies:
- Better estimates reduce the probability that you will have to drop functionality.
- You implement the customer’s most important requirements first, so if further functionality has to be dropped it is less important than the functionality that is already running in the system.
Chapter 5: Cost of Change
- One of the universal assumptions of software engineering is that the cost of changing a program rises exponentially over time.
- The problem is that this curve is no longer valid. Or rather, with a combination of technology and programming practices, it is possible to experience a curve that is really quite the opposite.
- Keeping the cost of change low doesn’t just happen magically.
- What makes our code easy to modify, even after of production:
- A simple design, with no extra design elements – no ideas that weren’t used yet but were expected to be used in the future.
- Automated tests, so we have confidence we would know if we accidentally changed the existing behaviour of the system.
- Lots of practice in modifying the design, so when the time came to change the system, we weren’t afraid to try it.
- We can create an approach to software development that makes each decision quickly, but backs each decision with automated tests, and that prepares you to improve the design of the software when you learn a better way to design it.
Chapter 6: Learning to Drive
“We need to control the development of software by making small adjustments, not by making a few large adjustments, kind of like driving a car.”
Chapter 7: Four Values
“communication, simplicity, feedback and courage”
- The effect of testing, pairing and estimating is that programmers and customers and managers have to communicate.
- What is the simplest thing that could possibly work?
- Not to look toward the things you’ll need to implement tomorrow and next week and next month.
- XP says that is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, that to do a more complicated thing today that may never be used anyway.
- The simpler your system is, the less you have to communicate about, which leads to more complete communication, especially if you can simplify the system enough to require fewer programmers.
- “Don’t ask me, ask the system” and “Have you written a test case for that yet?”
- You are going to have to live with supporting production and developing new functionality simultaneously. Better to get used to juggling production and development sooner rather than later.
Chapter 8: Basic Principles
- Rapid feedback
- To get feedback, interpret it, and put what is learned back into the system as quickly as possible.
- Assume simplicity
- Treat every problem as if it can be solved with ridiculous simplicity. We are traditionally told to plan for the future, to design for reuse. Instead, XP says to do a good job (tests, refactoring, communication) of solving today’s job today and trust your ability to add complexity in the future where you need it.
- Incremental change
- Big changes made all at once just don’t work.
- Embracing change
- Quality work
- Teach learning
- Small initial investment.
- Too many resources too early in a project is a recipe for disaster.
- Play to win.
- The difference is between playing to win and playing not to lose. Most software development I see is played not to lose. Lots of paper gets written. Lots of meetings are held. Everyone is trying to develop “by the book”, not because it makes any particular sense, but because they want to be able to say at the end that it wasn’t their fault, they were following the process.
- Software development played to win does everything that helps the team town and doesn’t do anything that doesn’t help to win.
- Concrete experiments
- Every time yo make a decision and you don’t test it, there is some probability that the decision is wrong. The more decision you make, the more these risks compound. Therefore, the result of a design session should be a series of experiments addressing the questions raised during the session, not a finished a design.
- Open, honest communication
- To be able to tell each other where there are problems in the code. To be free to express their fears, and get support. To be free to deliver bad news to customers and management, to deliver it early, and not be punished.
- Work with people’s instincts, not against them.
- People like winning.
- People like learning
- People like interacting with other people.
- People like being part of a team.
- People like being in control.
- People like being trusted.
- People like doing a good job
- People like having their software work.
- Accepted responsibility
- Local adaptation
- You have to adapt whatever you read in this book to your local conditions.
- Adoption XP does not mean that I get to decide how you are going to develop. It means that you get to decide how to develop. I can tell you what I have found to work well.
- Travel light
- You can’t expect to carry a lot of baggage and move fast. The artifacts we maintain should be:
- You can’t expect to carry a lot of baggage and move fast. The artifacts we maintain should be:
- Honest measurement
Chapter 9: Back to Basics
“The four activities of development are coding, testing, listening and designing”
- The first step is to decide on the scope. What is it that we will try to prescribe? What sorts of problems will we address and what sorts of problems will we ignore?
- When most people thing of automated tests, they think of testing functionality – that is, what numbers are computed. The more experience I get writing tests, the more I discover I can write tests for non-functional requirements – like performance or adherence of code to standards.
- “Test Infected”, it describes people who won’t code if they don’t already have a test. The tests tell you when you are done – when the tests run, you are done coding for the moment. When you can’t think of any tests to write that might break, you are completely done.
- Tests keep the program alive longer (if the tests are run and maintained). When you have the tests, you can make more changes longer than you can without the tests. If you keep writing the tests, your confidence in the system increases over time.
- Programming when you have the tests is more fun than programming when you don’t.
- Testing done badly becomes a set of rose-coloured glasses. You gain confidence that your system is okay because the tests all run.
- We will have unit tests written by the programmers to convince themselves that their programs work the way they think the programs work.
- We will have also functional tests written by the customers to convince themselves that the system as a whole works the way they think the system as a whole should work.
- Good design organises the logic so that a change in one part of the system doesn’t always require a change in another part of the system.
- Good design ensures that every piece of logic in the system has one and only one home.
- Good design puts the logic near the data it operates on.
- Good design allows the extension of the system with changes in only one place.
- Complexity is another source of bad design.
Section2: The Solution
Chapter 10: A Quick Overview
- The story about learning to drive
- the four values: communication, simplicity, feedback, and courage
- The principles
- The four basic activities: coding, testing, listening and designing
- The Planning Game: Quickly determine the scope of the next release by combining business priorities and technical estimates.
- Small releases: Put a simple system into production quickly, then release new versions on a very short cycle.
- Metaphor: Guide all development with a simple shared story of how the whole system works.
- Simple design: The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.
- Testing: Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that futures are finished.
- Refactoring: Programmers restructure the system without changing its behaviour to remove duplication, improve communication, simplify or add flexibility.
- Pair programming: All production code is written with two programmers at one machine.
- Collective ownership: Anyone can change any code anywhere in the system at any time.
- Continuous integration: Integrate and build the system many times a day, every time a task is completed.
- 40-hour week: Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.
- On-site customer: Include a real, live user on the team, available full-time to answer questions (Product owner).
- Coding standards: Programmers write all code in accordance with rules emphasising communication through the code.
The Planning Game
- Composition of releases
- Dates of releases
- technical consequences, such as, why to use a NOSQL db rather than a SQL one.
- the team needs to fit the culture in which it will operate.
- Detailed scheduling
- Within a release, which stories will be done first? reducing the chance that important stories will have to be dropped toward the end of the development of a release.
- Every release should be as small as possible, containing the most valuable business requirements. The release has to make sense as a whole – that is, you can’t implement half a feature and ship it, just to make the release cycle shorter. Reduce the cycle as much as possible.
- By asking for a metaphor we are likely to get an architecture that is easy to communicate and elaborate.
- Runs all the tests.
- Has no duplicated logic. Be ware of hidden duplication like parallel class hierarchies.
- States every intention important to the programmers.
- Has the fewest possible classes and methods.
That’s all for now. This is a work in progress… You will find more about it in the coming few days.