The Magic of Whole Team Thinking

fran.ohara@inspireqs.ie

Fran O’Hara

Inspire Quality Services, Ireland

The Magic of Whole Team Thinking

Fran O’Harafran.ohara@inspireqs.ieInspire Quality Services

Supporting Agile and Testing transformation

The whole team approach in Agile

• The use of a whole-team approach to product development is one of the main benefits of Agile development

• It means involving everyone with different knowledge and skills to ensure project success - testers, developers and the business representatives working together in every step of the development process.

• Benefits include:

– Enhancing communication and collaboration within the team

– Enabling the various skill sets within the team to be leveraged to the benefit of the project

– Making quality everyone’s responsibility

State of Agile

Versionone Survey:

• Challenges experienced adopting/scaling agile

– Company philosophy or culture at odds with core agile values 63% (55%*)

– Lack of experience with agile methods 47% (60%)

– Lack of management support 45% (31%)

– General organizational resistance to change 43% (33%)

– Lack of business/customer/product owner 41% (45%) * EuroSTAR DIT Webinar poll ‘The Seven deadly Sins of Scrum’ – Fran O’Hara - Sept ‘17

High Performing Teams

Transcendent

• A sense of purpose beyond the ordinary

Autonomous

• Self-organising and self-managing

• Team members decide themselves how they are going to do the work

Cross-functional

• All the skills needed to complete the project

The New New Product Development Game – Takeuchi & Nonaka

Transcendent

• A sense of purpose beyond the ordinary

Shared Values are key• E.g. delivering quality, respecting

others, importance of learning and innovation, fairness, honesty

Common goal• Sense of purpose and accountability• Vision• Business outcome focused

Autonomous

• Self-organising and self-managing

• Team members decide themselves how they are going to do the work

A team should have a

compelling mission.

clear boundaries in terms of information flow, alignment with other organizational

units, resources.

give the authority to self-manage within

these boundaries

provide stability for some period

of time

Indicators of a self-organizing team are: • Scrum ceremonies are productive, • the team enjoys the work • members help each other• team tackles its own impediments• new ideas are forthcoming• teams are pulling work for themselves

Whole Team Accountability Trust is a two-way street

In Scrum, ‘committed’ means dedicated• E.g. to the sprint goal

A 3 step process – training, coaching, mentoring1. Select team members and Develop capabilities – Training e.g.

• agile values/principles/methods

• domain/technology

• behavioural training

2. Inspect & adapt - adopt a coaching style to see if the members are facing any difficulties.

• more support and guidance at the beginning

• this phase results in innovative ideas and improved results from the team.

3. Sustain - Assign mentors who can help the team go to the next level.

• Teams aren't static; they change over time. Building a self-organizing team is an ongoing process, and we're really never done. Whenever a team's composition changes, we need to repeat the whole process.

Based on Scrum Alliance ‘Self-Organizing Teams: What and How’ Nitin Mittal

© 2016 Inspire Quality Services10

Culture/people/mindset

© 2016 Inspire Quality Services11© 2017 Inspire Quality Services

• If you experiment with the move to Agile, starting with your business reasons for it and using feedback to ensure that you’re on the right track, you too can ease your transition.– Johanna Rothman

• The biggest secret in making the transition to Agile isn’t in the technicalities of the new process, but in “how” the change initiative is approached. Leaders and managers must be clear in their communication around how the change will affect each team member and what the benefits are. It is by building trust and removing doubt and fear that resistance disappears.– Susanne Madsen

Some wise words…

Role of test line management

Based on ‘Keys to Transitioning to Agile Testing’, Bob Galen

Whole Team?• Scrum team

• Product Owner• Scrum Master• Development Team – ‘Developers’!

Testing:• Testing competency• T-shaped – ‘Technical awareness’• Developer – Tester Pairing

Co-located versus Distributed

Cross-functional

• All the skills needed to complete the project

From: Lisa Crispin, 201114

Role of manual tester

- John Ferguson Smart – BDD in action

Collaborate, collaborate, collaborate

Integrating test into the lifecycle

Code CodeCode & Bug Fix

Test

Sprint 1 Sprint 2

Code

Test

Sprint 1 Sprint 2

Code & Bug Fix

Code

Test

Code & Bug Fix

Code & Bug Fix

Test

Sprint 1 Sprint 2

Code & Bug Fix

Test

A

B

C

!

Test design 1st

What can the team do re testing 1/2

• Commit to whole team approach to testing, quality

– Consider a ‘team charter’

• Discuss and agree on the test strategy/approach

– Release/feature test plans ?

• Quality risks: Characteristics of concern e.g. functional (accuracy, interop..), usability, security, performance, availability, etc.

• Types and levels of test abstraction, techniques, coverage, test automation..

• Light & adaptive – reflected in an evolving Definition of Done

19

Unit/Component layerDeveloper Tests

API/Service layerAcceptance Tests

GUI layer

Manual Tests

Automate at feature/work-flow level

Automate at story level

Automate at design level

Based on Mike Cohn

Quality Risks

Code & Bug Fix

Test

Code & Bug Fix

Test

Sprint 2

Code & Bug Fix

Test

Sprint 3Sprint 1

……

Agile Test Strategy/approach

20

PBI/Story level

• Unit tests passed,

• unit tests achieving 80% decision coverage,

• Integration tests passed

• acceptance tests passed with traceability to story acceptance criteria,

• Exploratory testing completed,

• code and unit tests reviewed,

• static analysis has no important warnings,

• coding standard compliant,

• published to Dev server

Increment/Sprint level

• Reviewed and accepted by PO,

• E-2-E functional and feature tests passed

• all regression tests passing,

• exploratory testing completed,

• performance profiling complete,

• bugs committed in sprint resolved,

• deployment/release docs updated and reviewed,

• user manual updated

Release level

• Released to Stage server,

• Deployment tests passed,

• Deployment/release docs delivered,

• large scale integration performance/stress testing passed

(Not part of scrum guide)

Embed agreed test approach into the teams ‘Definition of Done’

Sample definition:

What can the team do re testing 2/2

• Use retrospectives

– Inspect & adapt at team and organisational level

– Identify obstacles to testers, testing

– Focus on one or two problems at a time

– Experiment & learn

• Celebrate successes no matter how small!

Thank you!

Any Questions/Experiences

to Share?www.inspireqs.ie

fran.ohara@inspireqs.ie