LEAP Serious Games for building experience on agile design processes

The LEAP learning game has been developed in the form of 3 learning applications that promote the development of agile and lean skills. The following games have been created:

The Technical Debt game

The game exposes learners to the concept of “Technical Debt”, namely the fact that an implementation team must invest early on a good implementation plan. If not, it risks rising future implementation costs as a result of choosing an “easy” and insufficient implementation.

The application is a simulator of “sprints”, namely work cycles in the context of agile processes. The player is encouraged to invest (or not) in the implementation of a project before each sprint cycle. The simulator demonstrates at the completion of 10 sprints the technical debt amassed as a result of the investment choices.

The lower the debt, the better the player has performed.

Download the Technical Debt game for Android devices v1.2

Get the Technical Debt game reference manual v4 EN GR ES PT EE

Get the Technical Debt Game Unity source code (C#) under CC-BY license

The 5S Lean Processes game

The second application refers to the “5S” implementation model that is often applied in lean processes. The model refers to the actions sort, set in order, shine, standardize, and sustain. A basic functionality is developed, which has the main features of gameplay. The application is developed both in 2D and 3D (3 dimensions). The player is challenged to deploy the 5S methodology in order to improve the work space and thus reduce implementation time. The player is asked to move a character on the game canvas by clicking on the ground. The player can interact with other characters and objects of the game by clicking on them. The basic gameplay is as follows: the player moves around on the screen in order to fulfill a task. By applying each of the 5S principles, naming sorting, ordering, shining/cleaning, and standardizing, the player will improve significantly the work flow. Three learning scenarios are developed following this idea. It can be declined in a various number of manners to demonstrate lean design and more specifically 5S. The scenarios address the needs of different industries. They include: ordering a pharmacy inventory (medical engineering), ordering a scrapyard (manufacturing), and ordering a desktop space on a computer (ICT and wider sectors). These diverse scenarios demonstrate the fact that lean production can be applied in diverse engineering and wider sectors, thus going beyond the traditional software engineering and manufacturing applications of the process.

Download the 5S Game (Windows) v1.2f

Download the 5S Game (Mac OSX) v1.2f

Download the 5S Game (Linux) v1.2f

Download the 5S Game (Web) v1.2f

Get the 5S Game reference manual v4 EN GR ES PT EE

Get the 5S Game Unity source code (C#) under CC-BY license

The SCRUM Agile Processes simulator game

This demonstrator refers “SCRUM” model that is deployed in the context of agile design. The SCRUM model is applicable in small teams that work in small to medium sized projects. Team members have roles. For example, the SCRUM master is the overall coordinator. he product owner is the person that decides whether the outcome of implementation actually meets needs; typically this person is the customer. Team members work with the SCRUM master to implement a project. What is different about SCRUM is that design and implementation of a project are interleaved and not separated as in more traditional project implementation approaches. At the beginning of a project implementation team members in collaboration with the customer brainstorm to identify the features that the final product must have. Each feature is documented in a small note typically on a board. The team members in collaboration with the customer then decide which features will be implemented in the first iteration of development, which in the second, which in the third, and so on. Once the features to be implemented in an iteration are agreed upon, the team members go into a “sprint” of implementation, which is intense. Typically, during this time team members do not interact with external individuals. Rather, they interact only with the SCRUM master, who acts as a buffer protecting the team from distractions. At the end of a sprint all team members, the SCRUM master, and the product owner have a meeting. This meeting is called a “SCRUM”, giving its name to the overall process. During the SCRUM participants decide whether the result is the desired one. They further identify the features that will be implemented in the next sprint. The product owner, i.e. the customer, may “accept” or “reject” the result. Rejection is not uncommon. If a release is rejected a new prototype is built in the following sprint.
The related application will be a single player game that will recreate the development of a product using the SCRUM methodology described above. The player will be able to assume any of the traditional SCRUM roles, namely SCRUM master, product owner, or team member. The following scenarios are planned, which demonstrate that the SCRUM methodology can be applied beyond its traditional use in software engineering: designing a university campus (civil engineer), designing a garden (agricultural engineering).