Effective Quality Facilitation | Beyond Normal

Effective Quality Facilitation – Beyond Normal

ByRamkumar RamachandranHead – QualityRenault Nissan Technology & Business Centre India Pvt Ltd,Chengelpet

Quality Facilitators – A Breed by themselves Eye for Delivery Tech Savvy Facilitator – An oxymoron? Eye for Engineering Eye for finer aspects The All-Friends-World Fear Vs. Fate Vs. Professional Respect Escalation for lunch Success = ƒ (Interactions with project team) Do-This-Do-That Syndrome Facilitation Success Indicators Case Studies

Contents

What this session is all about

Quality Facilitators – The Normal Breed

• Software Quality Analysts – SQAs are a breed by themselves.

• Have full responsibility to ensure compliance.

• Have less authority to enforce compliance.

• Is seen as threat in project or threatened by project.

• Hit by Project team and by QA Seniors.

• Always wants to make a point but makes enemies.

• World View Compliance is PM’s capability, non-compliance is Facilitator’s inability.

Quality Facilitators – A Class Breed

• Facilitator is always visible to the delivery team

• PM ensures Facilitator’s presence in all status review meeting

• Facilitator conducts training on processes

• Project schedule is closely tracked by Facilitator

• Facilitator has planned reviews with PMs

• Networks to bring best practices from others

• Is also visible to the customer

• Is contacted by delivery team for any change in delivery methodology

• Knows to make a point without making enemies

My Mantras

I’m going to talk about my Mantras. The Mantras that I’ve practiced over a period of time and have yielded results.

Yes, there is no rocket science in this, but it is pure distilled common sense.I guarantee you results by following these Golden Rules with near nil exception.

Believe in me and start this journey…!

Mantra # 1 – Eye for Delivery

• All the processes are for successful delivery – never lose this focus

• All the facilitation has to converge into delivery success

• Bother more about contract, cost sheet, effort over run, design, code quality etc

• Never harp upon documents for document-sake

• Be equipped to relate a compliance to successful project delivery. For eg. Why code review?

• Resist short-term process violations with justifications on long-term benefits

Eye for Delivery (contd.)

• Never force a consistently successful project to shed its result yielding practices

• Remember, wherever a project makes consistent quality deliveries, there is definitely a ‘system’ working for them – Analyze it

• This ‘system’ could be ‘set of practices’ by individuals in the project or the organization’s QMS

• When ‘set of practices’ is outside QMS, help the project to: -– Comply to organization QMS and tailor their needs (OR)– Enrich QMS with their local best practices (OR)– Share them as ‘Best Practices’ to SEPG

Mantra # 2 – Tech Savvy Facilitator – An Oxymoron?

• Remember – we are in Information Technology Industry

• Being tech savvy is a need for everyone in IT

• Tech Savvy Facilitator need not be tech wizard

• It is important to

– Know various technologies (Client Server, Web based, Multi-tier, SOA etc.)

– Their strengths and weaknesses, broadly

– How an architecture fits into a business solution

– How design fits the architecture

Tech Savvy Facilitator – An Oxymoron? (contd.)

Tech Savvy Facilitator – An Oxymoron? (contd.)

Tech Savvy Facilitator – An Oxymoron? (contd.)

Exercise – 1

A bank has decided to automate in a major scale. The broad goals to be achieved are: -

- Availability of central customer database- Branches should be able to retrieve & update

customer information- Customers should be able bank in any branches

How do you want the architecture to look like?

(10 minutes to discuss 5 minutes to present per group)

Mantra # 3 – Eye for engineering

• Facilitators should ensure that engineering artifacts are reviewed• Facilitators should have gone through RS Pressman fully atleast once• As Facilitator, one should get a hold of: -

• Application Architecture• High level design• Coding standards availability

• Facilitators should refer to LLD and verify the implemented code• Facilitators should be able to appreciate that ‘design’ has to finalized

and then implemented in the code• A deep glance into design and getting a good hold of the same is

always good• Facilitator is not a Technical Architect, but still should have an

engineering ‘flair’

Eye for engineering (contd.)

• Indicators for Engineering ‘flair’: -o Check coding standards for current technologyo Understand the application architectureo Glance through the HLD / LLDo Ensure code review is a ‘scheduled activity’o Ensure an ‘effective’ code review – effort proportional to defectso Sample passed test cases and run the application to confirm the

sameo Study requirement and confirm that traced test cases are

adequate

Mantra # 4 – Eye for finer aspects

• Verify activities in its ‘natural’ flow

• For eg. Design baseline – how many activities to be verified?

o Check first baseline of requirements in CM repositoryo Check design document baseline date > Requirements baseline

date in CM repositoryo Check design review date <= design baseline dateo Check for timesheet effort in and around corresponding activityo Review defects count proportional to review efforto Update of RTM after design baseline date

Eye for finer aspects (contd.)

• Eg. Project with ‘crunched’ effort• Ask the PM whether he/she can ‘really deliver the project in this

duration / effort’• In the event of predicted delay, check for dependencies on the

client’s side• Is there prioritization of the features, so critical ones get

delivered first• Are the skill levels of team members good enough to do delivery

‘right the first time’?• If any of the above is a ‘NO’, has the same identified as risk?• Has this risk been discussed with appropriate Seniors and/or in

appropriate forums?• Seasoned SQAs can take it up with their senior or with PM’s

senior and discuss the issue

Eye for finer aspects (contd.)

Requirements sign off

Skill fitment

Test Case Adequacy

Effort / Size Estimation

Testing Efficiency

Effective CM practices

Design effectiveness

Metrics collection & analysis

Effective Defect TrackingProject Scheduling

Exercise – 2

Form groups, and let each group take one of the scenarios of

above slide and provide the maximum finer ‘verifiable activities’

that can be done to confirm it’s compliance

(5 minutes to discuss 3 minutes to present per group)

Mantra # 5 – The All-Friends-World

• Pointing out issues is not pointing out enemies• Facilitators always talk about ‘systemic-problems’• Reporting process gap is professional and not an ‘un- friendly act’• Facilitator reporting issues is NOT the same as reporting NC reported in PCR / IQA• Have ‘clinical-detachment’ to the issues you report into

the project• Do not ‘grade’ a person based on issues reported in their project• You can always report huge process issues and still have coffee with the Project Manager

The All-Friends-World (contd.)

• Points to ponder

o Why should the SQAs not be emotionally attached to their findings?

o Why is the facilitation not like an audit?

o Why should the SQAs harmonize with an ever-erring PM?

Exercise – 3

The PM of a project where the effort estimate has no relation to the schedule with no consistent monitoring mechanism has to be told about the same.

o Participants to write down the risks

o Do a role play on how they will communicate the same to PO

o Trainer will act as the PM

( 5 minutes / group)

Mantra # 6 – Fear Vs. Fate Vs. Professional Respect

• Fearo ‘How will it sound if I tell code review is not done?’o ‘I very well know that design is not base lined, but can

I stop the coding activity?’o ‘If I report that person ‘X’ has not closed all defects,

will it harm him/her’o ‘This is new technology, and project team tells UML

addresses both requirements & design. I’m not sure how to facilitate’

o ‘The PL wants me to prepare the plans. If I escalate this I will lose the rapport’

Fear Vs. Fate Vs. Professional Respect (contd.)

• Fateo ‘Never does the project hear me. It is always like this, cooking

documents is a way of life’

o ‘Whatever I tell will be vetoed by Seniors, better let me not use my energy is such things’

o ‘The culture is not pro-process. My effort will only be futile in such environment’

o ‘I get hit from both sides. This is a donkey’s job’

o ‘If only I was a developer, the job would’ve been more cushy’

Fear Vs. Fate Vs. Professional Respect (contd.)

• Professional Respecto Mr. PM, please understand that I’ve got equal concern about

project’s quality delivery

o New technology, ok, but did you see any need for change in processes?

o Coding started, ok, but what is the logic you are going implement, without a baselined LLD?

o You are creating a local practice, but have you formally tailored it

o I can prepare the plans for you the first time, but remember that you have to ‘own’ it

Mantra # 7 – Escalation for lunch

• Rapport with the project is key for successful process rollout

• Any process violations has to be discussed, accepted and implemented

• Any ‘undue’ delay in closing the identified gaps has to be reported ‘formally’

• Non-escalation and subsequent project bombing would reflect bad on facilitation

• Escalation without enough project handholding will as well look like passing-the-buck

Escalation for lunch (contd.)

• Points to pondero What should the SQAs do when the PM is requesting not to

escalate?

o What should the SQAs do when it is clear that nothing can be done even if escalated?

o High possibilities of soured relationship post – escalation, how to handle this?

Exercise – 4

• What are the scenarios that you would escalate?• How will you do the escalation?

(5 minutes to discuss 5 minutes to present per group)

Mantra # 8 – Success = ƒ (Interactions with project team)

• SQAs is a key stakeholder in the project

• SQAs should bother about successful deliveries by projects that they facilitate

• SQAs to be treated as ‘Delivery Team Member’

• SQAs should know majority of the project team members by name, not just PM

• Majority of the project team members should know the SQAs too

• SQAs should have ‘planned interactions’ with the project team

Success = ƒ (Interactions with project team) (cont)

• SQAs should follow a 40:40:20 interaction philosophy

• 40% of the time personal in-place interactions

• 40% of the time desktop reviews

• 20% of the time generic QA activities

• This is more rule-of-thumb may vary based on project’s nature

• Interact with every role players in the project

• SQAs should approach everyone with clear agenda

Success = ƒ (Interactions with project team) (contd)

• Roles whom the SQAs should interact

Project Lead

Developers

Business Analyst

Customer

Testers

Project Manager

DBA

Delivery HeadPre-Sales team memberPMO team member

On-site coordinator

Points to ponder

• How does the SQAs get to know the team members?

• Should the SQAs keep meeting the Developers / Testers often?

• SQAs gets all the info from PM, still is it required to interact with other?

Exercise – 5

What are the questions that has to be put to Developer / Tester?

• Participants should list out the questions

• Trainer will play the role of Developer / Tester

• Participants to play the role of SQA’s

( 5 minutes / group)

Mantra # 9 – Do-This-Do-That Syndrome

• SQAs should NEVER ever tell the project ‘Do this, because that’s what QMS wants’

• SQAs should only ‘reason out’ the need for QMS practice

• SQAs should also take the ‘risk mitigation’ route of process compliance

o ‘If you don’t plan for code-review, then…’o ‘If you don’t use the design template, then…’

• As a pre-requisite, SQAs should have a thorough knowledge on QMS

• SQAs should be able to answer any needs of QMS

Exercise – 6

• Reason out the need for the following: -– Need for SDLC– Need for templates– Need for metrics / quality goals– Need for traceability matrix– Need for CAR meeting– Need for IPP– Need for design– Need for baselining CI– Need for release audit– Need for code reviews

(10 minutes – Free-for-all)

Facilitation Success Indicators

Under normal circumstances: -

• Smooth deliveries of the project• Defect decrease across shipments• SQAs involved in all critical project reviews• SQAs is consulted for any change in practice• SQAs is invited to present in client meetings• SQAs is able to tell easily the current ongoing activity of the project• SQAs is well aware of the current project challenges on various fronts• SQAs is invited for project celebrations…!

Note: The ownership of project delivery is always with PM. SQAs is an enabler for good project deliveries

Case Study – 1

The story of a complicated technology and compliance challenges

Case Study – 1

A project with an effort of 350 person years of effort for modernizing sea port handling. This involves complicated solutions for logistic companies, customers, sea farers, governmental bodies etc.

The technology was mixture of n-tier, mobile based and web-based solution. Government used it from their desktop, customer from web and few others from their handhelds.

The Delivery Head felt that there should be strict process compliance from day one. What are the key activities for project’s success that an SQA should be looking into?

(15 minutes for discussion & preparation / 5 minutes for presentation)

Case Study – 2

The dilemma of a diluted estimation

Case Study – 2

• Arjun work for ‘Astra Teksolutions’. He is not a very happy soul these days. After taking up the current project as PM for a Belgian client, life has become too hectic. This project was to develop a focused solution for Belgium diamond factory.

• Arjun’s organization, with a zeal to get the first diamond domain deal, bent backwards. The initial effort Arjun provided with around 5% cushion, was 73 person months.

• The Belgium client’s CIO was a great negotiator. He informed ’43 person months. Take it or leave it’. Astra never had an inclination to leave this project. Arjun’s boss was considerate and told Arjun that 12 person months cost would be borne by the company. Still, Arjun has to manage with the 55 person months of effort

Case Study – 2 (cont)

• Arjun has lost his sleep. His dreams are nightmares of ‘Death March’

projects. Normally, a systematic guy, Arjun wants to induct a good SQA so that the final product does not have bombs.

• You are the SQA for this ambitious and effort-starved project. What will you do to minimize the damage and maximize success?

(15 minutes for discussion & preparation / 5 minutes for presentation)

Summary

• Facilitator is a major stakeholder

• Technical knowledge is an asset

• Never worry about escalation

• Meet more

• Command professional respect

• Success Indictors

Before Signing Off

Queries

The floor is yours…..!

Thank You