XP2006 Day 4: Barry Boehm
Product and Process Archtiectures for Integrating Agile and Plan-Driven Methods
The talk summarised the experiences of the USC centre for Software Engineerings’s industry affiliates in using XP and other agile methods. They found that the agiel methods are effective on small proejcts, but difficult to scale up. the talk presents a set of product and process architecture frameworks taht the idnuctry affilitates are finding effective for doing risk-driven integration of agile and plan driven methods to fit the particular large-project elements’ needs to simultaneioulsy accommodate rapid change and high assurance.
Although it’s hard to scale an agile project over 100 people, big projects need to be agile in order to adapt to the changing business environment, therefore it’s acutally more important for large companies to go agile than ever before.
Barry came up with 5 critical dimensions to large scales systems which effect the choice of whether to go Agile or plan-driven:
- Size
- Criticality
- Skills
- Volatility (adaption to change)
- Culture
It was found that in large scale projects both Scrum and XP elements were used. However, there was a need to re-interpret some practices. For example the metaphor was hard to sustain across a number of different communities and the customer ended up being more than one person or else a customer proxy. Collective ownership called responsible ownership as it wasn’t always possible for everyone to be experts in all parts of the system.
In order to scale up Barry cited the following requriements:
- Business process analysis
- Risk management
- Wall gantts (story based earned value)
- Independent reviews
- Big picture architecture
Some situation dependent difference in opinion
- Simple Vs Architecture - With some parts of the system simple was best but if changes are predictable one can architect to accommodate it. Architecture checks integration before it’s coded so tha 100 people can code in parallel.
- Optional Vs pair programming vs reviews - reviews required where safety criticality was an issue
- Contract issues - large organisations have change control so have to re-negotiate memorandems if the scope changes
- New build coupled with a legacy system - impossible to refactor
- Sarbanes - Oxley - this turns the agile manefesto on it’s head: following a plan is more important than responding to change! This is an auditor manifesto and causes issues with Agile
Example - Lockheed Martin
- Agile processes (mix of scrum and XP)
- Agile modelling
- Pair programming
- Risk Managment
- Time boxing
What went well:
- Team empowered
- Short cycle times - feedback
- Continuous integration
- Customer involvement
- Pair programming
Findings
- Increased level of stakeholder involvement
- Cost of making change wasn’t flat. Fewer stories were done in 30 days as the systems got bigger
- Agile organisational processes were required - keeping track of progress etc
Critical Success Factors for Scaling Up:
- Timeboxed iterations
- Stakeholder involvement
- Adative specs and plans
- Scrum of scrums (need more leaders)
- Architecture essential but lighter
- Set expectations early
- Resist temptation to do the easy stuff first
- Use risk anaylsis to determine how more agility, discipline is enough
Relevant Agile Practices
- Short stabilised increments
- Continuous customer/developer participation
- Early test continuous integration
- Doing these systems without any documentation at all isn’t feasibile
- Welcome changing requirements
- Simple design just for current increment but refactor to accommodate later capabilities
- If parts of the system are stable and some unstable then determine which parts of the system are predictable and which aren’t
- If parts of the system are changing rapidly then architect these so that they can be modified without a ripple effect
Conclusions
- Agile methods scale up to 100 people until processes need to be adapted e.g. scrum of scrums
- However, systems need agility and product and process architectures and that help. These do look like they are scaling.
- Place for all people in the new process even though change has been hard. Put people where they feel most comfortable e.g. people good at building specs so put them where they can do this, where people are more creative let them go agile.
- Customer participation is still the biggest issue in agile development
