• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Five Key Numbers to Gauge your Agile Engineering Efforts
 

Five Key Numbers to Gauge your Agile Engineering Efforts

on

  • 8,983 views

Talk given at Agile Tech DC, May 14, 2011

Talk given at Agile Tech DC, May 14, 2011

Statistics

Views

Total Views
8,983
Views on SlideShare
8,479
Embed Views
504

Actions

Likes
14
Downloads
0
Comments
3

26 Embeds 504

http://geekswithblogs.net 391
http://www.geekswithblogs.net 57
http://milnespg.blogspot.com 9
http://devfeeds.com 9
http://www.edmodo.com 6
http://paper.li 4
https://twitter.com 2
http://aprendersociales.blogspot.com 2
http://therichestweb.com 2
http://tallerapr3pr4pfc.blogspot.com 2
http://moodle.egap.xunta.es 2
http://us-w1.rockmelt.com 2
http://a0.twimg.com 2
http://twitter.com 2
http://manish-sharepoint.blogspot.com 1
http://milnespg.blogspot.com.es 1
http://localhost 1
http://www.istikbal.gr 1
http://agile4all.com 1
http://reeep.org 1
http://localhost:8082 1
http://www.mongodb.org 1
http://pmsapp.mercadolibre.com.ar 1
http://www.slideshare.net 1
http://www.janakiramm.net 1
http://yuvalyeret.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

13 of 3 previous next Post a comment

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Speed up feedback loops, know whether you’re building the right thing, whether it’s going to make you money, know if you understood the requirements, be more responsive to your customers, change direction quickly
  • What if you could engineering things in such a way so that you could produce a constant stream of new features at a steady rate, regardless of the age and/or size of the system?
  • OBJECTIVES Understand how various agile engineering practices help to flatten the cost of change curve See why lowering transaction costs is a key theme of agile engineering practices Be exposed to some ways to evaluate the maturity of their own agile engineering effortsHave ideas about how to improve their implementation of agile engineering practices
  • This exposes the limit of how quickly you can work within your team context.
  • Collective code ownershipSimple designGroup designTransparency in version controlReduce the WTH’s per minute in a code reviewPAIRING
  • You need a shared contextBuild trust through interactionIf you aren’t working regularly side-by-side with your teammates, the team knowledge and cohesion is going to fracture

Five Key Numbers to Gauge your Agile Engineering Efforts Five Key Numbers to Gauge your Agile Engineering Efforts Presentation Transcript

  • Five Key Numbers to Gauge your Agile Engineering Efforts
    Jeff Nielsenjeff@jeffnielsen.com
    Agile Tech DC
    May 14, 2011
  • There are many benefits to working incrementally in short cycles . . .
  • . . . if you can pull it off
  • Agile engineering practices are supposed to enable a flattened cost-of-change curve
    TDD
    refactoring
    continuous integration
    pair programming
    coding standard
    automated builds
    automated tests
    . . .
    Craig Davidson, http://www.agileadvisor.com/2009/01/yagni-and-cost-of-change-curve.html
  • But it’s not sufficient simply to do the practices(They’re not binary)
  • How do we knowhow effectivewe are atflattening the curve?
  • Five key numbers . . .Not intended to be comprehensive or even very scientific
  • Seconds
    20
    #1How long until you see feedback from a test after writing or changing a line of code?
    16
    12
    8
    4
    0
  • #2How many one-line changes can you commitand push to testin an hour?Following the team’s practices, of course
    20
    16
    12
    8
    4
    0
    Commits
  • The speed of the feedback affects the speed at which you can work
  • 5
    4
    3
    2
    1
    0
    #3How many people on your team can explain the details of any particular section of code?
  • 100%
    #4What percentage of your team members did you pair with in the last two days?
    80%
    60%
    40%
    20%
    0%
  • “Promiscuous” pairing speeds up communication and builds trust
  • #5How many manual steps does it take to get a build into production?
    15
    12
    9
    6
    3
    0
    Steps
  • Higher transaction costs drive longer cycles and bigger batches
  • To lower the cost-of-change curve, we must lower the transaction costs associated with adding features
  • Make it cheaper to
    Change code
    Check in code
    Understand the code
    Communicate with your teammates
    Push code to production
  • If we can make changes cheaply enough . . .
    . . . the cost savings from quicker feedback and increased learning outweighthe costs of overhead and rework.
  • 120
    96
    72
    48
    24
    0
    BONUS
    What’s theaverage typing speed of the programmers on your team?