I Suck At Agile Development (Part 2)

since i have yet to finish the book my coworker (tim) lent me and thus, still suck at agile development, here are some more lessons:

10. let customers make decisions. decide what you shouldn't decide. developers, managers, or business analysts shouldn't make business-critical decisions. present details to business owners in a language they can understand, and let them make the decision.

11. let design guide, not dictate. design should be only as detailed as needed to implement. a good design is a map; let it evolve. design points you in the right direction. it's not the territory itself; it shouldn't dictate the specific route. don't let the design (or the designer) hold you hostage.

12. justify technology use. blindly picking a framework is like having kids to save taxes. does the technology really solve the problem? will you be tied to this technology? what about maintenance costs? don't build what you can download. choose technology based on need. determine your needs first, and then evaluate the use of technologies for those specific problems. ask critical questions about the use of any technology, and answer them genuinely.

13. keep it releasable. keep your project releasable at all times. ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment's notice.

14. integrate early, integrate often. code integration is a major source of risk. to mitigate that risk, start integration early and continue to do it regularly. never accept big bang integration.

15. automate deployment early. deploy your application automatically from the start. use that deployment to install the application on arbitrary machines with different configurations to test dependencies. qa should test the deployment as well as your application.

16. get frequent feedback using demos. develop in plain sight. keep your application in sight (and in the customer's mind) during development. bring customers together and proactively seek their feedback using demos every week or two.

17. use short iterations, release in increments. develop in increments. release your product with minimal, yet usable, chunks of functionality. within the development of each increment, use an iterative cycle of one to four weeks or so.

18. fixed prices are broken promises. estimate based on real work. let the team actually work on the current project, with the current client, to get realistic estimates. give the client control over their features and budget.