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: http://gerrardconsulting.com 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 gerrardconsulting.com 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.
15 years experience in software process improvement.
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, www.satisfice.com
“ 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
“ 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”
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.…
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
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)
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.8 Developer Testing
3.9 System Testing
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.
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.