I am a big fan of agile development, especially Scrum and test-driven development.

On Sept 20th, I attended the presentation SCRUM at Borland: A Case Study of Transition hosted by SEM SIG.

It's a very good presentation about how Borland adopted Scrum, and the insights and lessons learned.

The presentation slides can be downloaded here. But you must sign up for SEM SIG Yahoo group. If you have problem with the download link, you can browse the file folder of the Yahoo group to find it. There are other past presentations available for download as well.

Notes

• Scrum adoption started as grassroot effort in Borland. Engineers generally start the effort of using Scrum. Took internal marketing effort to promote scrum
• Scrum implementation is transparent to upper management at big organizations. Someone like VP of Engineering still provide a development roadmap to the rest of the organization
• The moves( at all levels) for Scrum:
  1. plan
  2. do
  3. inspect
  4. adapt
  5. REPEAT 1-4
• The mis-conception is that agile dev. has no plan. Agile dev. has plan. The short term plan(sprints in scrum's term) is well defined, and the long term plan is just higher level
• Product backlog - criteria for each backlog item: customer value, size, risk , origin, dependencies
• Product owner's responsibility: maximize values and control risk of each sprint
• Used Excel for product backlog
• Do the simplest thing first, add capability later
• Don't take a couple of months to architect. Break the architecture down. Develop working software on top of a evolving architecture
• Story granularity – down to the level of what the end user expects from using the software.
• 3 weeks/sprint, 3-4 sprints/releases
• Delivering biz value every sprint( working software )
• Working software include testing. Develop testing cookbooks
• Agreement on what done means
• End of each sprint: done unit/integration tests. Automated test is a must
• toward the end of release: do system, regression, performance. can have a hardening sprint for this kind of testing purpose
• Documentation in each sprint: diagrams, derived user stories
• Team size - 7 individuals including QA/Dev/Doc/Product owner. Each team joins scrum meetings of other teams twice a week to communicate project status
• HCI(Human Computer Interaction) experts create UI mockups. Go over with charter customers to get early feedback on UI
• UI changes so much. Hard to doc well every sprint. Suggestion from the audience: write manual first. then deduct story.
• Pre-planning: 5% of sprint time dedicated to grooming the backlog for next sprint
• Develop goal story to document best practices in style, look & feel, security, coding/design guideline
• Develop user story for Legacy/data migration
• charter customer engagement: involve tech. support when talking to charter customers, to support *early* candidate release of software
• Team goal is 75% of the project. Individual goal is 25%.
• How to fit QA into the process: QA develops test cases against user stories, and can do test on working software at the end of each sprint
• How to fit documentation into the process: get them involved in user story development
• VC and Lawyers start using Scrum for process management
• Control is through inspection and adaptation
• Don't get caught up in scrum. Apply reality big picture. Get everyone aware of the big picture while working on user stories. Synthesize product definition from marketing, sales, customers, analysts, field , competitors. Without the big picture, it's like building a puzzle without a picture of the puzzle on the box
• Hybrid approach to agile development. There's no silver bullet in implementing scrum

Thoughts

Automated testing is a must for successful implementation of quick iteration(sprints) because that's the only way to quickly validate working software. It doesn't matter whether you use test-first or test-driven developments. You must automate testing.

No matter which agile methodology you use, it's really important not get caught up in following exactly what the book says. Adapt your process to your organization's particular structure, culture, team, and needs.

No matter whether it's called agile or not, what really matters is whether real business value is delivered with better customer acceptance, controlled cost, controlled risk, better quality, and better ROI.

I also want to echo the point that automated testing is so vital to the success of agile/iterative development. Without it, one can't really verify QUICKLY with CONFIDENCE whether your new changes break any of the working functionality delivered in a earlier sprint/iteration.

Whatever your do, the golden rule is to show progress and business values along the way, pro-actively manage risks! Doesn't that sounds like what you'd do in every profession?

Tags: development agile scrum sdforum borland methodology