Thursday, December 20, 2007

Agile Development Practical Experiences

Johan Lybaert gave a talk at JAVAPOLIS 07 about practical experiences in agile development. He started out by emphasizing that picking a certain methodology needs to take into account the type of project, organization culture, team members and client. Once a methodology is selected, it should be constantly evaluated and adapted.

With Agile, team members require certain soft skills. These include courage, responsibility, stand up meetings, direct communication, working in pairs, working with different members, thinking before acting, does what they say, looking for feedback and able to accept feedback, likes to keep it simple, and likes to have fun.

Johan covers some lessons learned:

  1. Team members work on a variety of tasks
  2. Configuration and build is common across projects and is provided as a service
  3. 2 week sprints better than 4 week sprints
  4. Investment in continuous learning is a must (coaching, info sessions, reading groups, workshops)
  5. Use Agile PM instruments (Velocity graph, backlog, high level plan with milestones,

Johan then moves to cover 10 best practices:
  1. User stories: An agreed high level analysis document should be the starting point. Just in time preparation for user stories is key, Review and sign off by customer at sprint design walkthrough essential for good scope management, involvement of developer and architect in the preparation is important for domain model design, technical options and constraints.
  2. On site customer: If can’t have on site customer all the time, then have a proxy customer fill in. Getting Demo feedback from the customer is not enough. Try to get the customer involved in exploratory tests after each sprint.
  3. Stand up meeting: Let the team agree what should be the best time for meeting (usually beginning of working day). Always have it at the same time and same place. Avoid having members report to the leader. Make sure they are discussing things amongst themselves. Avoid problem solving in the meeting. Avoid having multiple status meetings. Have scrum of scrums.
  4. Testing: teach TDD (not natural for developers), unit test becomes the documentation, automation of gui test and integration test will have very important influence on build duration, keep tests independent, regression tests outside core application.
  5. Collective ownership: technology diversity is a challenge, keep project wiki updated, the team has to respect code standards, extra education and information session is required, not everyone can master all aspects from day one, assign owners for each technical to act as coach for the others
  6. Continuous integration: automated, have multiple build environments, build manager necessary in large team, one successful build per day.
  7. Refactoring: give them the courage (it will pay off), educate the team (use real smells as examples), refactor if you do not understand the code, refactor only code you are working on, only refactor when it hurts, late refactoring costs a lot, is often perceived as conflicting with iteration scope.
  8. Design: need a lead architect, assign a design coach, involve experts in 1st technical implementations, courage.
  9. Pair programming: 6 dev + 1 coach, change pairs every half day, combine experience and junior developers, exchange people each sprint, pair when you are at start phase, have new technology, have difficult business.