I have been an Agile Coach for over 6 years now.  I’ve learned a lot during this time, and I’m still learning.

Here are 78 things I have learned so far:

  1. Number of people to whom you ask to describe “Agile”  = Total number of Agile mental models  + or -  2
  2. Distributed teams need love and a ScrumMaster at each site
  3. A foosball table may be one of your best Agile tools
  4. Geography is more than a timezone issue; it needs infrastructure support
  5. It’s massively worth the effort to stay engaged in the Agile community through local events, online lists, conferences, and casual meet-ups
  6. Having a Product Owner is non-negotiable
  7. Avoid Cargo Cult Scrum at all costs!
  8. Agile teams need to have fun
  9. The best Agile teams and companies rely on Servant Leaders
  10. Embracing a real Agile culture is often more than one team can create on its own
  11. Agile development can only cut costs if you are willing to spend time and money on it
  12. A great approach to agile maturing and scaling is Flow Pull innovate guidance from Lean
  13. Burndown charts are about the team commitment to doneness, not about individual performance or time tracking
  14. Ensure your sprint backlog reflects the delivery of product value
  15. Escalation doesn’t serve either the Agile or Lean community in continuous improvement of practices
  16. You need to have more than checkbook buy-in from your Executive to be successful
  17. Mature your Agile team practices before attempting to scale to more teams
  18. Not having a clear signal to end your stand-up can lead to problems
  19. The Lean principle on Flow guides Agile teams on how to tighten up their practices
  20. Get everyone in your Release Planning meetings if you want true commitment to the Release’s vision
  21. Command-and-control ScrumMasters reduce the intelligence of their teams
  22. Co-located teams move to being high-performing, high trust teams far easier and far faster than non-co-located teams
  23. Frequent communication through site visits, IM, Skype, email, Facebook, Yammer, video conferencing and other technologies help distributed teams gel and feel the love
  24. Agile teams invite healthy conflict in order to become great, enduring teams
  25. Velocity: it’s about the team not the individual
  26. Kanban is helping teams find new measurements for constant flow of value -  so let’s pay attention.
  27. No product owner or too many product owners add up to the same Agile adoption smell: no definitive decision on ranking or acceptance
  28. A Product Council is an effective way to manage stakeholders and minimize backlog churn
  29. Story points help teams separate calendar hour and number of team members from the story’s complexity, effort, and doubt
  30. Stories have relative sizes to one another; only tasks take on effort estimates
  31. A well-written story (small, about benefit to a role) doesn’t lie; requirements do by their shear volume of content
  32. A product backlog is ALWAYS ranked
  33. A product backlog is not a task list; tasks only appear after estimating and planning by the team
  34. Agile improves the quality of life for employees
  35. Great teams are made of collaborative team members
  36. Agile doesn’t create the messages it exposes them
  37. Pair programming raises team awareness and code integrity
  38. Use consensus, not forced compromise or command and control, to gain full team commitment
  39. Effective team meetings require structure and discipline
  40. Commit to Agile values and principles; your practices will follow
  41. Transparency is an Agile virtue not a punishment
  42. Agile is about commitment not tools; tools support those commitments and make them visible
  43. Product owners who make their decisions in a vacuum are not Agile
  44. Agile teams invoke respect and kindness even in stressful times
  45. Teams that don’t retrospect are not Agile
  46. Retrospectives are not about blame
  47. Retrospectives bring continuous improvement of process and working agreements
  48. If you don’t have team working agreements, create them now
  49. If you don’t hang your team working agreements on the wall, put them up there now
  50. Aggressively cap your utilization capacity until you know your velocity
  51. Blog your Agile experiences; more people want to hear them than you think
  52. Test driven development doesn’t just create better code; it creates better conversations that create better acceptance
  53. Agile Architects and Product Owners work side-by-side to rank product backlogs
  54. Give your Agile teams a break such as a “hackathon” built into the cadence of the team’s release schedule
  55. High capacity utilization is deceptively evil
  56. Quality is everyone’s responsibility
  57. Small increments quickly inform us about our work and produce feature sets faster
  58. Lean has had a great impact on my Agile language
  59. Hiring the best” can be yet another cliche in Agile
  60. Hire wisely not cheaply
  61. When hiring new members, team consensus is a must
  62. Use 5 levels of planning: Vision, Product Roadmap, Release Planning, Iteration Planning and Daily Planning
  63. Release planning is one of my favorite Agile activities
  64. Teams and stakeholders invite release planning to see beyond the next iteration
  65. FYI, good brainstorming requires lots of post-it notes and sharpies
  66. Pay attention to your facilitation skills so that you don’t takeover decisions and don’t let others do the same
  67. Keep Agile meetings focused, stick to the purpose and timebox
  68. Turn your electronics off in Agile meetings; focused meetings are productive and end on time
  69. The biggest cost cutting lever in Agile is prioritization
  70. Don’t be afraid to try new practices; your velocity and quality may thank you
  71. Agile is useful beyond software; take it up and out the organization
  72. Old tools stand in the way of new tricks; MS project is not the way to go Agile
  73. Team identity is important, individual heroics are dangerous
  74. Individual appreciations in retrospectives are a great way to create space for the growth of Agile team trust
  75. Agile maturity is NOT about a CMMI-like maturity model
  76. The war between Agile and Waterfall is over; get on with your continuous delivery of valued items
  77. Agile asks us to slow down in order to speed up; just do it
  78. I love Agile.

This is far from a comprehensive list. I still have plenty more to learn about Agile. I’d love to get some insight from you about what you would add to the list.

What have you learned in your experience practicing Agile?

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.