Non-technical colleagues look at our increasingly-agile team and wonder why we say we are more productive than ever. After all, thanks to coding dojos, pair programming, and retrospectives, the KPPPD metric (Keystrokes Per Programmer Per Day) has dropped alarmingly, so how can we possibly be producing more code?
I'd like to discuss this attitude with others who have encountered it and get some ideas for how to help those who are not involved in agile practises understand why they are useful.
(Note: this is a different topic than http://xpday-london.editme.com/TeachingPairProgramming. Matt specifically says he wants to talk about selling pair programming to members of the project team, while I want to address those outside the team.)
OK, here's the summary of the copious notes I took on the board. Many thanks to all participants, including James Lyndsay, Ivan Moore, and Keith Braithwaite (sorry that these are the only folks whose names I caught).
First quote: Why concentrate on better processes when you could be writing more code?
Pages 4-6 of Clean Code explain how your project can get slower and slower until it grinds to a halt, unless you pay attention to doing things right all the time.
Slack by Tom DeMarco makes the argument that we should not run our teams (or our CPUs!) at 100% - that is inefficient and brittle. Leave yourself 40% headroom for growth.
Draw a classic two-by-two matrix, with Urgent in one direction and Important in the other. We all do things in the urgent and important quadrant, and too often in the urgent and unimportant quadrant. You have to leave yourself time to get to the not-urgent but important quadrant.
You can explain until you are blue in the face - non-techies don't get it. Accountants don't hold accounting dojos!
BuyAFeature.com can be helpful for prioritising work.
Second quote: The first job of a developer should be delivering software, not professional development (which is also important, but not as important as delivery).
Do your team have shared goals? Or do you have a conflict between developers who want to write the best applications and non-technical managers to whom "agile" is a bad word? Instead of "agile", refer to "professional development", "iterative", "speedy development", or "speedy training". In the pub with your football mates, you don't mention your love for Dr. Who!
In the public sector, the tradition is to measure the input not the output. So trying to measure real results gets you nowhere.
Low turnover can be a powerful argument for agile development. (At youDevise we have well under 10% - someone cited 20% as industry standard.) Happy developers stay; happy developers write better code.
One of the problems with late capitalism is that we all have to justify having fun (perhaps a Calvinist philosophy?)
Sounds like there is an absence of trust between developers and non-developers here.
Accountants, doctors, and lawyers are regularly reassessed and must have ongoing education. Why not developers?
Third quote: I could build that feature in an hour. Why did it take you a week?
Again, sounds like a disconnect in goals. Do you really need a feature done in one hour? Or can you combine that work with learning, so you get done slower but better, and can go faster next time?
Disagreement - why don't we care that the business want the feature in an hour? Maybe they really do need this.
Short-term thinking here. Returns on education come in 3 months not one hour.
Synthesis of disagreement: a new feature is easy to see, but medium-term investment benefits are not visible.
Assigning value points to a story is not the same as assigning effort points. There are lots of stories that are easy but provide significant value.
Numbers are not the solution. Can lead to false questions, like "why did you do 28 points last week instead of 28.3?"
Points are at least better than hours - more abstract measurement.
Tell non-techies to leave us alone and not to micromanage us to absurd numbers.
Again, debates over numbers point to a lack of trust between developers and non-developers.
The high cost of smart people means we should be thinking of ways to improve their skills (do we really want to replace them and retrain??)
We've all been on projects where according to the numbers, we were very successful (an "actuarial success") but the product was cancelled and everyone on the team wishes she was dead! Conversely, we've all been on projects that were a failure by strict criteria but where all the customers were delighted with their new live product.
Doctors who get sued have the same quality of care as non-sued doctors, but aren't as nice! (See Malcolm Gladwell, Blink: Why Doctors Get Sued.)
People (customers, managers, executives) are NOT rational! See Predictably Irrational and Duncan Pierce's review of cognitive biases.
Discussion of others' similar problems
Customer says iterative development is working great and they'd like to see your 2009 plan now.
Just include the milestone releases.
Find out what is done with the plan. (It probably goes on a shelf somewhere.) It will be invalid in six weeks anyway.
Use fakeplan.org to make a slick but totally fake plan. (That site doesn't seem to exist, but someone should definitely create it.)
Customer asks why you didn't find that bug.
"Why" has two parts: what was the cause of the initial error, and why didn't we find it (after creating it)?
Root-cause analysis is often helpful.
For instance, you may find that testers are not unified with developers in a single team.
Deming defines four types of error: common, special, systemic, and noise.
Participants cite many examples of nasty systemic errors, including ones caused by assuming that the user is in the Western Hemisphere, that the user doesn't have any apostrophes in her name, and that third-party libraries won't leak resources.
Many of these examples are black swans, best found by exploratory testing.
