Agile Process Proverbs
 Here are some things to think about. I have summarized them into pithy sentences, added bullet points and called them proverbs to make them sound important. Don't be fooled. These are ideas, not rules. Ideas to help you think about making your current process, what ever it is, a more Agile process.

Iterative Planning
The best way to meet customer objectives is to explicitly schedule their completion.
 Trying to catch up is the fastest way to get further behind.
 The changes you get late in a project are very valuable because you paid the most to get them.
 One third of your requirements will represent two thirds of the project's value.
 Showing someone something they can change is helpful, showing something they can't change is spiteful.
 Iterative development gives you a few "oh drat"s during development instead of one big "AW SHIT" at the end.

Honest Plans
 An estimate not based on a measurement is a guess; an estimate based on a measurement is a prediction.
 He who does the work sets the estimate.
 If software is what you want to deliver then measure progress by how much you have working right now.

Team Empowerment
 The most important thing on a project is good leadership; the least important thing is who leads.
 If you can see a need for leadership you know enough to lead.
 When you only have responsibility you will know worry, but when you also have authority you will know opportunity.
 The organization of your team will be reflected in the code. (Conway's Law)
 Calm and relaxed plus confident yields decisive.
 Count how many people are on the project, now communicate like a group that size.
 Hermits don’t share, communities are based on sharing.
 Agile models are paintings, not photographs.
 The creation of a document is an implicit agreement to keep it up to date or destroy it.
 Without the use they are just cases.
 Ideas move faster than documents.

Customers/Product Owners
 There is more to owning software than just paying for it.
 Negotiating is basic to being human, don't give it up that right before the project even begins.

Managers/Scrum Masters
 Challenge your team intellectually or they will challenge themselves in ways you wouldn't have chosen.
 Demanding estimates change seems like taking control, but you lose control by not making a decision.
 People don't scale, teams do.
 The only way to guarantee bad decisions is to make all of them yourself.

Developers/Team Members
 Big changes cause big problems.
 Egoless programming doesn't work; expand your ego to include everyone's code.
 Don't guess, measure it.
 Don't theorize, try it.
 Everything you did today can be done over tomorrow in half an hour and be better.
 Measure twice cut once saves wood, but software isn't made of wood.
 The best way to get help is to offer help.

 The first test is the hardest.
 Your test suite is more valuable than your code.
 The harder the test is to create the greater your savings.
 Where there is a will there is a way to test.
 If you want a good suite of tests next year you must start collecting them today.
 If you don't use your process it can't help you; if your process doesn't help, you won't use it.
 The one essential ingredient that turns repetitive development into iterative development is feedback.
 If less doesn't work try more, if more doesn't work try less, if neither works stop doing it.
 If 10 people slow the project down by just 10% each it will take twice as long.
 If it isn't fun you're doing something wrong.
 A hammer without a good process is a sore thumb waiting to happen.
 Process is something you do, not something you do to someone.
 The person least likely to save time is the person in the biggest hurry.
 The least disciplined team member has the greatest control over your process.

 Simple is subjective so judge it subjectively as testable, browsable, understandable, and explainable.
 The best way to guarantee it costs too much is to add something you don't need.
 If it takes you too long to refactor than you are not refactoring enough.
 A simple solution always takes less time than a complex one.
 If you always try the simplest thing next you will always work as simply as you can.

 Who ever finds a problem knows enough to design a solution.
 Flexibility isn't building for every imaginable possibility; it's having as little to change as possible.
 A good design can be explained to someone else using four blank cards.
 A design which doesn't meet business needs is bad, no matter how pretty.
 UML was designed to document complexity, not expose it.

Finish your guided tour with Links and Books.Links and Books home |Links and Books | About the Author

Copyright 2009 Don Wells all rights reserved.