Embed Size (px)
Citation preview
Slide 1
Software Success Improvement
Paul GerrardGerrard Consulting1 Old Forge CloseMaidenheadBerkshireSL6 2RD UK
e: paul at gerrardconsulting dot comw: http://gerrardconsulting.comt: 01628 639173
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
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)
“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
1. Establish a sense of urgency2. Create a guiding coalition3. Develop a vision and strategy4. Communicate the change vision5. Empower broad-based action6. Generate short term wins7. Consolidate gains, produce more change8. Anchor new approaches in the culture.
Eight stage change process (Kotter)
1. Mission2. Coalition3. Vision4. Communication5. Action6. Wins7. Consolidation8. Anchoring
Eight stage change process (after Kotter)
Changes identified here
This is where your ‘test model’ comes
into play
3.1 Some Perceptions3.2 Product Quality3.3 Customer Management3.4 Organisation and Methodology3.5 Planning and Scheduling3.6 Product and Release Management3.7 Development3.8 Developer Testing3.9 System Testing3.10 Support
Section 3 – Example Findings (rapidly growing software house)
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.
Perceptions (3 of 15)
4.1 Company Management4.2 Organisation and Planning4.3 Methodology4.4 Product Management - Requirements4.5 Product Management – Project/Work Package
Management4.6 Releases/Installations/Customer Support4.7 Development - Design4.8 Development – Better Practices4.9 Development – Product Development,
Refactoring4.10 Development – Testing4.11 Training4.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 Explanation5.2 Organisation and Management5.3 Product Strategy5.4 Customer Support/Product
Improvement/Implementation5.5 Project/Change/Release Management5.6 Development Methodology5.7 Test Strategy5.8 Development Test Methodology5.9 Design Process5.10 Development Process5.11 Training
Section 5 - Implementation
Sample recommendations (3 of 73)1.Organisation and Management
1.Recommendations: 4 6 8 9 10
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.
Constraints
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.
Summary
