The work-reflection-learning cycle - Department of Computer and ...
The work-reflection-learning cycle - Department of Computer and ... The work-reflection-learning cycle - Department of Computer and ...
A Model of Retrospective Reflection in Project Based Learning 421 creating timelines and satisfaction curves [10], but conducted as a two day, video recorded workshop with one team to investigate in depth the use and role of historical data in the reflection process. Examination of the historical data helped team members individually identify project events that had not been included in the timelines made from (individual) memory alone and that were later included in the collaboratively constructed timeline and accounts of lessons learned. Historical data in the issue tracker were also used by the team to adjust details in the shared timeline. Fig. 2. Historical data in a collaborative tool aiding recall of a project event [11] Some features for navigation and retrieval of historical data were found to be important in retrospective reflection [9, 11]. These features included chronological overview and traversal, and the possibility to switch between overview and details. Interviews with the 2007-2008 teams and examination of their reflection notes showed that the collaborative tools used were generally lightweight. The teams were clear about what tools were used for what purpose. While the specific tool selection and usage differ among teams, we see a general pattern: Lightweight project management tools (typically project wikis or issue tracking tools) are used for managing team-internal coordination of tasks, e.g. create and follow up on a project plan, and define, assign and track the status of tasks. The tool provides links to project documentation. Development tools are used to write, test and integrate source code. The storage and versioning of project artifacts are managed in a file versioning system that may or may not be integrated with the project management tool. Email is used for formal and documented communication internally and in communication with other stakeholders. Typically, the project team has its own mailing list. Instant messaging chat is used for informal, team-internal messages and substitute face-to-face conversation over synchronous, distributed work. Less often, it is used for communication with other stakeholders. Internet sites are used to get 176
422 B.R. Krogstie information about technology; in most cases, simple web search or FAQ lists provide answers, but occasionally project members participate in discussion forums [16]. These patterns of use, combined with the functionality of tools, imply that data resulting from various types of project work is generally logged. Wiki revisions are automatically stored and the email clients store all mail unless otherwise specified by the user. It is tacitly expected that an email user keeps an archive of work-related email. With instant messaging, team members frequently choose to enable logging. On an internet forum, postings remain as long as the community hosting the forum wants to keep them. Looking into the historical data stored in these tools, they can be seen as a trace of the work undertaken with the aid of the tools. The studies investigating reflection aided by historical data [9, 11] showed that data in tools used for project management and coordination reminded participants of events related to those aspects of project work and thus helped them reflect on that type of issues. To examine the potential for historical data to shed light on other types of issues, we started out by issues that, according to the teams’ own reflection. had been of great importance in their projects (e.g. misunderstandings in team-customer collaboration, problems of getting timely information from a service provider). Examining historical data in collaborative tools used by those teams, including email archives, instant messaging logs, and discussion forums, we looked for historical data that could shed light on those issues The data found were, as seen by the researcher, rich enough to have such a potential, partially because the data shed light on the use of the collaborative tool itself, which was often at the core of the project challenge. We end this section by outlining some more characteristics of the SD projects relevant to our agenda of understanding and supporting retrospective reflection in the teams. Work in the projects is typically diversified, project participants having different roles, dividing work and using different tools to address different tasks. Team members’ roles affect their day-to-day use of collaborative tools. Consequently, historical data in a tool typically reflects work in which some team members have been more involved than others. Project artifacts (e.g. requirements specifications and project plans) frequently play a role in collaboration with project stakeholders (e.g. customer [17] and course staff) having different goals for their project involvement. Project artifacts in various states can be seen as more or less well defined versions. These may be deliberately saved by the user (as when a text document is renamed and saved) or automatically stored in a tool. A file versioning system stores the contents of and differences between every file version ‘checked in’ by the users. In our studies of retrospective reflection aided by historical data in collaborative tools, going into detail often meant exploring specific artifact versions. 3 Theoretical Background Taking the view of constructivism, seeing learning as integral to activity that is basically social and situated, and focusing on the role of tools, several theories [18, 19] may shed light on project based learning. They include activity theory (AT), actor network theory (ANT), symbolic interactionism, situated learning, and distributed cognition [20, 21]. In [11] it was shown that distributed cognition is an adequate framework for understanding retrospective reflection in SD student projects. It has 177
- 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 and 170: Proceedings of the 42nd Hawaii Inte
- Page 171 and 172: Proceedings of the 42nd Hawaii Inte
- Page 173 and 174: Proceedings of the 42nd Hawaii Inte
- Page 175 and 176: Proceedings of the 42nd Hawaii Inte
- Page 177 and 178: 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: 420 B.R. Krogstie Fig. 1. Shared ti
- 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
A Model <strong>of</strong> Retrospective Reflection in Project Based Learning 421<br />
creating timelines <strong>and</strong> satisfaction curves [10], but conducted as a two day, video<br />
recorded <strong>work</strong>shop with one team to investigate in depth the use <strong>and</strong> role <strong>of</strong> historical<br />
data in the <strong>reflection</strong> process. Examination <strong>of</strong> the historical data helped team members<br />
individually identify project events that had not been included in the timelines made<br />
from (individual) memory alone <strong>and</strong> that were later included in the collaboratively<br />
constructed timeline <strong>and</strong> accounts <strong>of</strong> lessons learned. Historical data in the issue<br />
tracker were also used by the team to adjust details in the shared timeline.<br />
Fig. 2. Historical data in a collaborative tool aiding recall <strong>of</strong> a project event [11]<br />
Some features for navigation <strong>and</strong> retrieval <strong>of</strong> historical data were found to be important<br />
in retrospective <strong>reflection</strong> [9, 11]. <strong>The</strong>se features included chronological<br />
overview <strong>and</strong> traversal, <strong>and</strong> the possibility to switch between overview <strong>and</strong> details.<br />
Interviews with the 2007-2008 teams <strong>and</strong> examination <strong>of</strong> their <strong>reflection</strong> notes<br />
showed that the collaborative tools used were generally lightweight. <strong>The</strong> teams were<br />
clear about what tools were used for what purpose. While the specific tool selection<br />
<strong>and</strong> usage differ among teams, we see a general pattern:<br />
Lightweight project management tools (typically project wikis or issue tracking<br />
tools) are used for managing team-internal coordination <strong>of</strong> tasks, e.g. create <strong>and</strong> follow<br />
up on a project plan, <strong>and</strong> define, assign <strong>and</strong> track the status <strong>of</strong> tasks. <strong>The</strong> tool<br />
provides links to project documentation. Development tools are used to write, test <strong>and</strong><br />
integrate source code. <strong>The</strong> storage <strong>and</strong> versioning <strong>of</strong> project artifacts are managed in a<br />
file versioning system that may or may not be integrated with the project management<br />
tool. Email is used for formal <strong>and</strong> documented communication internally <strong>and</strong> in<br />
communication with other stakeholders. Typically, the project team has its own mailing<br />
list. Instant messaging chat is used for informal, team-internal messages <strong>and</strong> substitute<br />
face-to-face conversation over synchronous, distributed <strong>work</strong>. Less <strong>of</strong>ten, it is<br />
used for communication with other stakeholders. Internet sites are used to get<br />
176
Change language