The work-reflection-learning cycle - Department of Computer and ...

More documents

Recommendations

Info

Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009 respect to some quality and with respect to alternatives. For instance, in reflection on a process, the congruence with, or deviation from, some other process, whether real (e.g. the process of a previous project) or imagined (e.g. an alternative course of the same process, or the ideal process as prescribed in a model) will typically be considered. We subscribe to the view that human activity is basically social [10, 11] and that reality is socially constructed [12]. Individual members of a social world, such as a project team, belong to different social worlds and have varying degrees of involvement in these worlds over time [11, 13]. Reflecting on project experience involves the alignment of different participants perspectives. Strauss [11] refers to Mead on the issue of how a social world reflects on its history: The temporal spans of group life mean that the aims and aspirations of group endeavor are subject to reviewal and recasting. Likewise past activities come to be viewed in new lights, through reappraisal and selective recollection. ..History, whether that of a single person or of a group, signifies a coming back at self (Mead 1936). Strauss uses the term trajectory to denote the course of any experienced phenomenon as it evolves over time. Events as they unfold, e.g. in a project, form a trajectory, and from each point in time there are many possible trajectories onwards. Taking the experienced phenomenon into consideration, different individuals trajectories will be different even when they largely comprise the same events. What actually happened, is a question of interpretation and reconstruction. Also, trajectory is given meaning in a particular situation of use [14]. For instance, the same sequence of information elements presented after an intermediary deadline in a project will be seen in a different way if used for purposes of coordination rather than to learn from the process. In sum, there is a lot of trajectory context which is not available from its representation (e.g. a textual description). Strictly, then, a trajectory is not a sequence of single elements of information as (re)presented, but as used. For practical purposes in what follows, however, we will frequently refer to trajectory as the trajectory as represented, e.g. a set of information elements, chronologically ordered. Doing so, we keep in mind that the representation will gain meaning through situated sense-making the essence of the sought-after reflection. 2.2. A case of reflection: SE postmortem reviews We now turn to reflection as part of software engineering (SE) work practice. SE work is typically performed in teams and structured as projects. The trajectory of a SE project is typically guided by a lifecycle model incorporating phases and iterations. Options range from strictly and moderately structured models (e.g. traditional waterfall, RUP) to agile approaches (e.g. XP, SCRUM) [15]. A process model typically specifies or recommends a division of labor and a set of artifacts to be used and produced. Generally, deadlines for project deliverables heavily impact on the day-to-day experience of SE project work. To cope with the complexity of work and avoid the all too frequent failures in SE projects, efforts are needed to understand project history beyond the status information needed for day-to-day articulation work. We will point to three major activities for which it is useful to review project history for purposes of reflection. First, capturing and making explicit the design rationale has been seen as important to developers understanding of the system and as a source of learning for new team members [16, 17]. Second, postmortem reviews are conducted to learn from experience within and across projects in an organization [18]. Third, supervision of SE project teams in educational settings involves gaining understanding of, and providing advice for, the project process [19]. In what follows, we will focus on postmortem reviews. What is commonly known as a postmortem review is a collective learning activity organized for a project that has either finished a major activity or phase or has ended. Postmortems are conducted to reflect on what happened in the project in order to improve practice for individual participants and for the organization as a whole. A post mortem report is part of the review result. Several approaches to postmortems have been proposed in the literature and taken into use in industry. The process typically takes from half a day to three days and is guided by a facilitator. Different approaches diverge over issues like homework or not, structured vs. open discussion, presence of management, appropriate output (e.g. how to make a useful report) and learning focus (tacit or explicit knowledge). The approaches provide lists of steps in the review process [18]. A problem with postmortem reviews is that they are not heavily used in industry despite the recognized need to learn from software engineering failures [20]. IT (Information Technology) specialists point to a number of barriers relating to set-up, data collection, data analysis and knowledge sharing. Some of these challenges relate to the availability of relevant information on the project process and the means available for structuring that information. Three of the barriers [20] (pp.77-78) are: 2 Authorized licensed use limited to: Norges Teknisk-Naturvitenskapelige Universitet. Downloaded on February 5, 2010 at 09:00 from IEEE Xplore. Restrictions apply. 152
Proceedings of the 42nd Hawaii International Conference on System Sciences - 2009 1) Insufficient integration with existing learning systems: .[..] (e.g. reporting systems, quality control systems, and informal knowledge sharing). 2) Simple information and complex issues: Information used in post mortem evaluations is limited and simplified compared to the complexity of the issues involved in system development. 3) Information overload: Post mortem evaluations are overwhelming because there is too much to reflect on. 2.3. The use of project wikis as lightweight project management tools To address current usage of project wikis and the types of information contained in the wikis, we refer to a case study reported in [21]. The case is an undergraduate project course in software engineering (SE). The projects are organized to be as close to industry SE projects as possible. Teams of 3-5 students work half time on their projects throughout their sixth (and last) semester in a Bachelor of Informatics study program. Each team has an external customer providing a development task unique to that team. The customer is responsible for providing necessary information on requirements and feedback on the development of the product. Further, each team has a supervisor from course staff providing guidance on the project process. The project deliverables includes a report in three versions, as well as a working software solution for the customer. Strong independence on part of the students is required. The teams are responsible for managing stakeholder communication and project organization as well as choosing an appropriate process model and development and collaboration tools. Four out of the nine teams in the 2007 cohort of our case made use of project wikis, and three teams were active wiki users throughout the entire project. Two different wiki tools were used in the 2007 teams: DokuWiki and MediaWiki. An exploratory case study was made by this author on the role of the wikis in these projects [21]. The researcher was course coordinator, but did not evaluate the projects. Access to the wikis was granted for purposes of research. Data for the study also comprised interviews with the teams as well as various project documentation. In the study, the project wikis were found to serve an integrative role along several dimensions of project work, enabled by the flexibility and automatic support for capturing history offered by the technology [21]. These findings demonstrated that the project wikis simultaneously served as knowledge repositories, means for staging the projects, coordination mechanisms, and shared workspaces. The more purposes for which a project wiki has been used, the greater the potential to find useful information there about the corresponding aspects of project work. For instance, if day-to-day coordination and allocation of tasks to team members is done with the aid of to-do-lists on the wiki main page, it is possible to use the wiki to reconstruct who did the work in various areas over time. If emotional expressions relating to the experience of project work have been added to the wiki, the wiki may be used to reconstruct at least part of the story of what it was like to work in the project over time. A content page from a project wiki is shown in Figure 1. This is the upper part of the main page of the wiki referred to in Section 4, and the particular page revision is from April 16. 2008 at 12:13. A project main page typically contains overview information about the project, e.g. news bulletins and to-do-lists, and links to various information useful to the project team. Below the header there are links to previous and next versions of the page, making it possible to chronologically traverse page versions. Surrounding the user-created contents of the page are menus providing access to various functionality, e.g to switch to editing mode, contribute to a discussion of the page, or view its history. Whereas this type of functionality is representative of wikis in general, the exact design shown is specific to DokuWiki. Figure 1. Wiki content page (Main page of team A) On basis of contents pages, the links between them, and the various page revisions, wiki tools offer metapages with synthesized information. This includes overviews of all pages, the history of changes to one 3 Authorized licensed use limited to: Norges Teknisk-Naturvitenskapelige Universitet. Downloaded on February 5, 2010 at 09:00 from IEEE Xplore. Restrictions apply. 153
Page 1 and 2:
Birgit Rognebakke Krogstie The work
Page 3 and 4:
Figure 1: Most used terms in the th
Page 5 and 6:
Abstract In project based learning,
Page 7 and 8:
Preface This thesis is submitted to
Page 9 and 10:
Acknowledgements I would like to th
Page 11 and 12:
Contents 1 Introduction ...........
Page 13 and 14:
Research paper P4 135 Research pape
Page 15 and 16:
Figure 17: Support for learning in
Page 17:
Abbreviations CSCL CSCW IS NITH NTN
Page 20 and 21:
The work-reflection-learning cycle
Page 22 and 23:
Page 24 and 25:
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
Page 34 and 35:
Page 37 and 38:
3 Software Engineering student proj
Page 39 and 40:
Software Engineering student projec
Page 41 and 42:
Page 43 and 44:
Page 45:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 55 and 56:
5 Results This chapter presents an
Page 57 and 58:
Results The background of P2 is a l
Page 59 and 60:
Results project management and coll
Page 61 and 62:
Results proposed in P5 was to allow
Page 63 and 64:
Results Analysis of the results sho
Page 65 and 66:
Results archives are found to conta
Page 67 and 68:
Results (SVN). Trac provides lightw
Page 69:
Results Figure 15: A model outlinin
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 81 and 82:
7 Evaluation In this chapter, I eva
Page 83 and 84:
Evaluation adds to the CSCW literat
Page 85 and 86:
Evaluation 7.3 Evaluation of the re
Page 87 and 88:
Evaluation In the longitudinal stud
Page 89 and 90:
Evaluation According to the princip
Page 91 and 92:
Evaluation However, only some of th
Page 93 and 94:
Evaluation to design is problematic
Page 95 and 96:
8 Conclusion and further work This
Page 97 and 98:
Conclusion and recommendations for
Page 99 and 100:
9 References Abran, A., Moore, J. W
Page 101 and 102:
References Cobb, P. (1994). "Where
Page 103 and 104:
References Herbsleb, J. D., Mockus,
Page 105 and 106:
References Leont'ev, A. N. (1981).
Page 107 and 108:
References Stahl, G. (2002). "Build
Page 109 and 110:
Glossary B Boundary object - artifa
Page 111 and 112:
Glossary maintaining the system aft
Page 113 and 114:
Appendix A: Research papers P1 P2 P
Page 115 and 116:
Research paper P1 Title: Cross-Comm
Page 117 and 118:
Cross-Community Collaboration and L
Page 119 and 120: the course staff may improve the co
Page 121 and 122: 4: Case findings: students’ view
Page 123 and 124: own account of why each artifact is
Page 125 and 126: Research paper P2 Title: Power Thro
Page 127 and 128: Power Through Brokering: Open Sourc
Page 129 and 130: Due to the openness of OSS communit
Page 131 and 132: 5.1.2 Second phase (February-May):
Page 133 and 134: Getting from the second to the thir
Page 135 and 136: 6.2.1 Benefits for SE student proje
Page 137 and 138: Research paper P3 Title: Do’s and
Page 139 and 140: DO‟S AND DON‟TS OF INSTANT MESS
Page 141 and 142: a chat window is opened. As soon as
Page 143 and 144: three examples in the form of excer
Page 145 and 146: Example 2. Excerpt from an IM log s
Page 147 and 148: Example 3. Excerpt from an IM log s
Page 149 and 150: immediate feedback in the heated di
Page 151 and 152: Acknowledgements Thanks to Monica D
Page 153 and 154: Research paper P4 Title: The wiki a
Page 155 and 156: The wiki as an integrative tool in
Page 157 and 158: type of use can be seen as an examp
Page 159 and 160: ecome integration, and we identifie
Page 161 and 162: project. Typically, a clean-up was
Page 163 and 164: 5.1 The wiki as a knowledge reposit
Page 165 and 166: 6. Conclusion We have shown how pro
Page 167 and 168: Research paper P5 Title: Using Proj
Page 169: Proceedings of the 42nd Hawaii Inte
Page 173 and 174: Proceedings of the 42nd Hawaii Inte
Page 179 and 180: Research paper P6 Title: Shared tim
Page 181 and 182: Shared timeline and individual expe
Page 183 and 184: presentation. In 2008, there were 1
Page 185 and 186: congruent’ to sets that seem to o
Page 187 and 188: team members and the co-constructiv
Page 189 and 190: Research paper P7 Title: A Model of
Page 191 and 192: A Model of Retrospective Reflection
Page 193 and 194: 420 B.R. Krogstie Fig. 1. Shared ti
Page 195 and 196: 422 B.R. Krogstie information about
Page 197 and 198: 424 B.R. Krogstie and to express ho
Page 199 and 200: 426 B.R. Krogstie 4.2 The Temporal
Page 201 and 202: 428 B.R. Krogstie in combining them
Page 203 and 204: 430 B.R. Krogstie Fig. 3. A model o
Page 205 and 206: 432 B.R. Krogstie 20. Hutchins, E.:
Page 207 and 208: Research paper P8 Title: Supporting
Page 209 and 210: Supporting Reflection in Software D
Page 211 and 212: 2 Background In this section we bri
Page 213 and 214: There are 3-5 students in the teams
Page 215 and 216: 4 Research Method The research repo
Page 217 and 218: 5 Findings In this section we draw
Page 219 and 220: As a consequence, ‘startup coding
Page 221 and 222:
The type of data involved included
Page 223 and 224:
potentially negative effects is if
Page 225 and 226:
unfolded may shed light on the proc
Page 227 and 228:
5. Lyytinen, K. and D. Robey, Learn
Page 229 and 230:
Appendix B: Other research publicat
show all

The work-reflection-learning cycle - Department of Computer and ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?