6 Productivity ideas in Agile
Productivity is defined as the production output per unit of input. I.e. dollars out / dollars in.
Assuming a fixed team working on a single product, your cost is (almost constant) for each sprint. The only way productivity can increase is by increasing the delivered value. That can be done by:
1) not building anything with 0 value, thus minimizing waste.
2) minimizing dead time. In software development that translates to:
- fast dev machines (minimize the devs waiting on builds and deployments).
- keep the build fast
- make deployments simple (e.g. hot deployments with JRebel)
- minimize dev env setup time (e.g. using Vagrant).
3) minimizing rework. This one translates to:
- keep the code releasable at all times using CI
- high coverage, layered automatic testing (aka agile release onion).
4) allowing the team to work uninterrupted
- minimizing external interference (including from management :)
- providing a quiet work space
- structuring the team in a way which prevents multi-tasking (assign team members against a work stream for the sprint)
5) What will not increase productivity is putting pressure on people.
6)What to measure to encourage a better productivity? In no particular order, here's a list of things that in my experience impact productivity and can be used to drive improvement:
- checkin frequency / developer (high is good).
- unit test code coverage (high is good).
- build duration * frequency (lower is better).
- variance in committed sprint scope (lower is better).
- variance in committed release scope (lower is better).
- SPI and CPI (see Earned Value PM method).
- mean time between stable system builds (low is good); one can look at frequencies at various levels in the release onion.
- number of defects detected post release (low is good).
""A team could be very productive but just be producing the wrong software.""
Assuming a fixed team working on a single product, your cost is (almost constant) for each sprint. The only way productivity can increase is by increasing the delivered value. That can be done by:
1) not building anything with 0 value, thus minimizing waste.
2) minimizing dead time. In software development that translates to:
- fast dev machines (minimize the devs waiting on builds and deployments).
- keep the build fast
- make deployments simple (e.g. hot deployments with JRebel)
- minimize dev env setup time (e.g. using Vagrant).
3) minimizing rework. This one translates to:
- keep the code releasable at all times using CI
- high coverage, layered automatic testing (aka agile release onion).
4) allowing the team to work uninterrupted
- minimizing external interference (including from management :)
- providing a quiet work space
- structuring the team in a way which prevents multi-tasking (assign team members against a work stream for the sprint)
5) What will not increase productivity is putting pressure on people.
6)What to measure to encourage a better productivity? In no particular order, here's a list of things that in my experience impact productivity and can be used to drive improvement:
- checkin frequency / developer (high is good).
- unit test code coverage (high is good).
- build duration * frequency (lower is better).
- variance in committed sprint scope (lower is better).
- variance in committed release scope (lower is better).
- SPI and CPI (see Earned Value PM method).
- mean time between stable system builds (low is good); one can look at frequencies at various levels in the release onion.
- number of defects detected post release (low is good).
""A team could be very productive but just be producing the wrong software.""
Comments
Post a Comment