Blog

Agile, Scrum and Talent Management not only for IT professionals

How to conduct your first agile meeting (IT or not)

During the last weeks I have had the chance to organize two different first Agile meetings with 2 different groups.  One was my first Meetup in Mallorca with Agile practitioners and the other one with a client team in UK.  Very different cultures, completely different audiences.  In any case I confirmed some key aspects that help a lot when you organize an Agile meeting:

  • Clarify Why are we here for:  In both cases the aim of the meeting was shared in advance to all participants. For example: Share your experience on Agile, Watergile or Agilefall practice in 3 minutes.  Nevertheless, once in the meeting is always good to make sure everyone knows why they are there without making assumptions up front (when was the last time you asked to the people in the room if they knew what was the meeting for?).  So, in the presentation round, asking to share expectations is sometimes useful to manage the scope of the meeting and clarify what topics will not be covered. 
  • Review the rules of the game with participants: the meeting mechanics can be clarified and agreed with participants.  What do we do if we are more people or less than expected?  Shall we wait for those that are late? How long can we stay if necessary? Who needs to leave earlier?  Who goes first?  How we solve the poor Skype connection? The projector does work or better to use flipchart?  Any topic that should be included in agenda?
  • You acknowledge where you are and how you feel: the initial chitchat talk is extremely useless for some people, but for most is the human touch you need to have an open conversation.  You can also acknowledge during the meeting: if you foresee a deviation in the timing it is always good to ask the participants for help to manage time.  Are you all OK on finishing later? Anybody that needs to leave earlier? What if we change the time allowed per person?  Shall we cover this topic and leave the other for later?
  • You do look back to learn - In my case both meetings had learning purposes behind, so that people can take something home right after.  You care for the past only in order to move forward faster.  This means you need to address the elephants in the room if necessary, and that includes pointing out behaviours that you consider were damaging (if a colleague annoys or hurts us in a way that impacts our work, for example) but also those that helped!  Meetup participants for example shared their experiences and some highlighted specific types of people that facilitated change and some types of people that didn't.  Interesting to confirm that personality do influence how Agile teams work, but that is material for another post. ;)
  • Ask for feedback - it does not need to be super engineered questionnaire, but a very simple round of comments or wrap-up helps if there is no other way at hand.  It also helps to shape next meeting.  For example Meetup participants suggested to have another meeting in which the topics to share were first voted by the audience so that we could start for those more relevant to more people.  Important:  Remember that in an Agile meeting the responsibility of the outcome is shared, the same as in any project.  It is a co creation process and unique itself, as the combination of people plays a role.  Of course facilitators help, but each meeting could be a completely different scenario.  A first meeting with a group of people is like a first iteration.  They are not necessarily a team.  They might or not know about Agile, and each has different level of knowledge.
  • Focus on the outcome: As servant leader conducting an agile meeting the least of your worries is to expect to be liked.  Do focus on the value each one takes home. An agile meeting is one of those precious opportunities for magic to happen, discover insights from people and qualitative information you will not find in databases.  It helps you to become better facilitator next time, adapting your style to the specific group in hand.

All these points don't seem "Agile" specific right? I would say there are 3 key aspects that make them different from others:  

1- You want to build trust and human interaction instead of monologue-type discourse

2- You allow participants to shape the meeting and self-organise as much as possible 

3- You care about adding value to each participant: there for agenda is flexible as long as it serves this main outcome

Greetings from foggy London!