RAPID PROCESS IMPROVEMENT SPIN UK - 28 September 1999

1
RAPID PROCESS IMPROVEMENTSPIN UK - 28
September 1999
2
Contents

• 1. The Business Environment
• 2. Software Development
• 3. Rapid Process Improvement
• 4. Tools and Techniques
• 5. Getting Started

3
(No Transcript)
4
The Business Environment...

• Dynamic (unpredictable)
• You will encounter
• economic fluctuations
• currency fluctuations
• mergers
• re-organizations
• changes in strategy
• new management
• initiatives
• Look-ahead more than 18 months / 2 years is of
  limited value

5
...The Business Environment

• Rapid change and uncertainty are facts of
  business life
• Timing is of the essence - sequencing and
  co-ordination, not just speed

6
(No Transcript)
7
Software Development...

• Software development processes in business
• are increasingly seen as just one of many
  business processes
• are not clearly distinguished from other business
  processes
• have the same expectations are placed on them as
  on other processes
• Software processes should be
• robust enough to cope with
• merger / take over
• new business
• re-structuring
• changed business / new business
• available as required
• be managed as assets
• they are often lost

8
...Software Development...

• Software Development is not usually
  development, it can be-
• business analysis/requirements elicitation
• enhancement
• bug fix
• support
• integration
• migration
• acquisition
• bespoke
• COTS
• etc
• or any variety or combination
• Development activity changes to support activity
  as the product matures - management approaches
  should reflect this

9
...Software Development...

• Software Development is usually managed as a
  project
• This management approach is often not the most
  appropriate
• enhancement, and bug fix are repeated and low
  risk activities
• service or production line models are more
  appropriate
• (these types of activities have properties that
  genuine projects aspire torepeatable, low risk)
• overloads these activities with inappropriate and
  unnecessary activities
• Strong project orientation has hindered
  understanding and development of software
  processes
• but our project is different
• A project is a unique, complex, intrinsically
  risky piece of work

10
...Software Development...

• Ways of working
• often very well understood by those performing
  them
• difficult to communicate to others
• documentation correct but unusable (esp. to new
  hires)
• documentation is user view narrative
• unique to project or organization (and
  idiosyncratic)
• does not differentiate business, management and
  technical practices

11
...Software Development...

• There have been a number of attempts to make
  software development better meet business need
• software methods, tools
• quality approaches (e.g TQM)
• management methods
• QA
• standards,
• metrics
• .

12
...Software Development...

• Software Process Improvement (SPI) is one of the
  more successful (influential) approaches
• SPI effectively means the application of the
  Capability Maturity Model (CMM)
• Takes many of the lessons learned from earlier
  work
• Scientific Management - Taylor
• Statistic Process Control - Shewhart
• Quality Management - Deming, Juran, Crosby
• Software Development Models - Royce, Fagan,
  Boehm, Mills

13
...Software Development...

• SPI Assumptions
• software development processes are to be improved
• improvement is incremental or evolutionary (grow
  the process to build the software)
• improvement takes time
• institutionalization makes processes robust
• There are good reasons for these assumptions
• ignoring these reasons may lead to failure to
  develop a software development capability
• but they are not necessarily correct.

14
...Software Development...

• Often
• there is nothing to improve
• typical response - ...heres one from my last
  project / job / employer
• there is not the time
• typical response - ...it takes time

15
...Software Development...

• Lessons we have learned...
• ongoing long term commitment to develop process
  understanding and capability is important
• ...but long term plans are of little use -
  outmanoeuvred by events
• SPI often takes far too long to deliver real
  benefits to developers or managers (and benefits
  are frequently never explicitly identified)
• tends to focus on model requirements rather than
  solving real problems
• predicting the effects of change is difficult
• large scale SPI is difficult to manage
• large scale SPI can be inefficient and expensive
• many benefits arise from small changes made
  rapidly
• some software engineering techniques are
  fundamental
• senior management scrutiny and feedback - but
  not big budgets

16
...Software Development...

• It is most effective to
• think strategically, but act tactically
• act locally
• deliver many small simple improvements
• evaluate actual results
• discard cheap fast failures, build on successes -
  and learn from failures
• Demings constancy of purpose

17
...Software Development

• Our response to this is to develop techniques and
  tools that enable
• Rapid Process Improvement...

18
(No Transcript)
19
Rapid Process Improvement...

• What is Rapid Process Improvement?
• There are subtle but important differences to
  SPI...

20
...Rapid Process Improvement...

• Characteristics - are required and consciously
  designed in
• clearly focussed on solving real problems
• desired results stated explicitly and measurably
• results driven - not activity driven, then act
  on data
• speed (scaled to be manageable and time boxed)
• perhaps guided by model - but not model driven
• highly visible
• structured - (how, how good, when)
• local ownership - effective resource models and
  motivation
• local accountability
• opportunistic
• To achieve these characteristics you need the
  right tools
• (These characteristics should be self evidently
  desirable.)

21
...Rapid Process Improvement

• Benefits
• speed
• 80 / 20 - know which is the 20
• Time boxed
• visibility
• results driven - there are results
• learn - from successes and affordable (therefore
  admissible) mistakes
• success is the best motivator
• low cost
• rapid ROI
• short BET
• no generic training
• NO LEAD TIME...

22
(No Transcript)
23
Tools and Techniques

• Lots of anecdotal SPI reporting and evidence but
  few tools
• We have worked to identify and develop tools for
  RPI
• Three classes
• Visibility
• Frameworks
• Construction

24
Visibility...

• shows what is actually happening
• FOCUSSED QUALITY ASSURANCE
• MEASUREMENT
• ASSESSMENT
• POST IMPLEMENTATION REVIEWS
• EVIDENCE/RECORDS

25
...Visibility...

• FOCUSSED QUALITY ASSURANCE
• Provides objective visibility of the performance
  of work
• as required by senior management
• and stated in published policies
• confirms quality controls operate by sampling and
  scrutiny of records
• also may support development activities and
  improvement

26
...Visibility...

• MEASUREMENT
• (re)definition of measures identifies important
  process and product characteristics - GQM
• quantitative targets focus on performance
  essentials
• data provides real time information to developers
  and trends for longer term understanding
• (will require critical validation and
  verification)

27
...Visibility...

• ASSESSMENT
• high profile investigation of development
  activities
• can provide a valid and accurate diagnostic
• critical to act on information provided
• relate to business issues
• translate into effective actions (DevPIP)

28
...Visibility...

• POST IMPLEMENTATION REVIEWS
• at the end of project - or phase
• opportunity to informally review how things went
  - or view as a process inspection
• generally welcomed, easy to perform, generate buy
  in
• valuable information from developers
• may indicate business issues

29
...Visibility...

• EVIDENCE/RECORDS
• project / process / records / reports
• consistent
• available
• integrity

30
...Visibility

• others?...

31
Frameworks...

• to provide structure and help communications
• TACTICAL CHANGE MANAGEMENT (TCM)
• PIRL
• PROCESS IMPROVEMENT TEMPLATES
• PROCESS INFRASTRUCTURE
• PROCESS ARCHITECTURE
• others
• ( which is critical in changing expectations and
  behaviour)

32
...Frameworks...

• TACTICAL CHANGE MANAGEMENT (TCM)
• provides common structure for change
• rigorous time boxing
• structured
• involves those affected
• makes resource available
• explicit deliverables
• visible

33
...Frameworks...

• POST IMPLEMENTATION REVIEW LED IMPROVEMENT (PIRL)
• used PIRs to identify issues and trends
• provides information to process group
• process group acts

34
business objectives
Focus for PI (e.g. SEPG)
trends and issues
PIRs
Development
quick fixes
process improvement
35
...Frameworks...

• PROCESS IMPROVEMENT TEMPLATES
• process improvements vary in nature
• new
• resurrection
• change
• best practice
• know the difference and apply the correct tools.

36
...Frameworks...

• PROCESS INFRASTRUCTURE
• describes explicitly how process elements
  function in the organization
• provides a shared mental model and stability
• an example...

37
reports
reports
states
references
directs
responds
responds
justifies
monitors and support
own and refine
defends
monitors and support
support
38
...Frameworks...

• PROCESS ARCHITECTURE
• also provides a shared mental model
• and provides process stability
• some examples...

39
(No Transcript)
40
(No Transcript)
41
...Frameworks

• others?

42
Synthesis and Construction...

• PROCESS DEFINITION
• PREFABRICATED PROCESS COMPONENTS
• PROCESS WORKSHOP

43
...Synthesis and Construction...

• PROCESS DEFINITION
• a framework and guidance for process capture,
  definition and documentation
• modelling
• information capture
• technical definition
• user documentation
• publication and support

44
...Synthesis and Construction...

• PREFABRICATED PROCESS COMPONENTS - Flat Pack...
• rapid deployment of a capability
• define / design / install / operating - 8 to 12
  weeks
• QA, SCM, Project Office, Risk Management,
  Requirement Management
• well defined interfaces - interoperable
• three levels of capability to match maturity
• enables evaluation of performance rapidly
• Leads to SOFTWARE PRODUCTION ENGINEERING

45
...Synthesis and Construction...

• ...PREFABRICATED PROCESS COMPONENTS - Flat Pack
• revisit the business need...
• how do you
• replicate
• relocate
• scale up
• cost for limited run
• a software development capability?
• Requires a SOFTWARE PRODUCTION ENGINEER

46
...Synthesis and Construction...

• PROCESS WORKSHOP
• to train and deal with change requests
• an example...

47
Process Workshops used with PIRL
business objective
Focus for PI (e.g. SEPG)
trends and issues
improvement reqs.
know how
PIRs
Development
Process Workshop
quick fixes
process improvement
48

• Process Workshop

improvement reqs.
know how
Review and Approval
Workshop
Preparation
process definition
improvement
developers
49
...Synthesis and Construction...

• others?

50
Techniques...

• WORK UPSTREAM
• users have a problem
• determine source (testers perhaps) upstream
  and fix
• identify cause at next source (coders perhaps)
• determine next source upstream
• not the most potentially efficient, but actually
  effective, fast and cheap.

51
...Techniques...

• RESOURCE MODELS
• tasking
• cross project support
• TCM

52
...Techniques

• SOFTWARE FUNDAMENTALS
• quality control
• change control
• lifecycle / management reviews

53
(No Transcript)
54
Getting Started or Re-orienting Improvements...

• Start Tomorrow
• for example
• draft and get endorsement for your software
  improvement strategy - not plan
• conduct PIRs and use effective action tracking
• do an assessment (next week!)
• develop and issue s/w policies and use QA to
  monitor and enforce
• install prefabricated process components (flat
  pack)

55
(No Transcript)
56

• 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
• L I M I T E D
• 9 Spinners Court, 53 West End,
• Witney,
• Oxfordshire
• OX8 6 NJ
• www.osel.co.uk
• Tel. [phone]

57
(No Transcript)