We use cookies to help us provide you with the best experience, improve and tailor our services, and carry out our marketing activities. For more information, including how to manage your cookie settings, see our privacy notice.


Skip to content. | Skip to navigation

Community-made content which you can improve Case study from our community

How to Organise an Event as an Agile Project

According to the last global survey of project management practitioners by the Project Management Institute, more than 70% of organisations used the Agile approach to managing their projects at one time or the other.

The Agile approach, once mostly reserved for software development, has officially jumped industries. One of the fields it has jumped to is event organisation and management.

The Agile approach has to be modified to better suit the specific nature of non-profit event organisation and management, but just looking at some of its ideas and goals, it becomes clear why it is an exciting proposition:

  • Empowering self-organized and cross-functional teams
  • Enabling effective internal and external collaboration
  • Improving adaptability
  • Continuous improvement
  • Delivering more value

The following steps will help you build the foundations for your first (and hopefully many future) Agile non-profit events.

Things you'll need

  • Willingness to try something new
  • Basic knowledge of Agile (Scrum and Kanban)
  • A cross-functional team
  • Organisational buy-in

Assemble and educate the team

Depending on the size of your organisation and the event at hand, you will have more or less choice when it comes to people you will invite to join your Agile team. It is essential that you actually invite people to join your Agile endeavour. Pushing Agile onto teams has become all too common, which completely misses the point.

As the Agile “advocate”, you will be responsible for educating your team on the potential benefits and pitfalls of taking this approach. That being said, the team formation process should involve an open discussion on what Agile entails and how the team would work.

Remember, Agile teams are self-organised.


Agree on practices

Once your Agile team is packed with people ready to try something new, it is time to agree on the Agile practices and concepts you will be adopting. Agile is a complex ecosystem with numerous frameworks and methodologies and, in consultation with your team, you will want to figure out what will work best for you.

Scrum and Kanban, besides being the two most popular approaches are also arguably best suited for organising events and your choice will most likely be between the two.

Kanban, for example, focuses more on the workflow, limiting work in progress and continuous delivery. Scrum focuses more on the iterative way to work by organising work into time-limited sprints with specific goals that add explicit value to the finished product, in our case, a well-organised event. (Please, keep in mind these are gross oversimplifications.)

While you will probably need to adapt these approaches to your process, you should avoid overdoing it because this might lead to reducing the potential beneficial effects of the Agile approach.

This is especially true for Scrum which is a more structured framework with complex interdependencies that may not be obvious initially but which play a big role in determining how successful the team will be.


Build a Product Backlog

Regardless of what kind of an Agile approach you choose, the next step will be building a Product Backlog. The Product Backlog represents an ordered, prioritised list of everything your team will be doing to organise the event. It will include everything from finding the venue, setting the event up, doing marketing for it and anything else you can think of.

In essence, it is an upgraded version of a to-do list.

The work that will need to be done will be broken down into Product Backlog Items (tasks, stories) which will be clearly described and estimated in terms of time and effort needed. For example, finding the venue will include Product Backlog Items such as:

  • Determining the budget
  • Doing initial research
  • Contacting venue #1
  • Contacting venue #2
  • Visiting venue #1
  • Visiting venue #2
  • Negotiating terms
  • Reviewing the contract
  • Signing the contract

While these tasks will be clearly described, the team members themselves will work out the best way to do the actual work and complete them. This is where the self-organised aspect of Agile teams comes into the picture.


Build a Board

Visualisation of the workflow is the key aspect of Kanban, while the vast majority of Scrum teams also prefer to have a way to visually represent the work they are doing. This is why boards have become an integral part of the Agile experience. Depending on the approach you have chosen, you will build either a Kanban board or a Scrum board.  

Your board will be divided into columns that will represent the different phases in completing the tasks (Product Backlog items). You should start with three basic columns - To do, In Progress and Done.

You can modify your board any way you like, adding columns, grouping them or subdividing them into more specific ones - whatever suits your process the best.

The tasks will move across the board and provide your team with an overview of how the project is going, where the team stands at any given point in time and whether there are tasks or parts of the process that require more attention.


Hold Meetings

In order for Agile to work, the team needs to collaborate and communicate, both internally and with external stakeholders. While the focus should always be on constant, in-person communication, holding Agile meetings is always a good idea, especially for new teams such as yours.

Scrum probably does this the best, prescribing different meetings (events) aimed at best supporting the process. Through these various meetings, the team openly inspects their work and the process itself, identifies problems, looks for possible improvements and ensures it gets as much feedback from external stakeholders as possible.


Inspect and Adapt

At the very core of Agile is the process of inspection and adaptation which applies to absolutely every aspect of delivering a product (in our case, organising an event).

Your team should actively inspect every aspect of their work and collaboration - from the practices you have employed, the tools you agreed on to the way you are getting tasks done and the communication with everyone involved.

One of the most important things to do here is not to turn this into a blaming and scapegoating exercise. You have to remember that the team stands together as a unit and that individual blame has no place in Agile.

Once you notice anything that can be changed, you move on to adaptation and make the necessary changes. After all, this is why you set out on the Agile path in the first place - to be able to make changes without disrupting too much of your process. 


Put down everything learned

One of the biggest differences between organising an event and the work that is usually done the Agile way is that an event is a one-off, temporary experience. However, your organisation is likely to do more events in the future and, because of this, you can benefit from another very important aspect of Agile - continuous improvement.

Namely, by taking stock of your first Agile project, you can ensure that your future endeavours are even better.

For example, you might have discovered that the promotion of your event should have been a higher priority in your Product Backlog. Or, you might have discovered that your on-site team should have featured more members. There are innumerable things you can take away from your first Agile event.

Documenting all of these findings and discussing them after the event is crucial. Through honest and open inspection and communication, you will build a strong foundation for your future Agile events.

Further information

Organising a non-profit event as an Agile project is a challenge. However, potential benefits are more than worth it. Read about it, talk to the people in your organisation, give it a go. If it turns out the Agile approach doesn’t work for you, you can easily go back to the old way of doing things.

There is no shame in that.



Page last edited Sep 18, 2018 History

Help us to improve this page – give us feedback.