Q.How can we make enough changes CHEAPLY ?
A. Agile engineering efforts
Agile engineering efforts is simply the easiest answer to this question. Agile practices are suppose to provide flat cost of change curve, but there are many perils involved with it, as it is not enough only to follow the practices, what is more important How do we know how EFFECTIVE we are in achieving this curve?
For starting, with these easy five questions we can 🙂
How long until you see feedback from a test after writing or changing a line of code?
“Speed of feedback is directly proportional to the speed at which you work“
Commits – How many one liner changes can be commited and pushed to test in an hour or hours or in a day?
How many people on the team can explain the details of any particular piece of code?
The more understandability of code across team the more easy it would be to make changes in future.
What percentage of team members paired with eachother in last two days?
Pairing fellow team memebers speeds up communication and builds trust.
How many manual steps does it takes to get a build into Production?
More the transactions, longer the cycles & bigger the batches increases overall time and cost.
With less transactions comes less cost and lower costs associated with adding new features.
Lets sum-up this CHEAP formula quickly 😛
#1 – Make it cheaper to CHANGE CODE.
#2 – Make it cheaper to CHECK IN CODE.
#3 – Make it cheaper to UNDERSTAND THE CODE.
#4 – Make it cheaper for TEAMMATES TO COMMUNICATE.
#5 – Make it cheaper to PUSH TO PRODUCTION.
Maintaing this cure is simple yet very complex as it requires lot of errorts across team, but practicing with comman-sense makes it a pleasant experience for developers and a CHEAPER one for client.
People who read “Agile efforts : A step towards cheap changes !” also read :