Rational Unified Process and how Software Configuration Management

Rational Unified Process and how Software Configuration Management (SCM) solutions can improve project management and governance Mark Dickinson

How using RUP and Collaborative techniques facilitated geographically distributed development. Mark Dickson

Agile RUP: balancing agility and discipline in public sector development Mark Dickson

Or… “Take your RUP and shove it” Mark Dickson

What we do Outsourcing § IT § Business Process Technology § Full lifecycle from concept to decommissioning § Cross-technology from legacy to enterprise § Integration services across all applications § Standalone services from upgrades to training Consultancy – embedded throughout our services stics i t a t s Vital , 300 h: c 7 t g n e r t wide s 4 m World £ 376. : r e v e turno ffshor o f o 2005 r ide K prov UK U t s e the larg s into 00 e c i v r : c 3, 4 se h t g n e tr ons hore s plicati p § Offs a K er U t lead e k r a e M ment k offic e c g a a b n in ma player K U g n i A lead ing s s proce

Typical Project Profiles for using RUP in Xansa § 2 -4 year programmes § Iterative projects, 6 to 18 months duration § Team sizes vary from 20 -120 § Mixed Teams, geographically dispersed § Range of technologies, combining § Bespoke development § Package implementation § Legacy integration

Typical Challenges § People § § § Initiative § Motivation § Skills Organisation § Command & Control management § Extremely large number of “stakeholders” Process § Multiple management & development process § Bureaucratic (by definition) § Predictive planning in extremis § Instinctively waterfall Information § Broad range & large volumes § Complex business rules governing access Technology § Extremely diverse § Largely ageing

Opportunities MODERNISING GOVERNMENT Joined Up Government Adoption of new technologies Innovation & Creativity Agile Government e-Government by 2008 Removal of unnecessary regulations Information Age Government

How Agile are we? § Individuals & Interactions over Processes & Tools? § Not yet – requires experience & judgement § Customer Collaboration over Contract Negotiation? § Yes – but could do better § Responding to Change over following a plan? § Yes in principle – in practice it depends on things other than RUP f i n a M le i g A o t s e § Working Software over Comprehensive e h T Documentation? § Sometimes? Depends what the documentation is Note: “over” not “instead of”

Individuals & Interactions over Processes & Tools § Good tooling in place to support distributed teams § Process defines individuals & interactions Technology Summary: Systems integration & development using J 2 EE, Bespoke build, CRM, HR, Legacy integration & various specialist packaged applications Dev team + Business Xansa Site Client Site 1 so what’s our process? CCM, RP, CQ, Plus web clients, Lotus Notes Client Site 2 Client Site 3 Business Dev team

Individuals & Interactions over Processes & Tools THE AGILITY TIGHTROPE MSP DSDM SCRUM PRINCE 2 XP ITIL RUP MSF

Individuals & Interactions over Processes & Tools § Adapt the Process § Combination of… § § Method abc (for Xansa Corporate governance) PRINCE 2, ITIL (for OGC compliance) DSDM (for “Agile” and collaborative practices) RUP (for software engineering best practices) Plenty of work by others to re-use: DSDM/Rational (1999) FMI Solutions RUP plug-in OAK IT (RUG, Drury 2001)

Framing in PRINCE 2 Programme Management Directing a Project Controlling a Stage Managing Product Delivery iteration Starting up a Project Initiating a Project Inception Elaboration Construction Transition iteration Planning Manage Stage Boundaries Close Down a Project

ITIL / RUP § ITIL defines an iterative development life cycle § “The main reason for the introduction of increments and iterations in the development process is management of the risks associated with uncertainty and changing requirements. ” § Our clients had dabbled with iterative development – through DSDM

DSDM / RUP Pre-Project Inception Post Project Transition Elaboration Construction

Software Development Activities Combines: Method abc DSDM RUP The substance of the work in RUP terms is unchanged

Customer Collaboration over Contract Negotiation Empowered JOINT teams Problem solving in groups § DSDM “Business” roles § Executive Sponsor § Visionary § Ambassador User § Defines active responsibilities § Plus DSDM “businesscentred development” practices, including “Customer” representation WITHIN the team § Facilitated workshops § Evolutionary prototyping

Customer Collaboration over Contract Negotiation: Example: Use Case Workshops Use Case Model Systems Analyst BAD Use Case Specification Detail a Use Case Visionary UI Prototype Ambassador User Architect UI Developer

Customer Collaboration over Contract Negotiation: Example: Use Case Workshops § Workshops held to detail the § § Functional and Non– Functional Requirements Joint group (3 -8 business & technical people) Based around USE CASES & System Qualities Write use case specifications Prototype UI

Working Software over Comprehensive Documentation: Coding is continuous § Software development is an early activity § Software developed from the outside in

Working Software over Comprehensive Documentation Architecture: BDUF? § NO! § The Big Picture - defining § § STRUCTURE and externally discernable properties of the system Teams of people need to work to a shared vision or plan of construction § Architecture is a technical plan Can start INFORMAL and grow in formality as decisions are made Do just enough architecture to get the team working Architecture must be developed collaboratively

Working Software over Comprehensive Documentation Analysis & Design JAD Sessions Design is discovered through use case realisations developed during collaborative workshops

Working Software over Comprehensive Documentation: Coding is iterative Software is developed iteratively *within* a time box SAD UI Prototype Developed during Use case workshops & refined thereafter Subsystem Interfaces Produced by Architect/designer During use case design Design Guidelines Subsystem development Assigned to distributed teams

Working Software over Comprehensive Documentation: How much documentation? Written Materials make a project / process LOOK heavyweight Written (and USED!) processes make the TEAM more Agile! The more we write down, the more information we able to share!

Responding to Change over Following a Plan § Each project in a programme was is run against a strict time-box § Predictive planning within that overall context is limited § Feasibility Study § High Level Design activity (produce a SAD, BAD & PRL) § “n” iterations of “development” (tacit elaboration/construction) to complete the build § “n” iterations of Transition to deliver the product

Responding to Change over Following a Plan § The Prioritised Requirements List acts as a work list for the project and iteration § Mo. SCo. W techniques are used to plan what work from the PRL is delivered in each iteration § Only 60% is guaranteed § Ultimately, requirements are cut to fit the available time § Additional, unexpected time-boxes are allowed!

Basic Do’s & Don’ts § DO make sure the Team § § § Manager walks the floor DO make sure that planning is a joint activity DO sit people together whenever possible DO use joint workshops – they really work! DO manage time-box scope DO Track progress diligently DO remember to re-estimate each iteration! § DON’T confuse iterative § § § development and phased delivery DON’T do “Gantt chart management” DON’T let Plans solidify DON’T let plans get too detailed DON’T allow Iterations to overlap DON’T let Joint teams fragment

Responding to Change over Following a Plan project management is the key to agility

Thanks for listening…Any Questions? § Or… § Email me at mark. dickson@xansa. com