Software Success Improvement Paul Gerrard
Upcoming SlideShare
Loading in...5

Software Success Improvement Paul Gerrard






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Software Success Improvement Paul Gerrard Software Success Improvement Paul Gerrard Presentation Transcript

  • Software Success Improvement Paul Gerrard Gerrard Consulting 1 Old Forge Close Maidenhead Berkshire SL6 2RD UK e: paul at gerrardconsulting dot com w: t: 01628 639173
    • Paul is the founder and Principal of Gerrard Consulting, a services company focused on increasing the success rate of IT-based projects for clients. He has conducted assignments in all aspects of Software Testing and Quality Assurance. Previously, he has worked as a developer, designer, project manager and consultant for small and large developments using all major technologies and is the webmaster of and several other websites.
    • Paul has degrees from the Universities of Oxford and London, is Web Secretary for the BCS SIG in Software Testing (SIGIST), Founding Chair of the ISEB Tester Qualification Board and the host/organiser of the UK Test Management Forum conferences. He is a regular speaker at seminars and conferences in the UK, continental Europe and the USA and was recently awarded the “Best Presentation of the Year” prize by the BCS SIGIST.
    • Paul has written many papers and articles, most of which are on the Evolutif website. With Neil Thompson, Paul wrote “Risk-Based E-Business Testing” – the standard text for risk-based testing.
    • In his spare time, Paul is a coach for Maidenhead Rowing club.
    Paul Gerrard
    • Leading Change, John P Kotter
    • Managing Transitions, William Bridges
    • Managing Change, Bernard Burnes
    • Goal-Directed Project Management, Andersen, Grude, Haug
    • Test Process Improvement, Koomen and Pol.
    • 15 years experience in software process improvement.
    Primary sources
  • Why is Process the Focus of Improvement? (Test Process Improvement is a Waste of Time!)
    • I want to improve my ( insert any activity here )
    • _______ people improvement
    • _______ organisation improvement
    • _______ process improvement
    How to improve…  Changing people (like me) and organisation (like my company) is so hard – let’s not even think about it
    • There are no “practice” Olympics to determine the best
    • There is no consensus about which practices are best, unless consensus means “people I respect also say they like it”
    • There are practices that are more likely to be considered good and useful than others, within a certain community and assuming a certain context
    • Good practice is not a matter of popularity. It’s a matter of skill and context.
    The delusion of ‘best practice’ Derived from “ No Best Practices”, James Bach,
    • Google search
      • “ CMM” – 12,100,000
      • “ CMM Training” – 12,200
      • “ CMM improves quality” – 4
    • A Gerrard Consulting client…
      • CMM level 3 and proud of it (chaotic, hero culture)
      • Hired us to assess their overall s/w process and make recommendations (quality, time to deliver is slipping)
      • 40+ recommendations, only 7 adopted – they couldn’t change
      • How on earth did they get through the CMM 3 audit?
    The delusion of process models (e.g. CMM)
    • People like simple models:
      • levels of maturity, stepping stones, checklists, roadmaps and outside support for credibility
    • But life is much more complicated, unfortunately
    • “ Things should be made as simple as possible, but no simpler” - A. Einstein
    But process models make improvement simple don’t they?
    • A big problem with process is it becomes all encompassing
    • Process folk sell process and cast all things in terms of it, forgetting that people who are smart, succeed in spite of process, not because of it
    • It could be argued, that less smart people need process
      • (By less smart, we're talking about people who need so much structure and enforced discipline they can only operate in the military, or in prison probably)
    • Is our industry really staffed by such people?
    • Do we really want production-line workers?
    People need process?
    • “ I believe that a scientist looking at nonscientific problems is just as dumb as the next guy”
    • “ It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong”
    • Richard P. Feynman
    Physics quotes…
    • “ I believe that a process consultant looking at non-process problems is just as dumb as the next guy”
    • “ It doesn't matter how beautiful your process model is, it doesn't matter how smart you are. If it doesn't agree with reality, it's wrong”
    • PG
    Process quotes Using process change to fix cultural or organisational problems is not going to work Improving test in isolation is not going to work either
  • Software Success Improvement
  • From this… Current Maturity Future Maturity Current Capability Future Capability Acts of Faith Better Capability = better, faster, cheaper Perceived Results Chain Process Change
  • To this… Current Constraints/ Problems Current Capability Future Capability Acts of Change Better Capability = better, faster, cheaper Actual Results Chain Changed Aspirations
    • Constraints are fixed headcount, budget, timescales, quality of requirements, contracts etc.
    • Problems are “testing takes too long; too expensive; can’t hire testers; bugs get through” etc. etc.…
    • Aspirations:
      • Personal: personal development, fulfilment, motivation
      • Organisational: hero culture to team culture, outsourced, higher consistency, predictability
    • Acts of change are…
    Constraints, problems and aspirations
    • Changes in behaviour to address specific problems (effectiveness, efficiency etc.)
    • Targeted personal and team development
    • Infrastructure change (process, techniques, tools, environments) to support the changes
    • Managed Transition…
    Acts of change – focused on constraints, problems and aspirations
    • Current behaviour assessed in the context of current problems, goals and constraints
    • Aspirations drive the definition of goals
    • People in the job define and consent to the required changes in behaviour
    • People supported by
      • Personal/team development plans
      • Infrastructure investment (process, technology, tools, environment) specific to the change
    • Transitions are managed, not assumed.
    Principles of change
    • Establish a sense of urgency
    • Create a guiding coalition
    • Develop a vision and strategy
    • Communicate the change vision
    • Empower broad-based action
    • Generate short term wins
    • Consolidate gains, produce more change
    • Anchor new approaches in the culture.
    Eight stage change process (Kotter)
    • Mission
    • Coalition
    • Vision
    • Communication
    • Action
    • Wins
    • Consolidation
    • Anchoring
    Eight stage change process (after Kotter) Changes identified here This is where your ‘test model’ comes into play
    • This is where the practitioners, with support, identify the changes to make
    • External model (TPI, TMMi, TOM, brainstorming) might provide improvement suggestions
    • Practitioners identify the specific problems, underlying causes, changes to be made, and pathway to the vision.
    • 3.1 Some Perceptions
    • 3.2 Product Quality
    • 3.3 Customer Management
    • 3.4 Organisation and Methodology
    • 3.5 Planning and Scheduling
    • 3.6 Product and Release Management
    • 3.7 Development
    • 3.8 Developer Testing
    • 3.9 System Testing
    • 3.10 Support
    Section 3 – Example Findings (rapidly growing software house)
  • Perceptions (3 of 15) 1. “No one can test”. There is a perception that no-one in the company is testing well enough to stabilise and improve the quality of the product. The support/test team are split between support and testing and support always takes priority. The team aren’t ‘career testers’ or focused on criticising and ‘breaking’ the product and haven’t had any formal testing training. Developers do not perform thorough unit testing. Requirements are not reviewed. 2. “No one is responsible for quality”. Although one could say everyone is responsible for quality, no one owns it because all groups are under pressure to compromise and see no way of resisting that pressure. No one owns quality because they don’t have authority to say no. 3. There has been a reluctance to implement a more structured process because of past experience. When a dedicated QA manager was recruited, they found it difficult to implement even basic processes. Probably their approach was to write processes and assume they could implement themselves. This negative experience discouraged attempts to try alternatives so practices are largely unchanged.
    • 4.1 Company Management
    • 4.2 Organisation and Planning
    • 4.3 Methodology
    • 4.4 Product Management - Requirements
    • 4.5 Product Management – Project/Work Package Management
    • 4.6 Releases/Installations/Customer Support
    • 4.7 Development - Design
    • 4.8 Development – Better Practices
    • 4.9 Development – Product Development, Refactoring
    • 4.10 Development – Testing
    • 4.11 Training
    • 4.12 System Testing
    Section 4 - Recommendations
    • We do ‘whole-process’ assessments
    • So, the recommendations aren’t just testing-related:
      • Could be a change in requirements/development/CM…
      • Could be a change in attitude, leadership, policy
      • Could be a change in organisation
      • Could be a change in emphasis
      • Could be an agile approach
      • Could be a novel approach
      • Could be a change in personnel
    • None of these changes are promoted by current testing models, but are almost always required.
    We recommend changes based on findings, not idealised models
    • 5.1 Explanation
    • 5.2 Organisation and Management
    • 5.3 Product Strategy
    • 5.4 Customer Support/Product Improvement/Implementation
    • 5.5 Project/Change/Release Management
    • 5.6 Development Methodology
    • 5.7 Test Strategy
    • 5.8 Development Test Methodology
    • 5.9 Design Process
    • 5.10 Development Process
    • 5.11 Training
    Section 5 - Implementation
  • Sample recommendations (3 of 73)
    • Organisation and Management
      • Recommendations: 4 6 8 9 10
    Constraints ID Recommendation Cost Quick Change Quality Time 4 Conduct a post implementation review of major releases. Periodically review the costs of bug fixing and enhancements Work Packages. Learn lessons. Make changes. 6 Identify key resources who are “bottlenecks”, “irreplaceable” or have conflicting roles (e.g. team leadership and team membership). Require these staff to mentor/coach a colleague(s) (who may have to be hired) to reduce the risk of over dependency/burnout etc. 8 Define specific roles, objectives, responsibilities for PS, product management, development, documentation, testing, support in the context of software product development, maintenance and support.
    • Improvement models implement waterfall approaches:
      • Structured, systematic, bureaucratic, v-model based
      • Favoured by service companies selling large teams
    • They try to resolve symptoms through testing, when many ‘testing’ symptoms are caused by problems elsewhere
    • Less than 5% of these approaches focus on people issues
    • IT focused, not business focused
    • Every organisation is unique, their problems and causes are probably unique too - models just can’t accommodate this.
    Alternatives are old fashioned, IT centric, inflexible
    • You have to treat every change project as unique
    • You need to understand how things are
    • But you also need to understand the reasons WHY they are
    • You must listen to practitioners and managers
      • To hear their ideas for improvement
      • To align/augment ideas with the known constraints
      • To refine the vision to be something achievable.
  • Thank-You [email_address] Software Success Improvement