RAPID PROCESS IMPROVEMENT SPIN UK - 28 September 1999 - PowerPoint PPT Presentation

Loading...

PPT – RAPID PROCESS IMPROVEMENT SPIN UK - 28 September 1999 PowerPoint presentation | free to view - id: 75c768-NWU3M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

RAPID PROCESS IMPROVEMENT SPIN UK - 28 September 1999

Description:

SPIN UK - 28 September 1999 Contents 1. The Business Environment 2. Software Development 3. Rapid Process Improvement 4. Tools and Techniques 5. – PowerPoint PPT presentation

Number of Views:52
Avg rating:3.0/5.0
Slides: 58
Provided by: IanS172
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: RAPID PROCESS IMPROVEMENT SPIN UK - 28 September 1999


1
RAPID PROCESS IMPROVEMENT SPIN 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. 44 (0) 1993 700878

57
(No Transcript)
About PowerShow.com