Fairly narrow, development-focused but also useful
Tackle risks up front
Be iterative and adaptive
Our position is to defuse the religious/brand name debate and focus on the practices
Our Practices – the Jazz Way milestones first API first end game retrospectives always have a client continuous integration community involvement new & noteworthy adaptive planning continuous testing consume your own output component centric drive with open eyes validate reduce stress learn enable attract to latest transparency validate update dynamic teams show progress enable explore validate live betas feedback sign off common agile practices common Open Source practices scaling-up practices Our unfair advantage
Example Team: Rational Team Concert for Z/OS Research Haïfa, Israel 3 4 2 6 10 3 8 1 37 developers Development Beijing, China Development Pornichet, France Mgt, Development Raleigh, US UA San Jose, US Development Austin, US Arch, Development Paris, France Development Perth, Australia Rational Team Concert SCM Work Items Build
Disciplined agile delivery is an evolutionary (iterative and incremental) approach that regularly produces high quality solutions in a cost-effective and timely manner via a risk and value driven lifecycle.
It is performed in a highly collaborative, disciplined, and self-organizing manner within an appropriate governance framework, with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders.
Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.
“ Fits just right” process
Continuous testing and validation
Consistent team collaboration
Rapid response to change
Ongoing customer involvement
Frequent delivery of working solutions
The disciplined agile lifecycle: An extension of Scrum
Agile Requirements Management Rational Requirements Comp RMC Practices: Requirements Management, Use-Case Driven Development Rational Team Concert Rational Requisite Pro
Requirements are prioritized by stakeholders
Requirements are estimated by the development team
Requirements will evolve throughout the project
Stakeholders see working software each iteration
Stakeholders can change the level of funding as appropriate