How to make the magic happen
What is actually a good project? Good results? Good money earned? Positive feedback from your client? Kept within budget? A motivated team at hand? Integrated findings from user testing? Mastered workload-peaks? Translated the project’s vision? Created something “new” and even learned something? It can’t be put into words, it was somehow magical, but maybe it has got something to do with magic. But what does that mean? The project has to be taken by an invisible hand and integrated into a network of happenings, situations, people, various needs and a budget? It just happens?
Experience shows: magic does not happen when people feel not listened to, excluded from the project or left alone. In German we say: “To simmer in your own soup.” So there’s no magic happening, when team-members (and clients) are not aware of their role’s importance in a project. Physical and mental presence of everyone involved in the project are essential components of a project’s magic. This allows goal-orientated communication and collaboration. Visions can be turned into reality. Magic can happen. And how can you provide the basis for such a mindset? With retrospectives for example .
Retrospective generally means to take a look back at events that have already taken place. A retrospective is a meeting of all team-members (customer included) reflecting on a specific project phase or the project itself. But this reflection does not happen in a classic round table “let’s discuss it and now i share my point of view” kind of way. Retrospectives happen in a structured way, where you gather and evaluate valid data about the project by using certain techniques: This is translated into specific action points, which are divided among the team members.
The project gets reflected collectively by all team members. The team jointly gets to know the project, acts and sets actions to adapt methods and teamwork. No theory there, real insights. A team that has both capability and ability to make decisions and deliver results.
Prime directive of a retrospective
To be “successful” as outlined above, the retrospective has to feel “safe” for everybody involved. All participants have to feel comfortable within the group to inspect the work that has been done and to accept that there may exist various ways to improve collaboration.
Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given
what was known at the time
his or her skills and abilities
the resources available
and the situation at hand.
To uphold this feeling of safety throughout the whole retrospective is crucial for its success. It also guarantees an active and positive participation of everyone involved. A single voice could not tell the whole story of a project. The learning curve would be quite shallow. Many voices reflecting on the project are able to provide a wider range of insights. But a retrospective is not only there to find mistakes made in the process. A lot of quality would be lost like that. It is as much about collecting the things, that made a project successful. A retrospective is about reflecting all aspects of a project:
- What has happened?
- What was effective?
- How do we want to continue our work?
The more often a retrospective takes place, the more it becomes a part of the team’s culture. An increased frequency in retrospectives improves the efficiency and implicitness of the actions taken to adapt a project. It also allows the team to focus on shorter periods of time in order to make the right decisions within every project phase. Reflect and adapt continuously.
dmcgroup and retrospectives
dmcgroup came in touch with agile working methods and retrospectives a couple of years ago. This particular period of time, the great work results, the experiences and epiphanies have influenced the working methods and had a big impact on the understanding of iterative processes within a project. Today retrospectives are held to improve teamwork and collaboration within the agency itself, as well as during a project together with the client. Retrospectives are a great tool to gather the team and to share thoughts and doubts, joys and insights by everyone involved in the project – regardless of whether it’s an agile or a “classic” waterfall project.
Retrospectives have emancipated themselves from agile software development. An agile workflow that divides the project into different sprints and is based on the principal of continuous delivery, supports the integration of retrospectives in a project. A retrospective can be held after every sprint. Specific results of the retrospectives can be integrated seamlessly into the project. Thus teamwork and collaboration, working methods and workflows can be optimized directly and have an immediate positive effect on the project results. Retrospectives that held on a regular basis focus on “real” problems and the team is able to discover ways to overcome their obstacles. That way solutions are not dictated using a top-down approach, but much rather the team agrees on how to take action democratically. Every participant is engaged and investing into the collective success. This in turn enables the team to:
- Improve efficiency
- Recognize capacities
- Utilize existing potentials
- Increase the quality of the results
Retrospectives are not this magic bullet that guarentees excellent project results. But it is a great way to start reflecting on working methods, breaking old habits and trying out new techniques. It allows the client to be integrated into a transparent communication process. Every team member learns about the importance of his or her role in the team and feels encouraged to improve continuously. Here at dmcgroup, this is an essential ingredient of project magic. What is project magic to you and what actions do you take to make that magic happen? Share your thoughts with us.
Norman L. Kerth: Project Retrospectives. A handbook for teamreviews. Dorset House Publishing, 3143 Broadway, Suite 2B, New York. New York 2001. Esther Derby, Diana Larsen: Agile Retrospectives. Making good teams great. The pragmatic programmers. 2006. Agile Retrospective Resource Wiki
– – – – – – – – – –
Karin Cepin is working as a visual designer at dmcgroup. She is a passionate long distance runner and embraces change.