This report describes the creation and evolution of the (modified) agile methodology implemented at Sabrix, Inc., a start-up enterprise-class software company. The company was delivering alpha quality software to early adopter customers on a weekly basis, using urgency as the primary driver for product development. New features and bug fixes were completed in a manner similar to a soccer game between two teams of five-year-olds, with everyone on the team chasing down the latest emergency. This report discusses the agile software development discipline that enabled Sabrix to evolve from that chaotic environment to the point where the company was balancing both urgency and importance to drive product direction. This discipline enabled the company to actually deliver a "Release", and move forward into a new product architecture.
The Unified Development Process (USDP) and especially its implementation from Rational Software Corporation, the Rational Unified Process (RUP), is a comprehensive process covering almost all aspects of software development projects. However, due to the great level of detail provided by RUP many professionals consider RUP as not practical for small and fast paced projects.
This presentation reports the experiences made with RUP in two small projects with teams of three to four developers. RUP proved to be adaptable to the needs of small projects and was very effective in both projects. One key to the successful application of RUP in small projects is the careful selection of a proper subset of artifacts and keeping these artifacts very concise and free from unnecessary formalisms. This report goes into the details of what it takes to make RUP agile, how it was applied on the two projects, and how it was configured. Also covered is what elements of RUP contributed to the success of one project, and why RUP could not prevent less than optimal results in the other project.
Extreme Programming appears to be a solution for discovering and meeting requirements faster (through close customer collaboration) as well as creating quality software. In practice we found XP did deliver high quality software quickly, but the resulting product still failed to delight the customer. Although the finished product should have been an exact fit, the actual end-user still ended up slogging through the system to accomplish necessary day-to-day work. This report describes using interaction design in an agile development process to resolve this issue. Using interaction design as a day-to-day practice throughout an iterative development process helps our team at Tomax Technologies deliver high quality software, while feeling confident the resulting software will more likely meet end-user expectations. The method of Interaction Design followed here is based on Constantine and Lockwood's Usage-Centered Design. Recommendations are provided on how to practice an agile form of U-CD and how to incorporate bits of Interaction Design thinking into every day development and product planning decisions.
Participants should be ready to learn from others' experiences.