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

2. 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:

3. 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

4. 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

5. 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

6. Page  6

7. 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;

8. Page  8 The importance of trust within a team Define: 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.

9. Page  9 Agile practice study

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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

16. 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.

17. 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.

18. Page  18 Demonstrate their own competence and trustworthiness. They have a say or they can have a say.

19. 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

20. 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.

21. Challenges of agile practice

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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.

30. 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.

31. 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