Agile Practices: The impact on Trust in Software Project Teams Bo Sun Xiaowei Wang Mingchang Zhao.

Agile Practices: The impact on Trust in Software Project Teams

Bo SunXiaowei WangMingchang Zhao

Page 2

Conforming to plan was no longer the primary goal

Major change in the requirement, scope, and technology that are outside the development team’s control often occur within a project’s life plan

The cost of change grows

Why do we need agile software development:

Page 3

1. The unforgiving honesty of working code 2. Effectiveness of people working together with good will

Agile method:

Extreme Programming

Scrum

Adaptive Software Development

Page 4

Manifesto for agile software development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value

Individual and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Page 5

Advantage for agile software development:

Produce the first delivery in weeks, to achieve an early win and rapid feedback

Invent simple solutions, so there is less to change and making those changes is easier

Improve design quality continually, making the next story less costly to implement

Test constantly, for earlier, less expensive, defect detection

Page 6

Page 7

Focus on team work and trust:

Team proximity and intense interaction between team members are hallmark of all agile methods.

XP:Pair programming;

Crystal, Scrum, ASD:Advocate close collaboration practices including barrier-free collocated teams;

Page 8

The importance of trust within a teamDefine:

Trust is a shared belief that you can depend on each other to achieve a common purpose.

Feeling able to rely upon another person;

Cooperating as a group;

Taking thoughtful risks;

Experiencing believable communication.

Page 9

Agile practice study

Page 10

People are core in agile practices!

Agile Manifesto places great emphasis on the team, encouraging autonomy and giving individuals the environment and support they need to get the job done.

An environment where stakeholders trust and respect each other is both a prerequisite for and a consequence of using agile methods.

Page 11

Need for trust The emergence of agile teams has increased the

importance of trust .

A cohesive team of members who collaborate and trust each other can be difficult.

Trust requires team members to believe that their colleagues possess the knowledge, competence, and integrity to complete their assigned tasks.

Page 12

Agile practice case study

We are focusing on 3 agile practices.

a) They are most commonly used.

b) Each one requires the collective participation of all team members.

The study is conducted across 3 teams with diversity in both distribution and industry setting.

Study lasts for 6 months.

Page 13

Diversity in teams Case A is a distributed team in a financial services

organization that develops software for internal business units.

Case B is a colocated team in an engineering organization that manufactures and supplies industrial robots.

Case C is a colocated team in an organization that develops software for the insurance industry.

Page 14

Results and analysis of study

We found that agile methods increased trust by increasing

1. transparency

2. accountability

3. communication

4. knowledge sharing and feedback.

Page 15

Status transparency and visibility

Iteration planning meeting:

1. requirements

2. indicidual task assignment

3. estimate of each task

Stand-up meeting:

1. day-to-day progression

2. potential dalays

Page 16

Iteration retrospectives:

1. achievements of this sprint goal

2. experience for next sprint

From the perspetive of QA: All team members and POs are aware of what they require on the project and set expectation accordingly.

Changes and any new feature are not surprising.

Transparency and visibility enhance congruence and vigilance which increace trust in software development.

Page 17

Accountability and collective responsibility

Team members feel responsible for not only their own estimates and promise, but also other members.

developers: tasks assigned to them

POs: obtain information from customers

Two ways of estimates in three cases

A: experts from particular area

B and C: collaborative estimates and discussion until final agreement.

Page 18

Demonstrate their own competence and trustworthiness.

They have a say or they can have a say.

Page 19

Open and frequent team communication

In traditional software development, communication only when it is required. (e.g. status meeting or debug)

Advantages: Development of common awareness Ask for or offer help PO's existance in team Perspective of new members

Promote a good sense of will and belonging

Lessen the magnitude of discrepancies

Page 20

Knowledge sharing and feedback

Supportive environment:

Any one can throw and pick up a question at anytime.

No reprimand, no negative view.

Timely feedback and response

From the perspective of PO:

Efficient in realization of features.

Build confidence if the team can deliver in time.

Challenges of agile practice

Page 22

Challenges of Trust in Agile Team

Trust was strong in all three teams and reinforced by agile practices, particularly from the QA and PO perspectives.

We identified four factors that increased trust but also created challenges for teams.

Page 23

External Visibility on Project Tasks

Caused by : Transparency and visibility of project status to all stakeholders

Organizational personnel external to the team have visibility on task status but perhaps not on actual causes of delays, if any.

Page 24

Team Pressure

Caused by : Accountability and collective responsibility

This pressure was entirely self-inflicted, but it might be consequent to the increased visibility of tasks and personal accountability to the team.

Page 25

Tension between the PO and the Team

Caused by : Accountability and collective responsibility

Some team members considered PO to be a team member and others did not.

Some POs themselves didn’t feel they were part of the project team.

Page 26

Developers Accessibility to the PO

Caused by : Open and frequent communication within the team

From a developer’s perspective, this access must be managed and controlled so that ad hoc requests aren’t suddenly added to the requirements list without agreement from the team.

Page 27

Tendency to Underestimate Tasks

Caused by : Sharing knowledge and obtaining feedback

It is difficult to accurately estimate unknown tasks even though team members were mostly experienced and quite familiar with the development environment.

Page 28

Value of the Retrospective

Caused by : Sharing knowledge and obtaining feedback

Most interviewees placed little value in retrospective.

The retrospective limited the communication, knowledge-sharing, and feedback mechanisms for building trust.

Page 29

Conclusion

Types of generic trust that can affect agile methods: Interpersonal trust

Relational trust

System trust

Trust in behavior

Trust in belief

The factors that maintain trust in agile methods: Honesty

Communication

Cultural understanding

Personal relationships

Working together

Performance and capability.

Page 30

To agile PM

If you think the team has underestimated their work and are leaving velocity on the table,

If you feel that the team isn’t working hard enough or are committed enough to their work,

If you feel that quality is poor and it isn’t improving sufficiently or you feel that the team isn’t taking product quality seriously,

If you’ve got a fixed date software delivery to make and you wonder if the team is going to get there,

If you think the team has underestimated their work and are leaving velocity on the table, TRUST the team.

If you feel that the team isn’t working hard enough or are committed enough to their work, TRUST the team.

If you feel that quality is poor and it isn’t improving sufficiently or you feel that the team isn’t taking product quality seriously, TRUST the team.

If you’ve got a fixed date software delivery to make and you wonder if the team is going to get there TRUST the team.

Page 31

Reference

[1] Hasnain, Eisha, and Tracy Hall. "Investigating the role of trust in Agile methods

using a light weight systematic literature review." Agile Processes in Software

Engineering and Extreme Programming. Springer Berlin Heidelberg, 2008. 204-207.

[2] http://www.projecttimes.com/robert-galen/the-agile-project-managerdo-you-trust-

your-team.html

THANK YOU