I recently took a course on agile development with Scrum, through Construx here in Bellevue. [Construx are generously offering to fill up to 20% of their classes for free, to people that are unemployed and have recently been laid-off.] Some of the lessons I learnt from the class that I am considering adding to the process are:

• Time-boxing - Scrum's alternative to an iteration is a sprint. The main difference between a RUP iteration and a sprint is that whereas an iteration encompasses the development activities that lead to a stable, executable version of the product, a sprint is a development effort performed over a fixed period of time culminating in a release of the product. In order to achieve a stable release we cannot guarantee the length and effort that goes into an iteration. In a sprint, the time to finish is guaranteed, but the content of the resulting deployment cannot be predicted for certain. If we remove the clause that an iteration must result in a stable release, then we could time-box RUP's iterations.

• The PBI - Every product development team has a prioritized list of items affecting the product or a Product Backlog of Items list. A PBI may be of any form that causes work for the product team. For example, requirements, change requests, issues or even design and test changes. I would like to see a similar concept explicitly described for each discipline, with a roll-down effect from Business Modeling through to Deployment. Say a change request comes from the business, this is added to the business modeling backlog. When the BA has addressed this change an item is added to the Requirements backlog. The systems analyst addresses the item in their backlog and adds an item to the implementation application backlog. Similarly, the designers add to a Test backlog and testers create Deployment backlog items. These are prioritized between the two teams at the time of being added to the backlog (this is different to Scrum, which prioritizes items at the beginning of each Sprint).

• One of the things this course, not so much taught me, but re-enforced, is a concept that I have been trying to get a handle on for almost as long as RUP has been around; is the idea that we do not build a product and release it to our customers, then go build another product, but even if using a waterfall SDLC, we release a product to the customer and then have to continue maintaining it for the duration of its life. Iterative methods, like RUP and Scrum, take that concept and embrace it, by planning for many releases of the product up front. (Waterfall generally plans for a single 'big-bang' release.) In the early days of RUP, I remember a conversation between two people who now both work for IBM, where one was asking 'Where is the Maintenance phase of RUP'. Sometime later the answer came back, it is there, during maintenance you start another iteration of the whole process. As someone brought up on waterfall, it's been a long journey, but I finally believe that I grasp the idea that we never finish a product, we continuously build the product until we kill it.