See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/267924029

Agile project management in public events

Conference Paper · July 2010

DOI: 10.13140/2.1.4305.6324

CITATIONS READS

2 944

3 authors, including:

Tomas Gustavsson
Karlstads Universitet
8 PUBLICATIONS 8 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Inter-team coordination in large-scale agile development settings View project

All content following this page was uploaded by Tomas Gustavsson on 07 November 2014.

The user has requested enhancement of the downloaded file.

 Agile project management in public events

M. Sc. Tomas Gustavsson

(Department of project management, Karlstad University, Karlstad, Sweden, tomas.gustavsson@kau.se)
Dr. Peter Rönnlund
(Department of project management, Karlstad University, Karlstad, Sweden, peter.ronnlund@kau.se)

Abstract

Companies in the IT industry today often use agile project management methods to govern their projects. Agile
methods value high transparency, self-organizing teams and a process to inspect and adapt. Some of the tools
and disciplines from these agile methods are purely aimed at software development. The hypothesis of this paper
is that the agile project management methods are suitable in other areas as well. This paper presents preliminary
findings and conclusions about using agile project management methods in public event projects.

The case study, carried out with an action research methodology, investigates the Swedish company Galaxen
who have organized public music and culture events since 1992. This research indicates that several techniques
and principles, originally developed for software programmers, can be adopted also in the area of public events.
Time-boxed iterations and visual tools for planning, collaboration and follow up are being used with great
success.

Keywords

Agile project management, agile methods, public event projects, project management, scrum

1. Introduction

Methods for Project management originate from large development projects during the cold war within the
American military industry (Engwall, 1995). These traditional methods aim at upfront planning for measurement
and control for projects which, at the time, had nearly endless resources. The goal was not a specific deadline but
to finish as early as possible. Nowadays, most small projects are still managed by the same principles (Nilsson,
2008) even if their preconditions differ a lot from these cold-war projects.

In the IT industry a new project management approach has emerged over the last decade. A number of methods
which share common values are called “agile methods”. These methods derived from crisis situations where
projects could not meet the deadline, where the time plan failed or where the quality of the delivered project
results, unfortunately, was not up to standard (Schwaber, 2004). To save the project from such situations, control
has been required with maintained flexibility.

1.1 Event project management

Research studies show difficulties in planning and organizing public events (Getz, 2005). Festivals often fail and
Getz (2002) has listed a number of reasons: the weather; lack of corporate sponsorship; overreliance on one
source of money; inadequate marketing or promotion; and lack of advance or strategic planning. Many events
and festivals are today managed with traditional project management methods (Getz, 2005). Could the choice of
project management methods and tools perhaps be the source of the problems with advance and strategic
planning?

1.2 Agile project management

The popularity of agile project management methods are growing and research shows an increasing amount of
successful projects due to the transition into agile project management (Schatz and Abdelschafi, 2005). In agile
project management, project plans are made to be flexible and allow changes even late in the process. Constant
demonstration of the project result, follow up and retrospectives allow the project team to repeatedly decide new
ways of action for the project. Follow up does not have the purpose of comparing progress with the original plan
but instead to show the actual status in the project for better decisions for the future (Schwaber, 2004). Agile
methods are characterized by short iterative cycles with actual delivery of project result at the end of every cycle.
In software development the deliverables are working code that can be used by the customer.

Tomas Gustavsson & Peter Rönnlund

In traditional project management, milestones are used to control the project. To reach a milestone means that a
number of activities should be finished by a certain time. When activities are not finished on time the milestone
is not met until later in the project and the project is therefore delayed. To avoid project being late, agile methods
use the time-box concept instead. This means that the time and date (the deadline) supersedes the activities
meaning that regardless of how many activities have been completed, the project phase ends on a specific date.
In management and control terms that mean that the project manager and the sponsor must constantly prioritize
and reprioritize what should be done before the accepted deadline. This is, however, nothing new; this is how the
media industry (newspapers, TV, radio) has always worked. The time-boxed iteration cycles are often called
“sprints” (Schwaber, 2004).

In agile methods ‘the people factor’ (Cockburn and Highsmith, 2001) is strongly emphasized. Instead of
controlling thousands of people in really large projects agile methods focus on how to achieve efficiency in small
teams. To achieve this, team members need flexibility in their team roles and use a “high bandwidth” (Schwaber,
2004), informal communication. Formal communication is, of course, also important and agile project teams
gather once a day in a fifteen minute, time-boxed, meeting called “the daily scrum” with a set agenda. Each team
member should respond to three questions: What have you done since our last daily scrum? What are you doing
today? Are there any impediments in your way?

Visibility and transparency are important agile values and an agile tool for this is the commonly used “Scrum
board” (see Fig 2). The name originates from Scrum, the most used agile method today (Andersson et al (2008)),
and consist of a simple sheet on the wall. The sheet (or whiteboard) consists of three columns that show both
planning and status for the ongoing iteration. The columns are named “Not started”, “Started” and “Done” and at
the start of the iteration, all goals and activities are written on post-it notes and lined up in the “Not started”
column prioritized from top to bottom. The team members start working from the top of the board and every
team member is responsible for moving the note to the correct column depending on the status of the activity.
The Scrum board therefore becomes a transparent “window” for the project since it always shows the current
status.

2. The case study company

This case study investigates the Swedish company Galaxen who have organized public music and culture events
since 1992. The main event is the annual summer music festival called Arvikafestivalen where 30 000 people
attend in a three day event. This is a typical hallmark event (Getz 2005) for Arvika municipality. Galaxen
realized the difficulties in planning and organizing public events and started a one year project management
program to train future event project managers in 2004. A typical class consists of 15-20 students who train
project management skills by managing a number of small real public events during a year. Typically, every
student manages 3-5 projects during the year.

The company experienced that traditional project management methods and tools were not entirely helpful in
their management training. The tools helped on a high level of management but did not assist the project
manager in working with small teams. At first they tried to develop tools on their own until they came across the
term “Agile” and realized that the values stated in the agile manifesto (Schwaber, 2004) corresponded with their
own beliefs. In 2006 they adopted the ideas of agile project management and implemented some of the agile
methods in their management program.

2.1. Method of research

This paper is conducted with an action research method. Since 2006, the authors of this paper have continuously
studied and participated as coaches and guest lecturers for the event project management program. The various
projects have been examined and studied 10-15 times per year since 2006 until today. Every visit has lasted for a
day consisting of observation as well as coaching and lecturing.

3. Managing event projects with agile methods

Since there are many forms of agile values, tools and methods, the event managers have continuously
experimented in many ways. Below are the most important tools the project managers’ uses today. The chosen
methods and tools have been altered in different amounts during the years but the event managers now
experience that the chosen tools are beginning to stabilize in their appearance and use and only smaller
enhancements are made every year.

Tomas Gustavsson & Peter Rönnlund

3.1 Short value-based iterations

Event projects always have a deadline that can not be negotiated. Many event projects also inherit their deadline
due to history of the event itself. Managing a Christmas Day music festival doesn’t leave much space for
negotiation, for example. Since this is natural for event project managers, time-boxed iterations (sprints) fits
naturally in the way they think and act. The event project managers experience that agile sprint planning has
been a helpful way of planning for event projects.

Sprint planning for the event project managers consisted of deciding real and made-up deadlines in order to
divide the project into short goal oriented sprints. A made-up deadline is a project internal deadline with a
specific goal. The real deadlines were easy to find out, such as the date of the festival, but the made-up deadlines
had to be decided for in order to achieve management control of the project. Made-up deadlines are such as
when to stop looking for sponsors or when to end advertising.

The length of these sprints varied from a week to a month depending on the size of the project. No matter how
large the projects were, sprints never exceeded one month in length in order to be flexible and to have several
opportunities for replanning, learning and reflecting. For every sprint the team decided on changes of team
members, resources and one or several goals. The information was written down on a large piece of paper titled
“Sprint plan” and put on a wall in the project office (Fig 1).

Fig 1 Sprint plan for event project managers

The sprint plan was used instead of a traditional project management Gantt chart. A traditional Gantt chart is
normally used for long term planning (PMI 2004). It was used for two purposes: as a planning tool and as a
simple form of communication to team members, sponsors and stakeholders. Information on the last line (named
“Lessons learned”) was updated after a final meeting at the end of every sprint. In this meeting (the
retrospective) changes were also decided for the following sprints.

3.2 Visual planning and follow-up

Once the long term planning of sprints had been made, the project team started using the scrum board with goals
and activities of the first sprint (Fig 2).

Tomas Gustavsson & Peter Rönnlund

 Fig 2. The scrum board for event project managers

The goals (large notes) and activities (small notes) were written down on post-it-notes and added on the first
column. A difference between typical goals for software development projects and event projects at Galaxen was
that goals for event projects often described levels of fulfilment. Instead of “getting three outside sponsors for
the music event” goals rather expressed “getting outside sponsoring for 65 percent of total costs”. Therefore,
goals were not easily measured until at the very end of the sprint. The activities were easy to see whether they
were completed or not (for example “negotiate the sponsorship details with Mr Richard at Volvo”) but the goals
often had to be calculated and discussed at the end of every sprint.

The scrum board was a natural meeting place for the team members. When working in event projects the teams
members usually needed to do work in different locations so formal meetings were rare. With this board, a
natural meeting point was established. The team also decided on a daily meeting time where they conducted their
daily scrum meeting to learn about each others progress and problems.

4. Conclusions

These preliminary findings indicate that agile methods work well for public event projects. For strategic
planning the overall sprint plan has been used successfully. The agile values of short time-boxed iterations which
makes it possible to make quick changes has worked very well in these event projects where deadlines where
crucial. The need for detailed planning has been solved by using an agile visual tool (the scrum board). Apart
from being a good visual support for planning it has also helped collaboration in the team. Together with the
daily scrum meeting, the board has been used for gathering people, understanding status and making quick
decisions for the future.

We cannot prove that the agile project management methods and tools have been the definitive reason for
successful outcome of these projects. Other factors, such as the personality types of these project management
students, could have been reasons for success of the event projects completed over the years. However, success
rate of the projects has increased over the years as more and more agile methodology has been implemented in
the training program. Further studies need to be conducted in order to verify the increasing success rate of these
public event projects.

5. References

Andersson, D., Laribee, D., Cohn, M., Hussman, D., Killen, S. & Lacey, M. (2008), The state of Agile
Development, VersionOne, Alpharetta.

Tomas Gustavsson & Peter Rönnlund

 Cockburn, A. & Highsmith, J. (2001), Agile Software Development: The People Factor, IEEE Computer, 34(11):
131-133, Los Alamitos.
Engwall, M. (1995) Jakten på det effektiva projektet, Doctoral dissertation, Nerenius & Santérus, Uppsala (in
Swedish).
Getz, D (2002) Why festivals fail, Event management, 7 (4): 209-219, Cognizant Communication Corp, New
York.
Getz, D (2005) Event management & Event tourism, Cognizant Communication Corp, New York.
Nilsson, A. (2008) Projektledning i praktiken, Doctoral dissertation, Umeå School of Business (in Swedish).
PMI – Project management institute (2004) A guide to the Project management body of knowledge. Project
management Institute, Pennsylvania.
Schatz, B. & Abdelschafi, I. (2005) Primavera Gets Agile: A successful transition to Agile Development, (IEEE
Software, Volume 22, Issue 3), IEEE Computer Society Press, Los Alamitos.
Schwaber, K. (2004) Agile project management with Scrum, Microsoft Press, Redmond.

Tomas Gustavsson & Peter Rönnlund

View publication stats