by Stan Kurkovsky, email@example.com, @SKurkovsky
Scrum is an agile iterative software development methodology in which a team of software developers works in well defined increments (sprints). Each sprint typically results in adding new features to the software product. LEGO SERIOUS PLAY has been successfully adapted both for team building and as a tool for conducting sprint retrospectives in Scrum software development projects. A retrospective is a meeting of the entire development team facilitated by the Scrum Master and conducted at the end of each sprint, during which the team reflects on the past sprint and answers two key questions: what went well and what can be improved during the next sprint? If applied properly, LEGO SERIOUS PLAY can make sprint retrospectives more productive by getting people to discuss their experiences in the last sprint more openly and communicate their ideas in a more constructive way.
It is relatively easy to make the development team members to communicate with each other since they all work on the same project on the daily basis, and they most likely share a similar background and experience in various aspects of software development. However, ensuring clear communication between the Scrum team and the product owner is not always an easy goal to achieve. A product owner is typically a lead user of the software being developed. The main responsibility of the product owner is to establish a clear vision for the product being built, which is accomplished by writing project specification in the form of prioritized user stories. In practice, a product owner does not always understand the problems the developers may be facing in order to build what the product owner wants. And vice versa, the developers may not always have a clear idea of what the product owner really needs. This situation is perfectly illustrated in this infamous comic.
To address this issue, we have recently held a LEGO SERIOUS PLAY workshop to build a better understanding between the Scrum team and the product owners. The team consisting of four developers is building a content management system and a web-based front end for a student-run weekly newspaper. Two co-editors of the newspaper act as the product owners by providing the vision for the product they want to be built for them. Of the six people participating in the workshop, only one had a prior exposure to LEGO SERIOUS PLAY. The entire workshop was limited to two hours, and the first 40 minutes were dedicated to the traditional introduction to LEGO SERIOUS PLAY. The remainder of the workshop explored the combined team’s perception of how this project should proceed and how each team member could make it better. We started with a challenge where each person identified their strengths in the context of contributing to the newspaper website project. The next challenge asked the participants to build models of the ideal qualities and features of the project as seen by each team member. Both of these challenges resulted in a landscape model of the project features surrounded by the qualities of each team member representing their individual strengths.
Finally, the workshop participants connected their strengths to the project features to see how each individual can contribute to creating a stronger team, which, consequently, could build a better project. The aim of building these connections was to see if there are any features or qualities of the ideal project that are left unconnected (or insufficiently connected) with the individual strengths. In other words, we wanted to make sure that if there is a certain quality of the project that we want to achieve, we should have at least one person who can contribute to that quality. Somewhat surprisingly, no project features were left unconnected, which is an indication that this software development project is off to a good start.
Members of the development team commented that it helped them see the concerns and fears of the journalists and see things from their perspective. One of the developers said:
I found the experience to be enlightening to see into the thought process of the other people involved. This helped me see what they felt was an important part of being part of a group and how they prioritized the qualities involved.
This LSP workshop also helped boost the developers’ confidence:
For me, the best part of the LSP session was when we were creating models of our personal strengths. As my teammates were discussing their strengths, I realized that some of them touched upon what I would consider to be a personal weakness. That boosted my confidence in knowing that if an issue related to one of my own weaknesses came up, we could collectively solve the problem with our combined skill-set.
Most importantly, this experience helped bridge the gap between the different mindsets of the developers and journalists in order to build a stronger team:
We did gain some perspective, especially in how [software developers] see problems and how to solve them. It was also nice to see what strengths they see in themselves and how it makes the whole group stronger when you know who is good at what. It was very illuminating to do that, and to see the final product, of all the individual strengths and group strengths connected together.