I'm the type of person who learns by "doing" therefore to try to "do" Agile, I'm going to summarize the 12 guiding principles of Agile, as stated by the founding 17 members. This is not going to be an exact copy of the original, I'm taking some poetic liberty to internalize the content. So if you disagree with anything I mentioned, please, leave a comment, help me and other readers learn (bet you thought I was going to say something else? haha nope, leave a message and we can all learn).
- satisfy your customer with early and continuous deliverables
- relish in changes, believe in your "lists" (aka Product Backlog) to help track and not lose any details
- deliver working "stuff" frequently, the shorter the frequency the better (this suggests automating your builds, very key)
- everyone plays an equal part in deliverying to the customer, from sales, manangers, developer, support, etc
- trust and support your people to give you what you ask for and they'll deliver, enthusiastically!
- IM, email, teleconferencing, cell phones, all great tools, but old fashoined face-to-face conversations trumps them all!
- working programs = success
- OT kills motivation long term, Agile feeds it, sustains it, feed it to your developers and they'll code forever
- never let your guard down to let bad design/code/testing into the program
- KISS
- people, left to their own devices will organize themselves the most efficient way possible
- periodic self reflection is key to "revectoring" your team to success
I've seen some of these things in my history, although I wasn't always part of a team doing Agile, I have seen first hand some of these things! Here are some of my experiences/observations about the guiding principles.
1. Having a continuous feed of working builds serves to reinforce your customers trust in you (and your team/company).
2. A customer who knows EVERY issue is being tracked, believes in you more cause they know you are listening and "actioning" every item requested, nothing is forgotten, dropped, disregarded.
3. Daily builds, well, builds trust in the deliverables, people and teams downstream can rely on their integrity.
4. In my study groups, everyone is equal, everyone contributes, everyone participates, from the study group leader to the person answering quiz questions, everyone's contributions are just as worthwhile!
5. One boss (PB) I had while overseas blew me away once when I was putting in 10-15 hours a day working with a coworker to get something done and I was getting late for my flight home. He comes over, pats me on the shoulder and says in a very reassuring voice, "don't worry, I know you guys will get it done by the deadline, I believe in you." Yes, we found the issue and got it done! We never gave up on him and did everything we could to make him look good! We all still talk to each other now!
6. Meeting people face to face, especially of different cultures makes you appreciate their perspective of work, career aspirations, family, development, technology, life in general. You just can't get that over a PPT, DOC, IM, email. Spend the dough for face to face meetings. If you don't, that's ok too, cause you'll just spent more in failed communications, misunderstandings, personal conflicts and possible mass withdrawal (yes this is sarcastic :>). Keep your people happy and working together as a team, help them see eye to eye, literally.
7. Nothing speaks louder than a working program.
8. Maybe you've been through the traditional "programmer's project cycle," laxed at the beginning, regular days, not too stressful, but as the project approaches a deadline, more and more time is spent at work, more stress builds. How long can you sustain that for? Months? Years? Your whole career? If you think you can, you're only fooling yourself.
9. I knew someone who had the following quote on his notebook "Don't let your boss talk you into doing bad work." (Thanks JK :>) It's nearly impossible to keep your job AND stay true to that quote, but the goal is honourable. You're going to pay the pricem, either by doing a crappy job now and redoing it in the future, or doing it right the first time. One place I was at decided to cut corners, six months later I was supporting that software and low and behold the customer was threatening to refuse payment of the software due to the bugs in one certain area. Three guesses on what area that was?
10. YAGNI (yup, one acronym deserves another :>)
11. Ever see a pro sports team perform? The good ones just seem to fly across the field/rink without much direction from their coach. They just know what everyone is doing, they just seem to work together better than the other teams at the bottom of the standings. They have "self organized" themselves behind the scenes, and they constantly rejig their efforts after every practise, game, social gathering, or even after a trade.
12. No progress can be made on something that is not measured. History repeats itself, why not take advantage of it?! If you can repeat the good stuff and not the bad, do it! But how are you going to know what worked and what didn't if you don't talk to your whole team?
Those are my personal takes and observations of the 12 Agile guiding principles. Please leave me a comment and let me know what you think?
References:
Principles behind the Agile Manifesto (http://agilemanifesto.org/principles.html)