Hi Thomas, nice reading. I have a question and two comments. First the question. I often find it hard to generalise anything but the obvious when doing a project evaluation, and even more in teams, because it often comes down to roles and individual learnings. So, when you sum it up in your wiki or talk about what is outside your control, how do involve these experiences in the next project? Do you use cases as reference or do you all revisit the wiki together (as part of meetings)?
Now my comments:
I often find that it does require to change the method, as a new approach, game or meeting-form, When you do something new it tends to get people more involved, and subsequently activate the reflection on the project. This ‘shaking things up’ is maybe more a meta-method, but it tend to work if the meetings become to stale and repetitive. The downside is to be able to ‘compare’ learnings across methods (can team-members understand the different screenshots in the wiki etc.).
From my work studying creative process and trying to interview people on creative leaps, I have found methods similar to Moodgraph a good conversation starter. I conducted individual interviews with team members (groups of students), where they first drew a timeline over the project, plotted in the significant events (insights, sprints, design changes etc.) and then drew the fever-curve (Moodgraph) on top of it. I did not find anything surprising, but later the students have told, that the interviews was a valuable tool for individual reflection… But I still haven’t found a good way to make the insights explicit and carried over into projects (besides the obvious e.g. keeping deadline) – and I can see from the students work, that they too struggle with carrying the previous experiences into new projects. That always seem to be the hard part, especially in teams. Any suggestions?
Thanks. Well, some people would build a huge checklist of things to remember “the next time”, but the thing is that every project is special and the rough parts are always something new. I don’t really believe in this. I take it as a collective learning experience. I do know that the next time, something similar comes up, I’, going to take the drag factors a lot more serious, we have a few technical adjustments and we are currently working on getting a lot more behaviour driven…
Hi Thomas, nice reading. I have a question and two comments. First the question. I often find it hard to generalise anything but the obvious when doing a project evaluation, and even more in teams, because it often comes down to roles and individual learnings. So, when you sum it up in your wiki or talk about what is outside your control, how do involve these experiences in the next project? Do you use cases as reference or do you all revisit the wiki together (as part of meetings)?
Now my comments:
I often find that it does require to change the method, as a new approach, game or meeting-form, When you do something new it tends to get people more involved, and subsequently activate the reflection on the project. This ‘shaking things up’ is maybe more a meta-method, but it tend to work if the meetings become to stale and repetitive. The downside is to be able to ‘compare’ learnings across methods (can team-members understand the different screenshots in the wiki etc.).
From my work studying creative process and trying to interview people on creative leaps, I have found methods similar to Moodgraph a good conversation starter. I conducted individual interviews with team members (groups of students), where they first drew a timeline over the project, plotted in the significant events (insights, sprints, design changes etc.) and then drew the fever-curve (Moodgraph) on top of it. I did not find anything surprising, but later the students have told, that the interviews was a valuable tool for individual reflection… But I still haven’t found a good way to make the insights explicit and carried over into projects (besides the obvious e.g. keeping deadline) – and I can see from the students work, that they too struggle with carrying the previous experiences into new projects. That always seem to be the hard part, especially in teams. Any suggestions?
Hi Henrik,
Thanks. Well, some people would build a huge checklist of things to remember “the next time”, but the thing is that every project is special and the rough parts are always something new. I don’t really believe in this. I take it as a collective learning experience. I do know that the next time, something similar comes up, I’, going to take the drag factors a lot more serious, we have a few technical adjustments and we are currently working on getting a lot more behaviour driven…