Software Success Improvement Paul Gerrard


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Success Improvement Paul Gerrard

  1. 1. 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
  2. 2. <ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul><ul><li>In his spare time, Paul is a coach for Maidenhead Rowing club. </li></ul>Paul Gerrard
  3. 3. <ul><li>Leading Change, John P Kotter </li></ul><ul><li>Managing Transitions, William Bridges </li></ul><ul><li>Managing Change, Bernard Burnes </li></ul><ul><li>Goal-Directed Project Management, Andersen, Grude, Haug </li></ul><ul><li>Test Process Improvement, Koomen and Pol. </li></ul><ul><li> </li></ul><ul><li>15 years experience in software process improvement. </li></ul>Primary sources
  4. 4. Why is Process the Focus of Improvement? (Test Process Improvement is a Waste of Time!)
  5. 5. <ul><li>I want to improve my ( insert any activity here ) </li></ul><ul><li>_______ people improvement </li></ul><ul><li>_______ organisation improvement </li></ul><ul><li>_______ process improvement </li></ul>How to improve…  Changing people (like me) and organisation (like my company) is so hard – let’s not even think about it
  6. 6. <ul><li>There are no “practice” Olympics to determine the best </li></ul><ul><li>There is no consensus about which practices are best, unless consensus means “people I respect also say they like it” </li></ul><ul><li>There are practices that are more likely to be considered good and useful than others, within a certain community and assuming a certain context </li></ul><ul><li>Good practice is not a matter of popularity. It’s a matter of skill and context. </li></ul>The delusion of ‘best practice’ Derived from “ No Best Practices”, James Bach,
  7. 7. <ul><li>Google search </li></ul><ul><ul><li>“ CMM” – 12,100,000 </li></ul></ul><ul><ul><li>“ CMM Training” – 12,200 </li></ul></ul><ul><ul><li>“ CMM improves quality” – 4 </li></ul></ul><ul><li>A Gerrard Consulting client… </li></ul><ul><ul><li>CMM level 3 and proud of it (chaotic, hero culture) </li></ul></ul><ul><ul><li>Hired us to assess their overall s/w process and make recommendations (quality, time to deliver is slipping) </li></ul></ul><ul><ul><li>40+ recommendations, only 7 adopted – they couldn’t change </li></ul></ul><ul><ul><li>How on earth did they get through the CMM 3 audit? </li></ul></ul>The delusion of process models (e.g. CMM)
  8. 8. <ul><li>People like simple models: </li></ul><ul><ul><li>levels of maturity, stepping stones, checklists, roadmaps and outside support for credibility </li></ul></ul><ul><li>But life is much more complicated, unfortunately </li></ul><ul><li>“ Things should be made as simple as possible, but no simpler” - A. Einstein </li></ul>But process models make improvement simple don’t they?
  9. 9. <ul><li>A big problem with process is it becomes all encompassing </li></ul><ul><li>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 </li></ul><ul><li>It could be argued, that less smart people need process </li></ul><ul><ul><li>(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) </li></ul></ul><ul><li>Is our industry really staffed by such people? </li></ul><ul><li>Do we really want production-line workers? </li></ul>People need process?
  10. 10. <ul><li>“ I believe that a scientist looking at nonscientific problems is just as dumb as the next guy” </li></ul><ul><li>“ 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” </li></ul><ul><li>Richard P. Feynman </li></ul>Physics quotes…
  11. 11. <ul><li>“ I believe that a process consultant looking at non-process problems is just as dumb as the next guy” </li></ul><ul><li>“ 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” </li></ul><ul><li>PG </li></ul>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
  12. 12. Software Success Improvement
  13. 13. From this… Current Maturity Future Maturity Current Capability Future Capability Acts of Faith Better Capability = better, faster, cheaper Perceived Results Chain Process Change
  14. 14. To this… Current Constraints/ Problems Current Capability Future Capability Acts of Change Better Capability = better, faster, cheaper Actual Results Chain Changed Aspirations
  15. 15. <ul><li>Constraints are fixed headcount, budget, timescales, quality of requirements, contracts etc. </li></ul><ul><li>Problems are “testing takes too long; too expensive; can’t hire testers; bugs get through” etc. etc.… </li></ul><ul><li>Aspirations: </li></ul><ul><ul><li>Personal: personal development, fulfilment, motivation </li></ul></ul><ul><ul><li>Organisational: hero culture to team culture, outsourced, higher consistency, predictability </li></ul></ul><ul><li>Acts of change are… </li></ul>Constraints, problems and aspirations
  16. 16. <ul><li>Changes in behaviour to address specific problems (effectiveness, efficiency etc.) </li></ul><ul><li>Targeted personal and team development </li></ul><ul><li>Infrastructure change (process, techniques, tools, environments) to support the changes </li></ul><ul><li>Managed Transition… </li></ul>Acts of change – focused on constraints, problems and aspirations
  17. 17. <ul><li>Current behaviour assessed in the context of current problems, goals and constraints </li></ul><ul><li>Aspirations drive the definition of goals </li></ul><ul><li>People in the job define and consent to the required changes in behaviour </li></ul><ul><li>People supported by </li></ul><ul><ul><li>Personal/team development plans </li></ul></ul><ul><ul><li>Infrastructure investment (process, technology, tools, environment) specific to the change </li></ul></ul><ul><li>Transitions are managed, not assumed. </li></ul>Principles of change
  18. 18. <ul><li>Establish a sense of urgency </li></ul><ul><li>Create a guiding coalition </li></ul><ul><li>Develop a vision and strategy </li></ul><ul><li>Communicate the change vision </li></ul><ul><li>Empower broad-based action </li></ul><ul><li>Generate short term wins </li></ul><ul><li>Consolidate gains, produce more change </li></ul><ul><li>Anchor new approaches in the culture. </li></ul>Eight stage change process (Kotter)
  19. 19. <ul><li>Mission </li></ul><ul><li>Coalition </li></ul><ul><li>Vision </li></ul><ul><li>Communication </li></ul><ul><li>Action </li></ul><ul><li>Wins </li></ul><ul><li>Consolidation </li></ul><ul><li>Anchoring </li></ul>Eight stage change process (after Kotter) Changes identified here This is where your ‘test model’ comes into play
  20. 20. <ul><li>This is where the practitioners, with support, identify the changes to make </li></ul><ul><li>External model (TPI, TMMi, TOM, brainstorming) might provide improvement suggestions </li></ul><ul><li>Practitioners identify the specific problems, underlying causes, changes to be made, and pathway to the vision. </li></ul>Vision
  21. 21. <ul><li>3.1 Some Perceptions </li></ul><ul><li>3.2 Product Quality </li></ul><ul><li>3.3 Customer Management </li></ul><ul><li>3.4 Organisation and Methodology </li></ul><ul><li>3.5 Planning and Scheduling </li></ul><ul><li>3.6 Product and Release Management </li></ul><ul><li>3.7 Development </li></ul><ul><li>3.8 Developer Testing </li></ul><ul><li>3.9 System Testing </li></ul><ul><li>3.10 Support </li></ul>Section 3 – Example Findings (rapidly growing software house)
  22. 22. 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.
  23. 23. <ul><li>4.1 Company Management </li></ul><ul><li>4.2 Organisation and Planning </li></ul><ul><li>4.3 Methodology </li></ul><ul><li>4.4 Product Management - Requirements </li></ul><ul><li>4.5 Product Management – Project/Work Package Management </li></ul><ul><li>4.6 Releases/Installations/Customer Support </li></ul><ul><li>4.7 Development - Design </li></ul><ul><li>4.8 Development – Better Practices </li></ul><ul><li>4.9 Development – Product Development, Refactoring </li></ul><ul><li>4.10 Development – Testing </li></ul><ul><li>4.11 Training </li></ul><ul><li>4.12 System Testing </li></ul>Section 4 - Recommendations
  24. 24. <ul><li>We do ‘whole-process’ assessments </li></ul><ul><li>So, the recommendations aren’t just testing-related: </li></ul><ul><ul><li>Could be a change in requirements/development/CM… </li></ul></ul><ul><ul><li>Could be a change in attitude, leadership, policy </li></ul></ul><ul><ul><li>Could be a change in organisation </li></ul></ul><ul><ul><li>Could be a change in emphasis </li></ul></ul><ul><ul><li>Could be an agile approach </li></ul></ul><ul><ul><li>Could be a novel approach </li></ul></ul><ul><ul><li>Could be a change in personnel </li></ul></ul><ul><li>None of these changes are promoted by current testing models, but are almost always required. </li></ul>We recommend changes based on findings, not idealised models
  25. 25. <ul><li>5.1 Explanation </li></ul><ul><li>5.2 Organisation and Management </li></ul><ul><li>5.3 Product Strategy </li></ul><ul><li>5.4 Customer Support/Product Improvement/Implementation </li></ul><ul><li>5.5 Project/Change/Release Management </li></ul><ul><li>5.6 Development Methodology </li></ul><ul><li>5.7 Test Strategy </li></ul><ul><li>5.8 Development Test Methodology </li></ul><ul><li>5.9 Design Process </li></ul><ul><li>5.10 Development Process </li></ul><ul><li>5.11 Training </li></ul>Section 5 - Implementation
  26. 26. Sample recommendations (3 of 73) <ul><li>Organisation and Management </li></ul><ul><ul><li>Recommendations: 4 6 8 9 10 </li></ul></ul>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.
  27. 27. <ul><li>Improvement models implement waterfall approaches: </li></ul><ul><ul><li>Structured, systematic, bureaucratic, v-model based </li></ul></ul><ul><ul><li>Favoured by service companies selling large teams </li></ul></ul><ul><li>They try to resolve symptoms through testing, when many ‘testing’ symptoms are caused by problems elsewhere </li></ul><ul><li>Less than 5% of these approaches focus on people issues </li></ul><ul><li>IT focused, not business focused </li></ul><ul><li>Every organisation is unique, their problems and causes are probably unique too - models just can’t accommodate this. </li></ul>Alternatives are old fashioned, IT centric, inflexible
  28. 28. <ul><li>You have to treat every change project as unique </li></ul><ul><li>You need to understand how things are </li></ul><ul><li>But you also need to understand the reasons WHY they are </li></ul><ul><li>You must listen to practitioners and managers </li></ul><ul><ul><li>To hear their ideas for improvement </li></ul></ul><ul><ul><li>To align/augment ideas with the known constraints </li></ul></ul><ul><ul><li>To refine the vision to be something achievable. </li></ul></ul>Summary
  29. 29. Thank-You [email_address] Software Success Improvement