Last week I asked the community for help on designing an agile talk rather than a talk on agile .
If you don’t want to read the full article here’s the TLDR: Can we embed the agile values in the format of a beginners talk so that people will learn by breathing them rather than hearing about them?
I received quite a lot of encouragement from a lot of people. I love the agile/lean community, thank you folks, you are incredible!
I got some great suggestions from Patrick Steyaert that recommended looking into Lean Coffee and Fish Bowl.
Both formats are highly participative and pretty much agendaless and gave me a great point to start at.
My goals in priority order:
- Do not bore an audience that for the first time hears about agile. Don’t push them away!
- Identify a format that embodies the values I believe to be the most important in agile and make sure the attendees feel and recognise them while they are attending
- Make sure people actively participate
- Have fun
To me the most important values in agile are: people, customer and responding to change.
I asked 3 fantastic practitioners to help me on the day. The 4 of us were “the agile product team” that was going to deliver the product (learning) to our customers (audience)
Thank you so much to Claudio Perrone, Andrea Baker and Lisa Hickey for accepting to help with less than 24 hour notice and no details whatsoever on what i needed them to do (isn’t this ability to respond to change? :-))
I told the audience that me and my team mates were going to give a product to them, they were our customers and as such they were extremely important.
To start we needed the customer help to understand what real value is to them.
We asked them to select with dot voting some agile topics from around 35 different agile topics (I took a subset including mainly basic concepts).
The customers immediately queued towards the table where the cards and the markers for voting were. We time boxed the activity to 5 minutes. Claudio, ever the lean man, immediately identified a bottleneck as the table was too small and only 2 to 3 people could vote at the same time.
The activity had to be extended to 6 minutes to allow everybody to vote.
The team took 6 topics with highest number of votes and put them on the wall in dot voting ranking order.
We started with the first topic.
It happened to be BDD: First thing, I asked the customers if they knew what it was. One of the people in the audience started giving us his take. When he finished, I spoke about it a bit, then my 3 team mates took turns in adding their perspective.
Responding to change
This lasted for 5 minutes when the timer went off and i asked the audience to tell us by using thumbs up or down whether they wanted to continue talking for 5 more minutes about BDD or if they wanted to move to the next topic.
People voted for sticking to BDD for 5 more minutes
After 5 more minutes we voted again and we went to the second topic.
We made sure that the team swapped activities, everybody took turns in talking about the topics, we alternated roles like time keeping and pulling the cards from the wall.
We wanted to show team collaboration and cross functional abilities.
I got loads of feedback from the people in the audience and the team.
Claudio suggested that when talking about topics, the first couple of sentences need to describe it in a easily understandable recipe format, this is true in particular because of the audience low level of agile knowledge.
Davide Lovetere an enterprise Architect among our customers gave me a lot of incredibly valuable feedback around some contradiction in terms he had noticed during execution.
Other customers said that they enjoyed the format and want to use it for some of the meetings they do in work (yay!)
Other customers said that they enjoyed it but it finished too early, we only had time to talk about 4 topics and they would have loved to touch more
I loved doing it, received valuable feedback to improve it and can’t wait for the next time!