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.

Evolving Agile

Agile Modeling: Effective Practices for eXtreme Programming and the Unified ProcessScott Ambler gave a talk at JAVAPOLIS 07 about Evolving Agile. He started out by describing Moore’s Adoption Curve which is like a bell curve and starts out with innovators, then early adopters, peeks with early majority, start its decline with late majority and dies down with laggards. Most new technologies/processes do not manage to cross the chasm from early adopters to early majority and never make it. The innovators are always excited about new things and are ready to jump in. The early adopters believe they can get a competitive advantage so they try it. The early majority see others succeeding so they get in. The late majority need to see similar organizations doing the same thing before they step in, while the laggards need to see case studies and solid proof before committing. In most cases, the late majority and laggards come way too late to catch up to the competition.

Next Scott provides some stats from surveys done on dr dobb (www.ddj.com).

The survey shows the about 70% have adopted agile in some way. Teams that are collocated have higher success rates than distributed teams. Smaller teams have better success rates than larger teams. The survey also shows that:
  • Quality: 87% believe high quality is more important than on time and budget
  • Scope: 87% believe meeting actual needs of stakeholders is more important than building to spec
  • Money: 80% believe that providing the best ROI is more important than delivering under budget.
  • Staff: 75% believe that having a healthy workplace is more important than delivering on time and on budget
  • Schedule: 61% believe that delivering when the system is ready to be shipped is better than delivering on schedule
Next Scott moved to cover some items often skipped when talking agile.
On any project there needs to be project initiation where the team and stakeholders are determined, funding is secured, a team room is setup. This also includes initial scope modeling.
Spend some time getting initial requirements, architecture modeling. You always need to answer
What are you going to build? How much will it cost? How long is it going to take? How are you going to build it?

Other issues include release into production, pilot, documentation, training, end of phase testing, sign-off, final testing environment, data conversion. Also one needs to understand production needs (operations and support)

Test driven development is not meant to scale. One should use the right tool for the right job. When working with small issue, one can do just in time specs by writing tests followed by code to make the tests pass. When dealing with big issues then we need to draw sketches, use index cards, etc. For validation, we can run tests to ensure code still works, but this is smoke testing or confirmation testing. It is good, but not enough. It validates to our understanding of the requirements. This makes the assumption that stakeholders understand what they want and can communicate that to us. We need investigative testing. TDD tests to spec. Investigative testing is testing outside the box (key strokes, integration, usability, break the system).

Monday, December 10, 2007

The Amazon.com Technology Platform: Building Block for Innovation

At QCON London 2007, Werner Vogels gave a talk on Amazon.com technology platform. The Amazon technology platform services 5 kinds of clients:

1. Amazon.com retail customers

2. Retail market place sellers

3. Enterprise Retail Customers

4. Associates

5. Web Service Developers

Werner describes the original Amazon business model as increase in selection, leads to more customers, which leads to more sellers and so on. This results in a fly wheel in motion which leads to growth. Economy of scale leads to lower cost structure and thus lower prices which feeds back into more customers which gets an additional swing in the fly wheel.

Amazon started out with selling books. Due to the enormous selection, books are the ideal candidates to sell online.

From books, there was a move for more breadth and depth (screws, springs, grocery, movies, TVs).

Werner explains how to extended selection, Amazon invites other vendor onto the platform, even if they offer the same products at lower prices. These vendors get to take advantage of reviews and customer feedback. Amazon takes in xml feeds containing item and inventory descriptions and pushes back information about transactions.

In terms of Services, Amazon offers webstores, fulfillment, and selling on Amazon.

Ecommerce platform: opening up the data through web services. It will drive traffic back to application.



Clients can pick and choose the services of the platform that they want