The document discusses five key metrics to measure the effectiveness of agile engineering practices: 1) How long until you see feedback from a test after changing code, 2) How many one-line code changes can be committed and tested in an hour, 3) How many team members can explain parts of the code, 4) What percentage of team members paired in the last two days, and 5) How many steps it takes to get code into production. These metrics help gauge how well practices like test-driven development and continuous integration are flattening the cost of change curve.

1. Five Key Numbers to Gauge your Agile Engineering EffortsJeff Nielsenjeff@jeffnielsen.comAgile Tech DCMay 14, 2011

2. There are many benefits to working incrementally in short cycles . . .

3. . . . if you can pull it off

4. Agile engineering practices are supposed to enable a flattened cost-of-change curveTDDrefactoringcontinuous integrationpair programmingcoding standardautomated buildsautomated tests. . .Craig Davidson, http://www.agileadvisor.com/2009/01/yagni-and-cost-of-change-curve.html

5. But it’s not sufficient simply to do the practices(They’re not binary)

6. How do we knowhow effectivewe are atflattening the curve?

7. Five key numbers . . .Not intended to be comprehensive or even very scientific

8. Seconds20#1How long until you see feedback from a test after writing or changing a line of code?1612840

9. #2How many one-line changes can you commitand push to testin an hour?Following the team’s practices, of course201612840Commits

10. The speed of the feedback affects the speed at which you can work

11. 543210#3How many people on your team can explain the details of any particular section of code?

12. 100%#4What percentage of your team members did you pair with in the last two days?80%60%40%20%0%

13. “Promiscuous” pairing speeds up communication and builds trust

14. #5How many manual steps does it take to get a build into production?15129630Steps

15. Higher transaction costs drive longer cycles and bigger batches

16. To lower the cost-of-change curve, we must lower the transaction costs associated with adding features

17. Make it cheaper toChange code Check in codeUnderstand the codeCommunicate with your teammatesPush code to production

18. If we can make changes cheaply enough . . . . . . the cost savings from quicker feedback and increased learning outweighthe costs of overhead and rework.

19. 120967248240BONUSWhat’s theaverage typing speed of the programmers on your team?