Are you Really Doing Agile Development?
So recently at work I was asked help to make the company more "Agile." Well I'm a developer first and process wonk second so I responded with my usual "How many of the 12 practices are you really following?" Which was met with a lot blank stares. Turns out the classic XP practices are not so easy to find on the internet anymore. It also turns out that the word "Agile" has been so successful that lots of people don't know that XP stands for Extreme Programming. Now I'll be the first to admit that "Extreme Programming" is a colossally stupid name, but what I like about XP and the original 12 practices is that they were controversial and easy to evaluate: Either you were doing them or you weren't. What I don't like about "Agile" is that it's so broad and defined in such a "hand wavy" way that pretty much everyone can fool themselves into thinking that they already are fully Agile.
So to fix this and help my company start measuring their "Agility" better, I've decided to list out classic (They've changed over time -- but not for me. And get off my lawn!) 12 XP processes. And my highly opinionated view of each of them. After that I'll tell you how to score your "Agility."
* Planning Game
Get requirements from customer, form them into (short) stories, estimate the time it will take, do them, measure velocity, examine failed estimates for clues as to how to estimate better, and repeat. A story should be a placeholder for a conversation -- This only works if the customer (or surrogate) is highly available to the developers and the developers take advantage of that availability by checking in frequently during the development process. Note: Stories that take longer than a day significantly undermine many of the other parts of XP.
* Small Releases
Iterations should be 1-2 weeks (depending on how painful/expensive it is to organize an iteration). Releases should happen after every iteration if the application is easy to deploy (web apps).
* Metaphor
Nobody does this. Extra points if you do.
* Simple Design
This means different things at different levels. When kicking off a green field project a week of requirements gathering and design is good. For an individual story, a few minutes to an hour is good. Then you start writing code. Important: Design as you go. Stopping to spend a few hours with a whiteboard is allowed and encouraged. Do the simplest thing that could possible work until it becomes apparent that it will not. Then redesign. The idea is that at the beginning of the project you know the least about it -- spread the design across the life of the project so you can make design decisions with more knowledge.
* Testing
Test first. Coverage above 80% for Java, 90% for Ruby (less exception checking in Ruby means easier to cover). Non-brittle, atomic, fast tests (unit tests should run under 5 min. Actually under 1 minute is best, but most think that's impossible (spoiler: Its possible)).
* Refactoring
Short: Red, Green, Refactor! Long: Write a failing test, make it pass, refactor the code. This also means when you wander into a messy place you leave it a little better than you found it.
* Pair Programming
Above 80% of the time. Seriously. Tasks that seem like you can't pair on them often mean that you aren't using the right pairing techniques. Pairing is a skill: Get good at it.
* Collective Code Ownership
Anyone can change any code. Yes, they should consult whoever is knowledgeable about said code, but there are no parts of the code that only developer X is allowed to touch.
* Continuous Integration
Every check-in to the remote repository triggers a comprehensive suite of unit tests. The developers have to care if the build fails. For example: When the build fails, no one checks in until it is fixed. Also there should be some social ridicule for the build breaker (have to wear a stupid hat for the rest of the day, an obnoxious build breaker trophy placed on their desk, they have to buy donuts for the team, etc.). This all assumes that the build is reliable and that a failure means there is a real problem.
* 40-hour Week
Now called "Sustainable Pace" because "40-hour Week" tends to scare managers and end of project pushes are sometimes necessary even in XP. This should be no more than 2 weeks, have a clearly defined point at which the long hours will stop, and happen no more than twice a year. Actually, if it happens twice a year it means your estimation skills need to get better.
* On-site Customer
Doesn't happen often for non-internal projects. Usually customer surrogates are used. These surrogates need to take pains to talk to real users often (not just the managers of the users) and be highly available to developers to answer questions.
* Coding Standards
Doesn't matter what they are but the developers need to come to a consensus and stick to it. Consensus does not mean everyone nods yes in the meeting but ignores the standards when they feel like it.
So how do I score my Agility? Take the number of practices that you actually do, divide by 12, and then multiple by 100 -- that's your percent Agile. Do not give yourself a point if you don't fully implement a practice. Have Continuous Integration but some of the tests fail randomly? No point. You pair "when necessary" which ends up being 40% of the time. No point! Run iterations but don't estimate your stories? No Point!!
This is take a hard look at yourself in the mirror time, not some hippie love fest.
So to fix this and help my company start measuring their "Agility" better, I've decided to list out classic (They've changed over time -- but not for me. And get off my lawn!) 12 XP processes. And my highly opinionated view of each of them. After that I'll tell you how to score your "Agility."
* Planning Game
Get requirements from customer, form them into (short) stories, estimate the time it will take, do them, measure velocity, examine failed estimates for clues as to how to estimate better, and repeat. A story should be a placeholder for a conversation -- This only works if the customer (or surrogate) is highly available to the developers and the developers take advantage of that availability by checking in frequently during the development process. Note: Stories that take longer than a day significantly undermine many of the other parts of XP.
* Small Releases
Iterations should be 1-2 weeks (depending on how painful/expensive it is to organize an iteration). Releases should happen after every iteration if the application is easy to deploy (web apps).
* Metaphor
Nobody does this. Extra points if you do.
* Simple Design
This means different things at different levels. When kicking off a green field project a week of requirements gathering and design is good. For an individual story, a few minutes to an hour is good. Then you start writing code. Important: Design as you go. Stopping to spend a few hours with a whiteboard is allowed and encouraged. Do the simplest thing that could possible work until it becomes apparent that it will not. Then redesign. The idea is that at the beginning of the project you know the least about it -- spread the design across the life of the project so you can make design decisions with more knowledge.
* Testing
Test first. Coverage above 80% for Java, 90% for Ruby (less exception checking in Ruby means easier to cover). Non-brittle, atomic, fast tests (unit tests should run under 5 min. Actually under 1 minute is best, but most think that's impossible (spoiler: Its possible)).
* Refactoring
Short: Red, Green, Refactor! Long: Write a failing test, make it pass, refactor the code. This also means when you wander into a messy place you leave it a little better than you found it.
* Pair Programming
Above 80% of the time. Seriously. Tasks that seem like you can't pair on them often mean that you aren't using the right pairing techniques. Pairing is a skill: Get good at it.
* Collective Code Ownership
Anyone can change any code. Yes, they should consult whoever is knowledgeable about said code, but there are no parts of the code that only developer X is allowed to touch.
* Continuous Integration
Every check-in to the remote repository triggers a comprehensive suite of unit tests. The developers have to care if the build fails. For example: When the build fails, no one checks in until it is fixed. Also there should be some social ridicule for the build breaker (have to wear a stupid hat for the rest of the day, an obnoxious build breaker trophy placed on their desk, they have to buy donuts for the team, etc.). This all assumes that the build is reliable and that a failure means there is a real problem.
* 40-hour Week
Now called "Sustainable Pace" because "40-hour Week" tends to scare managers and end of project pushes are sometimes necessary even in XP. This should be no more than 2 weeks, have a clearly defined point at which the long hours will stop, and happen no more than twice a year. Actually, if it happens twice a year it means your estimation skills need to get better.
* On-site Customer
Doesn't happen often for non-internal projects. Usually customer surrogates are used. These surrogates need to take pains to talk to real users often (not just the managers of the users) and be highly available to developers to answer questions.
* Coding Standards
Doesn't matter what they are but the developers need to come to a consensus and stick to it. Consensus does not mean everyone nods yes in the meeting but ignores the standards when they feel like it.
So how do I score my Agility? Take the number of practices that you actually do, divide by 12, and then multiple by 100 -- that's your percent Agile. Do not give yourself a point if you don't fully implement a practice. Have Continuous Integration but some of the tests fail randomly? No point. You pair "when necessary" which ends up being 40% of the time. No point! Run iterations but don't estimate your stories? No Point!!
This is take a hard look at yourself in the mirror time, not some hippie love fest.
Comments
Quibble: Continuous Integration does not require the use of an automated build server. In fact, I think it works better without one.
As you were.
-- XP Ninja
Juan Pablo