Annemike Salonen

 

Overview
A standardized sequential method of project man­agement approach had been successfully established in a company for several years. Increasingly, how­ever, as a result of the challenges posed by the VUCA world, issues arose in projects that could not be solved efficiently and in a customer-focused manner using this classic approach.
The client’s assignment for the training workshop was therefore: “Communicate the essentials of Agile project management methods in such a way that our project team members are able to integrate them into the previously established classic project management approach.”

 

Topic
The aim, therefore, was for the employees to flex­ibly and smartly combine Agile and tradition­al methods in day-to-day project man­agement so that hybrid project management could be implemented. To achieve this, we used SysTeam as part of a one-day in-person training workshop. The goal of the interaction “Agile not Fragile” was to allow participants to experience the principles of Agile collaboration in projects. In particular, the participants were to experience the iterative approach of Agile methods in order to be able to realize how it fundamentally differs from the conventional sequential approach and to evaluate the practical possibilities of using this approach.

 

Staging
a. Preparation
The 30-minute interaction was conducted halfway through the training workshop after the lunch break. The basics of Agile project management had already been taught, i.e., the underlying values, principles, techniques, and methods (especially Scrum) were already known in theory.
• The interaction was prepared for three teams “Red,” “Green,” and “Blue.”
• The ideal team size was three (to four) people per team, with the option of appointing observers.
• Three (four) figurines of different sizes were grouped together for each team and color-coded with a sticky dot.
• To increase the complexity of the task, a “restricted zone” was established in the middle of the table – using a piece of round cardboard – which the figurines were not allowed to enter.
After being set up, the board was in complete balance. It was not immediately obvious to the players that the plate was not fixed in place.

 

b. Performance
I presented the task and the rules on a flip chart, which was also clearly visible to the participants during the entire interaction.
I explained: “Welcome back, dear project team. I am your client for the next 30 minutes. The assign­ment I have for you is to create two isoscel­es triangles on the plate within 15 minutes, each sharing one side. I already have a very precise idea of what the final result should look like (I pointed to the sketch at the top right of the flip chart). You see, all three colors must appear in each triangle and the distance between the figurines must be at least seven and a half inches. No figurines are allowed in the forbidden zone at the end or during the project. And, as with every project, there are conditions that must be met: for example, the team is only allow­ed to touch the figurines one after the other, in a clockwise direction. It is not allowed to touch the plate at all. If the plate falls over, you start all over again with the initial figurine set-up. You will work together in three sub-project groups: Red, Green, Blue. Please split up into even groups and go ahead and stand behind the grouped figurines. The project will start as soon as you take your positions. Good luck!”
While they tackled the task, I adopted the role of observer. The question about the distribution of ­roles within the teams often came up: “Do we all have to have moved a piece at some point?” The answer was: “The rules of the game don’t say that.” This was because, in keeping with the Agile approa­ch, team members (apart from clearly defined roles such as “Scrum Master” or “Product Owner”) chose their own tasks/roles in the project. For all other questions, I pointed to the flip chart. Anything that it did not exclude was allowed.
Often, the participants only realized how unstable the board was – and boy, was it! – when they lift­ed the first figurine. The previous classically planned approach was then quickly thrown overboard: “Let’s just have a go now. And then decide the next move step by step …” This was where the basic principle of the iterative approach was intuitively applied!

 

c. Finish
The learning project was completed when they had achieved the goal or the specified project time had expired.

 

Tranfer to the real World

Elements in the learning project	Elements in the real world
Due to the uncertainty of how the plate will react, it quickly becomes clear that it makes no sense to plan in detail in advance. What does work is to adapt the next step to the interim result previously achieved and to build on it.	This is also the case for projects with a high novelty factor or very uncertain underlying conditions: in this case, time-consuming, detailed advance planning – as envisaged in classic project management approaches – is pointless. Instead, when using an iterative approach (“sprints” in Scrum), you move step by step closer to the optimum.
It is important to ensure that everyone has a clear, shared understanding of the goal. If it is not clear to everyone which (intermediate) result is being work­ed toward, this approach will result in chaos!	This is also the case in Agile project management: before each sprint, the desired end result is discuss­ed (sprint goal). The purpose of the backlog items is to substantiate the sprint goal.
The task could only be completed successfully when all sub-teams collaborated with each other and constantly shared information with each other. The physical proximity of the three sub-teams was also crucial to achieving successful collaboration. It created transparency and allowed for rapid feedback and response.	This made it clear to the participants why, for example, Scrum requires daily stand-up meetings, whereas in traditional project management weekly or even monthly meetings are often considered sufficient. Ideally, in Agile approaches, the team sits together physically. If this is not possible, the daily stand-ups are conducted virtually, with the webcam always activated.
During the activity, situations often arose where a figurine that was previously planned to be placed in one of the triangles no longer seemed right, because it was too heavy/light and would cause the plate to tip over. This created new options that the team needed to recognize and be open to.	This enabled them to internalize the Agile principle of “responding to change over following a plan.” That is, changes are seen as an integral part of the project and as an opportunity – not as a “disrup­tive factor”!
Many groups realize that a classic project manager is not needed for this approach. The best result is achieved through dialog on the basis of equality, respect, and trust. However, there is a need for people who ensure that the rules are observed.	This is precisely how the roles in Scrum are understood. Scrum is hierarchy-free. There are three defined roles; the Scrum Master ensures compliance with the Scrum rules. The Product Owner focuses on the communication with stakeholders, customers, management, and the Development Team, and sets the goals. The Development Team organizes itself.
The key to this approach is transparency and contin­uous reflection: Where are we in the project? What experiences have we gained so far? What has gone well, what has not worked?	Scrum ensures this through regular retrospectives at the end of each sprint!
Sometimes it takes courage from the person doing the grabbing to lift the figurine, even if the plate is perilously close to toppling. Then all the other team members have to stand behind this person.	According to the two creators of Scrum, courage is one of the five values that the Scrum team should possess. The same applies to commitment.

 

Reflection
Experience shows that it is very easy to establish the link between the staging and real life. Questions prepared on a flip chart are used to support the reflection:
• What factors helped you work together to successfully complete the task?
• What role does “agility” play in completing the task?
• What can we take from the activity to our daily business life?

 

Conclusion
This interaction resulted in real “Aha!” experiences for many participants. One participant said: “Now I have finally truly understood the idea behind the iterative approach!” In particular, participants who were previously skeptical about Agile approaches recognized their benefits and role in real-life projects. This interaction is not only suitable for teaching hybrid project management approaches, but also paves the way for greater understanding and acceptance of pure Agile project management methods such as Scrum.