Mike Cohn’s 12 things you MUST do in transitioning to agile:

1. Pick the right project – find the project with the proper intersection of duration (2-4 months), size (1-5 teams), with a business sponsor, and importance (high – keeps you on task).
2. Pick the right iteration length – XP now says 1 week, Scrum says 30 days – just pick what works and be consistent.
   • Will you allow change during an iteration? (Refinement of requirements is not change)
   • He recommends no – pick an iteration length equal to how long the organization can go without changing its mind.
3. Get everyone on board – make sure all key players surrounding the project buy into Agile
   • Objection – it only works with talented people. No, but you need at least one developer who can fluidly move between different development techniques. (But you pretty much need someone like this for any project to succeed)
   • Objection – it only works on trivial projects. This is disproven by the number and breadth of complex projects that use agile (Yahoo, Joint Strike Fighter).
   • Objection – it’s not appropriate for all projects. This may or may not be true, but just use common sense, use it when it makes sense
4. Have a “customer” – an actual customer or product owner, and keep them consistently involved.
5. Start with a beachhead team – for larger organizations, start with a smaller, focused group and help them fight through the infrastructure and process issues until they’re succeeding. Ensure that this team is fully cross-functional.
6. Deliver – makes sense. Don’t allow the team to miss any deadline, large or small. Missing a small deadline trains the team to miss parge ones.
   • Stress quality, not speed. You want code you’re PROUD of, that you would hang on your mom’s refrigerator.
7. Automate – automate unit tests, acceptance tests, regression tests, builds, deployment
   • Test automation tools – JUnit, FIT, FitNesse, HttpUnit, HTMLUnit, Canoo WebTest
   • Continuous integration – Automated nightly build at least, if not continuous – Cruise Control, AntHill
8. Follow a guide – you need someone who’s been there before, either an employee or an outside mentor or coach.
9. Track and communicate progress – many approaches, from a task board to formal reports
10. Meet Daily – use a daily standup meeting to coordinate, communicate, and make committments to one another
11. Reflect – at the end of an iteration, reflect and discuss what we’d like to start doing, stop doing, and continue doing
12. Don’t try it all at once – start with the practices that seem most valuable, prioritize the ones you want to adopt later in a backlog.

His preferred order of implementing things – Requirements as user stories (light requirements), estimate and create a release plan, nightly or continuous build with tests.

I enjoyed the talk, though much of it seemed focused on how to sway the momentum of a large organization toward agile. He called a company a “small shop” when it had 100 developers. Our entire company is around 50 people, including operations, support, sales, etc. So our challenge is more about the proces to adopt rather than the politics of adopting it. Some later sessions may help shed some light on this decision.

Where am I blogging from? No Fluff Just Stuff’s Greater Atlanta Java Software Symposium. I was using the [GAJSS] heading before, but thought NFJS Atlanta might be more clear, and better signal the relevance of the entires to the Atlanta community better.