I Suck At Agile Development (Part 1)

my coworker (tim) lent me a book to read which he thought i would enjoy. the book is called "practices of an agile developer" by the pragmatic programmers venkat subramaniam and andy hunt. basically, the book is a collection of best practices for... being an agile developer... which is of particular use for software developers in the ever changing environment of technology. and by agile, i don't mean doing cartwheels or somersaults... although that would be interesting. agile, in this sense, refers to the ability to adapt to situations.

to many who are not into software developing, this content would normally sound pretty dull. some lessons, however, actually translate well into the non-software developing area. since i suck at agile development, here are some of the lessons thus far:

1. work for outcome: blame doesn't fix bugs. instead of pointing fingers, point to possible solutions. it's the positive outcome that counts.

2. quick fixes become quicksand: beware of land mines; don't code in isolation; use unit tests; don't fall for the quick hack. invest the energy to keep code clean and out in the open.

3. criticize ideas, not people: negativity kills innovation; set a deadline; argue the opposite; use a mediator; support the decision; take pride in arriving at a solution rather than proving whose idea is better.

4. damn the torpedoes, go ahead: do what's right. be honest, and have the courage to communicate the truth. it may be difficult at times; that's why it takes courage.

5. keep up with change: learn iteratively and incrementally; get the latest buzz; attend local user groups; attend workshops or conferences; read voraciously; you don't have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects accordingly.

6. invest in your team: raise the bar for you and your team. use brown-bag sessions to increase everyone's knowledge and skills and help bring people together. get the team excited about technologies or techniques that will benefit your project.

7. know when to unlearn: expensive mental models aren't discarded lightly. learn the new; unlearn the old. when learning a new technology, unlearn any old habits that might hold you back. after all, there's much more to a car than just a horseless carriage.

8. question until you understand: keep asking why. don't just accept what you're told at face value. keep questioning until you understand the root of the issue.

9. feel the rhythm: tackle tasks before they bunch up. it's easier to tackle common recurring tasks when you maintain steady, repeatable intervals between events.

i have yet to finish the rest of the book, but so far... i would recommend the book to anyone. it's easy to read and the concepts make sense. i will post more lessons as soon as i get to it...