Agile Process Development and the APD Tool-set
O X F O R D S O F T W A R E E N G I N E E R I N G
C o n s u l t I n g S o f t w a r e E n g I n e e r s
RPI has been renamed: We have renamed the RPI method and toolset ‘Agile Process Development’ because it describes better what RPI is and because, frankly, the word ‘agile’ gets attention that no other word does in the software community. We aren’t going to obscure the old name – we are proud of the work done under the rpi banner – but apparently a rose by any other name doesn’t smell as sweet.
The approach is
exploratory and structured in small increments, where the work can be readily
co-ordinated and the results evaluated. This type of approach limits risks
and is often far more acceptable than the centralized 'one size fits all'
process improvement initiatives so often imposed on software professionals,
and, ironically, it can achieve the results desired by the corporate
initiatives faster and at lower cost. (The similarity of
Real improvement is
greatly aided if the right tools are available. We have been collecting and
The tools are well described and teachable to equip process engineers to improve understanding, and to change intrinsically complex, subtle and often highly coupled software development and support activities in a controlled and measurable way. They have been acquired and developed over a number of years and will continue to be developed and added to. Tools are classified in three main categories; visibility, construction and infrastructure. A fourth ‘catch all’ category, ‘other’, is used for tools that do not fall readily into one of these categories. We are keen to develop this classification as a tool in its own right to enable process engineers to more readily select the right tool for the job. Any suggestions or pointers to better classification systems would be very welcome.
…and if you have tools or assets you are willing to share we are keen to hear from you too.
Tools for Visibility:
These tools are designed to show how software development and support is performed. They answer the questions: “what is happening?”, “what effect have our process improvement activities or technology introductions had?”. These tools give process engineers data to work with.
V - 1 Post Implementation Reviews and Retrospectives: fundamental tools for understanding and improving development and test practice
V - 2 Assessments, Appraisals and Audits: potentially powerful diagnostic tools - but often misused or abused
V - 3 Focussed Quality Assurance (FQA): A low risk, low cost method for introducing and ramping up a quality assurance capability for non engineering software organizations
V - 4 Records: the team, project and organization’s memory – often disregarded or overlooked
V - 5 Formal Technical Reviews (FTRs): A fundamental software engineering practice. (Actually a set of practices of variable formality and rigour, from walkthroughs, to inspections, to pairing.
V - 6 Defect Models and Defect Tracking: Provide insights into product qualities, process efficiency, and project performance – defects are software development’s lab rats.
V - 7 Measurement: Needs and deserves to be treated as a tool in its own right, but is integrated into many of the other tools too, to the extent that RPI could also be called MPI (Measurable Process Improvement)
V - 8 Using Performance Targets: a double edged tool
V - 9 Cost of Quality (CoQ)
V - 10 Visualization: of patterns, processes, products and projects
V - 11 External Consultants: getting best value from their knowledge and experience.
V - 12 New Hires: for an objective but informed perspective of process performance, development and test capability, and organizational culture.
Tools for Construction and Change:
Software development is dependent on both technology and the people using it. These tools are designed to aid the change of technology, processes, expectations and behaviour.
C - 1 Developing a Process Improvement Plan (Dev-PIP)
C - 2 Process Definition: A fundamental tool that ensures that process definition work establishes a genuine and valued process baseline, not shelf-ware.
C - 3 Tactical Change Management (TCM): A simple framework for process improvement that delivers results fast and reduces risk.
C - 4 PIR Led Process Improvement (PIRL): Fundamental - start with this.
C - 5 Process Improvement Templates: Characterize the types of process improvement, and selects the right process improvement tools.
C - 6 Joint Application Development (JAD): It works for software – and software practices and processes too
C - 7 Making Checklists: Fast, fun and an effective method of distilling and sharing wisdom.
C - 8 Knowledge Transfer:
C - 9 Process Workshop (PW): A method for tactical process improvement
C - 10 Prefabricated Software Process Components: An approach for the rapid installation of software development capability
C - 11 Strategy: Development: (and validation and maintenance)
These tools are models or templates for robust process infrastructures. They eliminate ambiguity redundancy and contention, and enable effective communications and collaboration.
F - 1 Software Process Infrastructure
F - 2 Process Improvement Infrastructure
F - 3 Software Process Architecture
F - 4 Tools Group
The difficult to classify tools:
A selection of difficult to classify tools and techniques.
T - 1 ‘Upstreaming’
T - 2 Resource Models
T - 3 Leverage and ‘Reverse Leverage’
T - 4 Visible Migration (or development) of process and practice assets
T - 5 Skills Recognition
T - 6 Process Sponsors and Process Champions
T - 7 Other Tools (mostly from other disciplines)
T - 8 Process Action Teams (PATs)
For data sheets for these tools or further information email: email@example.com
© Copyright OSEL 2004 - 2012