Saturday, 6 July 2013

Let's Play!!

I am a true believer that people learn more by doing than reading or listening. So I try to make my teaching more interactive. That is also good for me. English is not my mother tongue language so sometimes, some "big" words that would explain something really good and precise, they just don't come to me at the right time. But if I tell stories, play games, engage others, have eye contact and discuss, I am a better presenter. Another coach that I have great respect, Griffin Jones, pointed these out to me at the Open Space back in April and I think he hit the nail in the head in 2 minutes.

Recently I feel I am writing a lot of presentations. Not sure how I ended up here, but I am really spending a lot of time with PowerPoint and formatting slides. I will tell about 2 sessions because I think both my audience and myself enjoyed. Read this as a retrospective of good sessions, but never forget that there is always lessons to learn from those too.

1. A new team in Agile was struggling with how to work in Scrum
I am the Scrum Master/Coach for this team. I joined the team when they had passed the business decision to work on this project and they were into the initial design discussions. I knew that some Agile training was done but didn't know that only some of them had participated. So on our first retrospective, the number one frustration was "we do not know what is next in this Agile process. We knew before what to do and what to expect, but now we are not confident". Clearly, there was need to explain not just Agile thinking, but more of agile mechanics.  I prepared 6 slides to explain how Agile fits into System thinking/Lean, the 9 rules of scrum and then, we plaid. I decided to play "Build me a city" with Lego. You can find the material here: 
The game in itself is fun. We found some Lego talents and they had to do the whole scrum process end to end. We did back log, sprint planning, demos and retrospectives, burndown reports and also added a spin with remote team members (working far from the table) and a 50% allocated person (switching between the two teams).
One team started asking me early on some decision they had to make like "Is the bridge for people or cars, or both?". At the end of the first sprint, they had some building prototypes to show me and I gave them feedback so they could fix it later. After all, that team did really well. They did what I asked, made changes after my feedback on demos and added also some delights since they loved playing with Lego :)
The other team did not interact with me between sprints. I met them and their Product Owner only at demo. The did not present me any prototype for buildings during the iterations, but at the end showed me 1 of each. Clearly, they did not understand my requirement to have several buildings of each type. The very first thing one of the team members did, was to draw a blue line on the paper and say "here is the river" without asking the others. They all jumped in alarm and told him to stop until they draw a concept of the city first. And then the whole design was around the river being where was drawn. They also did not organize well the work between the team members and the level of collaboration was more on the chaotic side. After all, they built only 1 type of building, added some delights when my main requirements were not completed and felt like pointing the finger to the product owner after all.
Here the pictures of what they built

Guess who learned more? The second one!
After the game we had some good discussion and I was there just to ask questions. The answers were somewhere in them, or the other team. Was really good and fun and we still use it as reference when we are in similar situations in real software development.

2. Working with Executive leaders
I volunteered to hold a session with my team of coaches about the pain of presenting to executives. Someone asked "Who are we considering Executives?" and the best answer he got was from Gino Marckx across the table saying "When it gets scary :)". The model I proposed was Insights Discovery because this model is used for Customer Service Representative training. After all, I think, talking with an Executive is like serving a client what they are looking for. After I explained the model, I got everyone in the room to build their personality tower, again using Lego blocks. This was easy, just a group of 4 colored blocks per each (red, blue, green, yellow) but they all felt engaged and "IN" the presentation. To make it more real, I gave them the task to prepare to present the status of project to an Executive sponsor. I made up a project that was in really bad shape and I split them in team A and B. Team A will present to a Red executive and Team B will present to a Blue executive. I had prepare a 1pager for a real Executive leader of the company to explain to him what was going on. After both teams had about 30 minutes of preparation time, the executive came in the room and took a seat. Both teams presented to him in 10 minutes each and at the end, we had a chat with him.
Here is them preparing. Guess which team is writing things down and preparing detailed report? :)

Team A didn't do very well. They took it easy and relaxed and "told" him what they were planning to do. He fired them on the spot :). The "PM" was literally sweating even-thought that was all staged.
Team B learned from Team A and started well (with introduction), presented better and supported with material. They "offered" options for next step.
Funny thing is that, the Exec said that none of the teams did a good job to convince him that they will get the project on track. The plan was 10 minutes chat after the presentations, but he went really above and beyond to explain to us real life situations with some really scary executives. Was really good and very fruitful 60 minutes of everybody's time.  Ended up being a talk that I wish I had recorded and listen over and over. Funny thing is, that he had been sleeping for 2 hours every night in the last couple of days. Imagine if his energy tank was fully loaded!


  1. certifications will definitely increase the salary significantly. For project management professionals, I would suggest them to attend any genuine agile scrum certification courses (eg. Scrum Master Certification). If not anything, at least it will give a boost to your career and salary.

  2. Looks like this post is attracting some interest on the Scrum certifications. That was not my goal. Although the trainings offered by different organizations are helpful, Scrum certification is taking Agile away from the original goal or connecting Business with IT. Certifications are used as "the way" to run Agile. In my opinion Agile is something you sense, measure and act as required. No formula, no rubber stamped solutions