Improving Software Projects Inception Phase Using Games

ActiveAction Workshop

Miguel Ehécatl Morales-Trujillo

, Hanna Oktaba

and Juan Carlos González

Graduate Science and Engineering Computing, National Autonomous University of Mexico, Mexico City, Mexico

ENTIA, Av. López Mateos 2077 Int. Z-16, Col. Jardines de Plaza del Sol, Guadalajara, Mexico

Keywords: Games, Inception Phase, Requirements Specification, Stakeholders’ Involvement, Software Project,

Workshop.

Abstract: Studies have demonstrated that an important factor to increase the success rate of software projects is the

involvement of key stakeholders at the right time, in order to define business objectives, scope of the project

and requirements. The Inception phase of projects is in charge to provide these outcomes and is suitable to

really involve stakeholders as team members because of the non-technical nature of the activities. However,

since the stakeholders' involvement is a time- and money-consuming activity, it is important to maximize its

efficiency. With that in mind, ludic aspect inherent to games can be used as a strategy to optimize the

Inception phase. This paper presents ActiveAction, a game-based workshop used as an alternative for the

software project’s Inception phase in order to increase its effectiveness and improve the stakeholders’

involvement in the project. ActiveAction combines classical and game-based techniques which permit a

deep involvement of stakeholders and a collaborative identification of objectives, constraints and risks

during an intensive workshop oriented to project conceptualization. ActiveAction workshop resulted in a

successful game-based strategy that has improved the Inception phase of 19 projects with different

customers. After-workshop surveys, projects outcomes and customer satisfaction indicate validity of the

method. ActiveAction is a valuable game-based alternative to carry out the Inception phase in a software

project. It makes possible to get an important amount of information, directly from key stakeholders in a

short period of time increasing the success rate of projects.

1 INTRODUCTION

A game could be defined informally as an

amusement activity with rules, undertaken for

entertainment but still pursuing a goal. A game can

be seen as an activity in which a player must learn

new skills and apply them to overcome challenges,

getting rewards or punishments, depending on their

success or failure, respectively. The application of

games in education, government or military areas

has become an important and feasible alternative to

face challenges. Since the entertainment is not the

main purpose of these games, they are labeled as

serious games.

A serious game is a game that does not have

entertainment, enjoyment or fun as their primary

purpose (Michael and Chen, 2005). Even thought,

according to (Abt, 1970) games may be played

seriously or casually, but it does not mean that

serious games are not, or should not be, entertaining.

The ludic and playful aspects inherent to games,

serious or not, can be used as a strategy to address

different kind of challenges and sorting obstacles.

Enclosing to Software Engineering, it can be

asserted that developing software and systems is a

challenging activity. In 2010, Standish Group,

through CHAOS Report (Chaos Summary, 2010),

revealed that only 32% of software projects were

successfull, 44% challenged and 24% were

cancelled. Comparing these data with that of other

industries, Construction for example, 94 percent of

the customers were satisfied with the results of their

projects, which suggests that construction projects

have much lower failure rates than software projects

(Stepanek, 2005).

But, why is developing software different to

producing any other product? Why is it so difficult

to develop good products in a consistent way from

their inception phase and on?

The purpose of the Inception phase of a software

projects is establish the business case for the system

180

Morales-Trujillo M., Oktaba H. and González J..

Improving Software Projects Inception Phase Using Games - ActiveAction Workshop.

DOI: 10.5220/0004891801800187

In Proceedings of the 9th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2014), pages 180-187

ISBN: 978-989-758-030-7

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

and delimit the project scope (Kruchten, 2003). The

stakeholders' involvement in this phase is inherent

and fundamental.

However, including stakeholders as part of the

team, but in the real sense, requires time and money.

With that in mind this paper presents ActiveAction,

a workshop used as an alternative into the software

project’s Inception phase. ActiveAction combines

classical with game-based techniques to improve

stakeholders’ involvement in the Inception phase of

a project and increase its effectiveness.

The paper is organized as follows: Section 2

presents main success factors in IT projects, while

Section 3 expands on the strategies to conceptualize

projects using traditional, agile and game-based

techniques. Section 4 then goes on to introduce and

analyze the ActiveAction workshop, while Section 5

presents results of the usage of this method, its

advantages and disadvantages. Conclusions and

future work are provided in Section 6.

2 SUCCESS FACTORS IN

SOFTWARE PROJECTS

Are software projects different to other projects?

According to (Stepanek, 2005) the main difference

relies on the characteristics of software and

technology. On one hand, software is abstract and

complex while the requirements to be developed are

incomplete. On the other hand, the vast domain of

technology changes rapidly, causing lack of

technical experience and immaturity of best

practices.

According to Gartner (Gartner survey, 2012) the

most common “anti-success” project factors are:

poor quality, cancelling after launch, high cost

variance, substantially late delivery and functionality

issues. Determining if a project is successfull or not

could be hard, the success can be determined by a

combination of factors like scope, time or cost, but

another one could be ROI, quality or the healthiness

of the workplace (Ambler, 2007).

However, failure aspects related to technical

issues are not a critical factor (Ibrahim et al., 2013).

It means that improving technical aspects of projects

will not always lead to higher ratios of success.

Building robust business-oriented requirements

can be half of the solution; according to (Bloch et

al., 2012) one group of success factor is to manage

strategy and stakeholders. Taking it into account, a

first approach is to focus on the very beginning of

the project, and increase the stakeholders'

involvement in order to improve business modeling

and specification of requirements.

Nevertheless, the stakeholders' involvement

implies investing time, money, experience and

patience from both parties: software developer

organization and stakeholders.

We believe that inclusion of games is a

beneficial strategy to conceptualize a project

together with the stakeholders and increase the

success rate of projects.

3 SOFTWARE PROJECTS

INCEPTION PHASE

Conceptualization begins at the early steps of

projects, in the words of RUP (Kruchten, 2003), it

occurs during the Inception phase. At the Inception

phase the bussiness process is documented in order

to assure a common understanding among all

stakeholders, the system is described determining

the required functionalities, objectives, risks and

constraints, to deliver, successfully, a product which

meets the stakeholders’ needs.

The reality of an ordinary Inception phase is to

deal with plenty of meetings with different

stakeholders, final users and management staff

getting a broad idea of their sometimes contradictory

needs. Business analysts start to mediate inconsistent

requests and the work that was intended to take a

couple of weeks becomes longer.

A feasible solution, applied during Inception

phase, could be to elicit, envision, design and

prioritize the business needs until a minimal viable

product is clearly seen by key stakeholders involved

in the project, collaborating with the development

team.

In light of this, three approaches to manage

activities during the Inception phase are presented in

the next subsections.

3.1 Agile Approach

Small releases and stakeholders', users' and

customers' involvement in day-to-day activities are

part of the philosophy of agile practices to face the

requirements elicitation and prioritizing.

According to agile practices, conceptualization

and development of a project occurs almost at the

same time. It is achieved thanks to the Product

Owner (PO), a role in charge of having a vision of

what to build: they create and prioritize a list of

desired features, the Product Backlog. PO must have

a solid understanding of users, market place,

ImprovingSoftwareProjectsInceptionPhaseUsingGames-ActiveActionWorkshop

181

competition and future trends for the domain or type

of system being developed. Also the PO requires

working closely with key stakeholders (Mountain

Goat, 2013).

An important complication of agile approach is

that the PO could be more than one person, and most

important, not all of them are ready or available to

be involved in a day-to-day dynamic.

3.2 Traditional Approach

The traditional approach is a process-centered way

of working. First, adequate stakeholders are

identified. Later, fixed interviews with clients and

stakeholders are held in order to identify their needs.

The input of this process is obtained from meetings,

focus groups, questionnaires or user observations.

The information is transformed by the development

team until a business model or requirements

specification is created and agreed upon with

stakeholders. This approach is expensive and

demands an arduous effort from both parties.

3.3 Game-based Approach

In fields of industry, such as marketing and sales,

games are used to help to understand customers,

market, business opportunities and to improve

everyday employee-related issues within an

organization (Gamestorming, 2013). The application

of these games has a broad spectrum: some

examples taken from (Innovation Games, 2013)

define their variety. For instance, Empathy Map's

objective is to gain insight and understanding for a

targeted public image; How-Now-Wow Matrix

pursuits the goal of selecting the best ideas as a

group; Job or Joy aims at improving working

environment of the organization; lastly, there are

classical techniques, such as SWOT analysis and

Pros/Cons adapted as games.

On the other hand, the application of such games

tends to be isolated strategies in order to accomplish

specific goals that may not be related to Software

Engineering. Besides, they are not organized as a

interrelated set of activities that reuses the result of a

previous activity as an input for the next, thus

making difficult to compose a method to attack more

complex problems.

Few reports of games that support approaches to

perform Software Engineering activities with

objectives not related to education nor training can

be found. One of those games is Software Quantum

Metaphor, a game that makes an allusion to the

chemical units known as quantum. The requirements

of the software project are visualized as a bag of

balls. Each ball visualizes one requirement or

quantum. There are balls of different colors, each

color representing a different state of analysis of the

requirements (Knauss et al., 2008).

Another game is the Labor Game Method,

described in (Torvinen, 1999). In this game the

requirements are presented through cards on a board.

Each card can be changed, or some cards can be

added or removed from the board. This game

permits to visualize all the requirements of the

project, their structure and priorities.

Taking into account the uncommonness of games

in Software Engineering development process and

the lack of a method that puts together games in

order to accomplish complex goals, the next section

presents a method that combines a set of classical

techniques with games, and is intended to improve

the Inception phase of software projects.

4 ActiveAction WORKSHOP

Entia (Entia, 2013) is a Mexican IT organization

established in 2003 as a software developer

organization conformed at the beginning by 4

employees, now 20. Entia has executed projects to

construct custom software related to finance, retail,

manufacturing and service sectors. They can be

classified into "process systematization" and

"business venture". The former consists in

developing a software system that automates a

specific process in the stakeholder's organization.

The latter is aiming at adding a new service or

product that will be offered to the stakeholder's

clients.

In order to increase the projects' success rate and,

consequently, the number of projects, Entia

developed Innocamp strategy. Innocamp consisted

in an intense workshop where all stakeholders

collaboratively design their new custom software

development project. This envisioning strategy was

created in order to avoid continual coming and going

between customers and Entia work team, caused by

the lack of definition, clarity and consensus in their

needs.

The Innocamp workshop let the organization

achieve such benefits as: bringing all of the

stakeholders to the organization at the same time and

place; stakeholders and work team invested quality

time during the workshop; complexity and size of a

project was better understood by the stakeholders;

and, both parties developed a synergy and emotional

attachment to the project.

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

182

Since 2007 Innocamp has evolved into

ActiveAction workshop. The evolution started with

the inclusion of games as a way of entertaining the

stakeholders during the workshop. Over the time the

work team noticed that games helped to decrease

resistance and increase concentration level of the

stakeholders, causing an important impact on the

results of each workshop.

ActiveAction is a game-based workshop focused

on the software project conceptualization. It consists

of the following activities:

 Pre-Day: It enables Entia to figure out

stakeholders' real motivations that made the new

project feasible. It includes negotiations between

the customer and the organization, calendar

planning for the rest -Days and collecting

relevant customer information. The organization

chooses adequate participants to take part in the

following -Days.

 Intensive-Day: It is the actual method that

gathers stakeholders and consultants during 8-12

hours in the same place. 5 roles are required for

the consultant team: Coach, Analyst, Process

Engineer, Logistics and Customer Service and

Support. The purpose of the Intensive-Day is to

extract expectations, objectives, needs, risks, and

functional and non-functional requirements from

stakeholders using a collaborative and game-

based strategy.

 Post-Day: The information gathered during Pre-

and Intensive-Day is structured in order to create

an IT strategy to deal with the project.

 Action-Day: on this -Day a meeting takes place

in which the context, technological strategy and

supplier proposals are discussed with the

stakeholders in order to define the path that a

project will take.

For the purposes of this paper, the Intensive-Day is

presented in detail in the next subsection.

4.1 Intensive-Day Method

To carry out the Intensive-Day practices the

following requirements and material are supplied: a

room with 4.5 square meters per participant;

speakers, a whiteboard, a glass wall or canvas, a

projector, a TV, a special table for personal

belongings and toys, such as little balls and office

supplies like post-its, tacks, pencils and markers.

Additionally each consultant needs a computer,

Internet connection, source of electrical power and

connection to the projector. All participants are

seated in circle.

Intensive-Day method is composed by 19

practices that can be classified in two groups:

 Core practices produce meaningful outcomes for

the Inception phase of the project and have a

defined order.

 Auxiliary practices are focused on keeping

order, reducing stress and maintaining high

entertainment level. They have no special order

to follow.

Figure 1 presents the Intensive-Day method where

the game-based practices are marked with a "balero"

icon, which is a traditional Mexican toy. The core

practices are colored in light green, while the

auxiliary are dark green. Flows between practices

indicate the order of their execution.

The Intensive-Day method was expressed as a

composition of practices using KUALI-BEH

approach (Morales & Oktaba, 2012). This approach

establishes that a practice provides a systematic and

repeatable way of work focused on the achievement

of an objective. Each practice pursues the objective

of producing a result that originates from an input.

Using these three elements, objective, input and

result, the Intensive-Day game-based practices are

described below.

4.2 Game-based Practices

This section presents 10 game-involving practices.

4.2.1 Cover Story and Product Box (Core)

The objective of the practice called Cover Story and

Product Box (Hohmann, 2006) is to identify and

express the stakeholders' objectives. An interesting

fact is that the identified objectives should be

expressed as if they had already been achieved.

The practice of Cover Story is suitable when the

stakeholders' objectives belong to the area of

improving their companies' image, functioning or

prestige. The practice of Product Box is more

appropriate if the stakeholders' objective is to own

and sell a particular product.

In the former the stakeholders have to design a

cover story for a magazine that would be published

in the future and would narrate their success story;

while in the latter they design a box that would

contain the final product.

The input of these practices is objectives

provided by the stakeholders, while the results are

the cover story or the product box with

comprehensive objectives.

ImprovingSoftwareProjectsInceptionPhaseUsingGames-ActiveActionWorkshop

183

4.2.2 Persons (Core)

The objective of Persons is to identify priorities of

cost, time and scope and their control strategy.

Three persons from the stakeholders’ team

portray each one of those variables, highlighting the

pros and cons in order to clarify the importance of

reducing or increasing their values. The stakeholders

listen and watch the game and have to make a

decision at the end, putting the three variables in a

priority order.

The input of the practice is an example of a

variable control matrix while the result is a matrix

with the agreed values of cost, time and scope.

4.2.3 Role Play (Core)

The Role Play objective is to simulate the

organization's everyday process. The simulation

consists in role-playing performed by stakeholders.

The role-play scenario is based on a frequent, but

complex episode from everyday business-oriented

activities in the stakeholders' organization. It also

should have exceptions or miscommunication issues

and needs to be rebuilt from a happy path.

The input of this practice is the actual process of

the organization used as a role play script. The

results are: a matrix of involved roles and a

successful criteria list of an everyday process. It also

provides contextual information of the stakeholders'

organization.

4.2.4 Metaphor (Core)

The Metaphor practice is based on the well-known

game Lego Serious Play, developed by LEGO

(LEGO, 2010). It is a structured process, where

participants use LEGO bricks to create models that

express their thoughts, reflections and ideas (Cantoni

et al., 2011). Here the prime objective is to obtain

product expectations from every member of the

stakeholders' organization.

The input is the matrix of involved roles and a

metaphor to motivate generation of ideas that will be

expressed as a LEGO figure. Each person of the

stakeholders team builds a figure, explains its

meaning and all of them are put together to interpret

their relationships and interactions working as one

team.

The results are: an interpretation of each LEGO

figure and a better understanding of relationships

among the roles in the matrix and within the process

through the set of LEGO figures.

4.2.5 Speedboat (Core)

The game practice of Speedboat is adapted from the

game designed by Luke Hohmann (Hohmann, 2006)

and its objective is to identify the project's potential

risks by and for the whole stakeholders’ team.

A speed boat is drawn on the top part of a

whiteboard while the participants write any risks that

can affect the project on post-its. Then they place

them on the white board as if they were anchors. The

lower a post-it is placed, the heavier the anchor is,

which means a high risk that will impact the project

the most. After all the "anchors" are set, a moderator

groups similar ones together and the participants

discuss the identified risk factors. The probability of

occurrence is determined by the number of repeated

risks and the impact by the lowest position.

The input of this practice is post-its used by each

person, while the result is the list of identified risks

associated with their probability of occurrence and

impact.

4.2.6 AVAX Storming (Core)

Based on the popular brainstorming technique

(Osborn, 1993), the practice of AVAX Storming is

focused on finding the desired functional

requirements for the system. All the participants

write a one functional requirement on a piece of

paper named Added Value Actionable Items

(AVAX). Later AVAXes are grouped in order to

sketch the system future modules.

This practice helps users to figure out the size of

their project because soon the walls start to be filled

up and the size of the project starts to grow. It is a

visual way to show users that each need has its

complexity and weight. If the project has a limited

budget, each AVAX has a section where each person

chooses if the requirement is "Needed" or "Desired".

When all AVAX are posted on the wall, each person

explains in detail their AVAX to the rest of the team

opening it to discussion.

The result of the practice is a mind map of the

identified AVAXes.

4.2.7 Buy a Feature (Core)

The objective of the practice called Buy a Feature is

to determine the scope of what will be built by the

end of a single iteration. Buying a feature with a

fixed budget is oriented to identify the top-rated

requirements. The stakeholders’ team has to buy the

most necessary requirements and define the

Minimum Viable Product (MVP).

The input of the practice is the list of required

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

184

functionalities or AVAX, each with a price tag and

fake bills for each stakeholder.

The result is the MVP or a list of AVAXes

bought by the stakeholders’ team. The MVP is also

helpful to validate the project's feasibility.

4.2.8 Gunfight (Auxiliary)

During ActiveAction there are "rules" to be

followed, such as not to use smart phones or not to

leave the room except during breaks. If anybody

disobeys the rule, the rest of the participants can

shoot at them with NERF guns until the "order" is

restored, which is actually the objective of the

practice.

4.2.9 Time Police (Auxiliary)

The stakeholders' team chooses a person who will

play the Time police role. He or she has a vuvuzela

(horn) that is blown when somebody is talking about

a closed topic or is digressing. The objective of the

practice is to maintain discussions focused and to

watch the time.

4.2.10 Circle of Trust (Auxiliary)

The practice of Circle of Trust pursuits the objective

that anybody in the room is allowed to express their

opinions. To start a circle of trust, the interested

person rings a bell and puts forward a topic. Every

single person in the room has to express their sincere

opinion on the question without being pressured.

4.3 Non-ludic Practices

This section presents the rest of the practices carried

out during the Intensive-Day. Making a total of 9,

they have no ludic aspects included.

 Preparation: planning and organizing the

logistics required for the Intensive-Day.

 Opening & Welcoming: opening the day and

presenting schedule, rules and logistics to the

stakeholders.

 Team Roles: introducing the teams and

explaining the roles to be used.

 Concepts: explaining concepts, dynamics and

supporting tools to be used during the -Day.

 Enclosing: stakeholders define initial objectives,

individual expectations and expand on the actual

reasons for being there.

 Packages: categorizing needs and requirements

expressed by the stakeholders. Identified

packages are used to initially group desired

functionalities obtained during AVAX Storming

practice.

 Non-functional Requirements: determining the

non-functional requirements of the desired

system. Consultants use a fixed questionnaire

based on the Pre-Day information.

 Final Agreements: closing all open topics,

dispelling doubts and getting the last comments.

 Closure & Raising a Toast: applying a

satisfaction survey of the -Day and making a

farewell toast.

Figure 1: Intensive-Day method diagram.

ImprovingSoftwareProjectsInceptionPhaseUsingGames-ActiveActionWorkshop

185

5 RESULTS

ActiveAction workshop resulted in a successful

game-based strategy that has improved the Inception

phase of the software development projects based on

the fact that: stakeholders express their ideas freely

in an unstressed environment; simulate real-life

scenarios to identify exceptions; prioritize risks and

identify requirements in a collaborative manner.

ActiveAction has been applied in 19 projects

with the following time distribution of the Intensive-

Day: 65% dedicated to game-based core practices,

17% of resting time and 18% of non-ludic practices.

5.1 ActiveAction Advantages and

Disadvantages

ActiveAction has resulted in a powerful tool for

Entia, which started to sell it as a separate service,

giving the customer the right to choose Entia or

another organization for further construction.

The following are ActiveAction workshop

benefits identified by Entia:

 Software products' origin and rationale are

known and understood by stakeholders.

 Each and every of the stakeholders' points of

view are taken into account.

 The whole team takes the project as something of

its own, not something imposed.

 Relatively relaxed in-game environment helps to

come to agreements among many people.

 Applying games helps to establish rules,

objectives and behaviors in a natural way.

 Customer satisfaction and emotional engagement

is easily achieved.

 The Inception phase is completed within three

weeks.

 The Entia successful project rate has grown 25

percentage points, from the initial 56% up to

81%.

On the other hand, ActiveAction requires a high

demand of skills, concentration and knowledge from

the Coach, Analyst and Process Engineer roles. 12

hours in-a-row, independently of the activity to do,

requires a lot of effort and concentration, so finding

adequate pace is important. Besides, the

organization must distribute carefully their key

personnel, consultant team members, between their

daily work and the ActiveAction Days, which can

compromise other projects of the organization.

The following are drawbacks identified by Entia:

 Difficulty in getting stakeholders together if they

are geographically distributed.

 Difficulty involving stakeholders in the -Day's

activity due to their passivity.

 Uneasiness to share opinions when the "boss" is

present.

 Including stakeholders' clients into the Intensive-

Day may not always be possible.

5.2 Validation and Improvement

Suggestions

In order to get feedback on limitations and identify

opportunities of improvement, three surveys are

applied both to stakeholders and consultants. A scale

from 1 to 5 is used to rate each item, also a free

comment section is also considered.

Two of the surveys are applied at the end of the

Intensive-Day with the objective to measure

stakeholders and consultants' satisfaction. The third

survey is applied to stakeholders at the end of the

Action-Day. The grades average from the last 10

ActiveActions is summarized in Table 1.

Table 1: Surveys’ results summary.

Intensive-Day Stakeholders' survey Average

Overall experience 4.8

Achievement of expectations 4.8

Intensive-Day Consultants' survey Average

Overall experience 4.4

Stakeholders team involvement 4.7

Consultants team performance 4.7

ActiveAction Stakeholders' survey Average

Proposed Solution 4.6

Has ActiveAction benefited your

organization?

4.7

Would you use ActiveAction again? 4.8

To improve ActiveAction stakeholders have

expressed a number of suggestions: to split the

Intensive-Day into two sessions; add ambient music;

reduce the duration of breaks but increase their

number and make a summary at the end of each

practice, mainly in Buy a Feature practice.

Consultants have observed that: information

about stakeholders is fundamental to prepare

Intensive-Day; a list of pre-prepared questions about

the stakeholders' business is useful to "re-activate"

discussions; more "standing-up" practices should be

added; playing with LEGOs is not fun for

everybody; AVAXes could be created and reviewed

in teams instead of individually; Non-Functional

Requirements practice could be omitted if the

stakeholders do not have technical background; and

lastly, if the product owners are not present

Intensive-Day must be postponed.

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

186

6 CONCLUSIONS AND FUTURE

WORK

Considering the non-techincal nature of software

project Inception activities, stakeholders can be

involved in depth and join software developer

organization at this particular moment. In fact,

addressing factors like executive support,

engagement of key stakeholders and clearly defined

needs increases the success rate of a project.

However, stakeholders' involvement is a complex

action that requires investment of extra effort and

time and be intrusive for both parties.

The strategy of using games within software

developing projects in order to address and improve

collaboration between stakeholders and development

teams can be considered as a novel and beneficial

approach. Consequently, game-based approach has

been adopted as a strategy to improve the Inception

phase outcomes.

ActiveAction is a workshop service which

objective is to clarify and process stakeholders'

needs and priorities. During the Intensive-Day,

game-based activities provide a favorable

environment in which stakeholders and development

teams collaborate and produce results of great

importance for the Inception phase of a project.

Two lines are identified as future work: (i) to

replicate the workshop in affiliates and (ii) to define

a continuous improvement process for ActiveAction.

At the moment one affiliate has replicated its first

three ActiveActions with promising results.

Moreover, documenting the method will reduce the

possibility of variation and find ways to improve.

Finally we can conclude that the inclusion of

games in such a challenging and over-whelming

activity as software projects inception, is feasible

and reported promising results which benefit both

stakeholders and software developer organizations.

ACKNOWLEDGEMENTS

The authors thank Miriam Eréndira Jiménez-

Hernández and Roberto Azrael Medina-Díaz for on-

site observation and initial analysis of the data.

This work has been funded by the GEODAS-BC

project (Ministerio de Economía y Competitividad

and Fondo Europeo de Desarrollo Regional FEDER,

TIN2012-37493-C03-01), the Graduate Science and

Engineering Computing (UNAM) and the grant

scholarship program of CONACYT.

REFERENCES

Abt, C., 1970. Serious Games. Viking Press.

Ambler, S., 2007. Defining Success. Dr. Dobb's.

http://www.drdobbs.com/architecture-and-

design/defining-success/202800777

Bloch, M., Blumberg, S., Laartz, J., 2012. Delivering

large-scale IT projects on time, on budget, and on

value. Insights & Publications, McKinsey & Company

Cantoni, L., Faré, M., Frick, E., 2011. User Requirements

with LEGO. University of Lugano. webatelier.net &

NewMinE Lab, version 1.0.

Entia, http://www.entia.com.mx/ 10/18/2013

Gamestorming, http://www.gogamestorm.com/ 29/12/13

Gartner Survey, 2012. Gartner Survey Shows Why

Projects Fail,

http://thisiswhatgoodlookslike.com/2012/06/10/gartner-sur

vey-shows-why-projects-fail/ 10/18/2013

Hohmann, L., 2006. Innovation Games: Creating

Breakthrough Products Through Collaborative Play.

Addison-Wesley Professional, 1

edition.

Ibrahim, R., Ayazi, E., Nasrmalek, S., Nakhat, S, 2013.

An Investigation of Critical Failure Factors In

Information Technology Projects. Journal of Business

and Management, IOSR. ISSN: 2319-7668. Vol. 10,

No. 3, pp. 87-92.

Innovation Games, http://innovationgames.com/ 29/12/13

Knauss, E., Schneider, K., Stapel K., 2008. A Game for

Taking Requirements Engineering More Seriously. In

Proceedings of the International Workshop on

Multimedia and Enjoyable Requirements Engineering,

ISBN: 978-0-7695-3626-2, pp. 22-26.

Kruchten, P., 2003. Rational Unified Process—An

Introduction, Addison-Wesley, 3

edition.

LEGO, 2010. LEGO Serious Play: Open Source. The

LEGO Group.

Michael, D., Chen, S., 2005. Serious Games: Games That

Educate, Train, and Inform. Course Technology PTR,

edition.

Morales, M., Oktaba, H., 2012. KUALI-BEH Kernel

Extension. Annex B (Informative) in: Essence –

Kernel and Language for Software Engineering

Methods. Object Management Group.

http://www.omg.org/spec/Essence/ 10/18/2013

Mountain Goat, http://www.mountaingoatsoftware.com

/scrum/product-owner/ 10/18/2013

Osborn, A., 1993. Applied imagination: Principles and

procedures of creative problem solving. Charles

Scribner’s Sons, 3

edition.

Stepanek, G., 2005. Software Project Secrets: Why

Software Projects Fail. Apress. New York, 1

edition.

The Standish Group International, Inc., CHAOS Summary

for 2010.

Torvinen, V., 1999. The Labour Game Method. In

Proceedings of the International Workshop on

Database and Expert Systems Applications, ISBN: 0-

7695-0281-4, pp. 382–386.

ImprovingSoftwareProjectsInceptionPhaseUsingGames-ActiveActionWorkshop

187