Learning day

Today my company arranged a Learning day in the format World Café Method which was really positive. In short all employees gathered together during the afternoon for discuss different topics in small groups. Every topic was introduced with a lightning talk followed with intense discussion's and sketching (every table were prepared with paper, pencils and questions). The idae to time box all sessions made everyone focus on what they wanted to say or/and ask. There was lot of energy in the discussions....really positive.

So why do I even write about this? The idea is nothing new. I guess it's more popular today when all companies goes agile. I will tell you what I though made this something extra.

Findings

We wrote down on the table what we discussed and in the end of every session we were asked for what findings we had done. Like a really short retrospective. If I only had discussed and afterwards went back to my desk, it would have been like a long coffee break.

People

I meet new people in my company. Instead of sit with my colleagues, I put myself outside my comfort zone and sat down with colleagues that work with something else in another department, like project managers, configuration manager, line manager, etc. I already know what my closest colleagues think and would say; because we see the same side of the coin.

Course reflections

Last week I hold my second internal company course, Coding standards and behaviors, with focus to make my colleagues more interested into the topic. In the end all attended had to give feedback on the course and it resulted in the image below.

Feedback from the course Coding standards and behaviors

And now some reflections...

The target group

The course was open for all who was interested to learn more about the topic. In the invitation I had included an agenda to reach the right target better. I do believe I did well with the invitation. I don't only want to have geeks in the audience.  I do know that the discussion get better when people have different backgrounds. Also, I get better feedback.

My preparations

I started with a pre-study about the course content 2 months before the actual presentation date and started preparing the PowerPoint presentation about 1,5 week ahead. During the first phase I tried to read and collect as much information as possible, e.g. documents, books and blogs. I tried to summaries everything in headings. The second and last phase was about sorting the important and most interesting parts into slides. This is the hard bit!

What I aimed for

The main focus was to make people more interested in writing safer code and using coding standards and coding style, as a help to achieve it. Also by being aware about strange behaviors (undefined and unspecified) in language, like C, are also helpful. I tried to have simple example but I also added a few more complex, with purpose to show how hard it is to understand some parts.

Was it appreciated?

This one is the tricky part, but I do believe it was based on three facts:

1. All the seats were filled the same day the course as announced
2. The picture above shove that most of the attendees marked it above average on the interest scale
3. I received some personal and positive feedback afterwards.

Because the target group was quit wide I expected some feedback were people thought it be not so interested or it wasn’t what I had expected. The questions are:

• Can I do anything about it?
  Yes, by a) more précised target group and b) more detailed agenda.
• Should I do anything about it?
  It depends. If I am asked to hold the same course once more I will probably update the course description. But in the same time I want to keep the content a little bit open, especially if it’s something new I have to do research in.

Why do I teach?

Because it’s fun! I also learn more about the subject when I need to teach it.

Some tips if you want to hold a presentation

If you haven’t held a presentation before, you should now that creating good informative slides take really long time. First of all you have to define two things:

1. What is your story?
2. How is the target?

The first one is a help for planning. Do you know everything already today? Or do you have to do a lot of research first? It also helps you to stick to the plan. The second one decides on what technical level you should have on your presentation. Is it a Java for dummies or advance cache optimization. If the target group is more senior, you should be prepared for trickier questions. They can even tell you that you are wrong :-)

When you finally start with the art of creating slides, here are some general tips:

• Stick to short and few sentences
• Pictures are nice
• Verify your colors on a project screen.
• Font size. can the person in the back read it?
• Style consistency. The layout should be similar between the slides
• Add questions (as a reminder for you to wake up the audience:-) )
• Avoid preaching
• Add some extra energy on the start end slide

Bigger retrospective - my first time

Finally I did it! I had my first bigger/higher retrospective. It wasn’t perfect, but I learned a lot.

In April last year I wrote a post on the internal forum at my company about Retrospective on a higher level, where I discussed that we missed some form of finalizing, round-up of each project. A planned time were all developers, testers, architecture's and manager sit together a put there view on how they thought it went. A possibility to visualize choices that resulted in good and bad,  from which we can learn from.

Why bigger?

Running retrospectives after each sprint is a great way to reflect after small changes. Maybe your team has tried pair programming or TDD for a sprint and then its perfect during the sprint retrospective to reflect over what everyone thought about it.


But during a project for several months or years it happens a liitle bit more:

• Several teams are working with different parts and the code changes a lot.
• There will be lot of communication ans synchronization  between the teams and managers.
• New way of working like remote-pair-programming.
• New tools are introduced .
• People leave the company and new people start.

This list can be made long. My point is that some changes a three week sprint is not enough to make reflection from. You need more input data to spot the delta.

My frirst trial

After I have read Joakim Sunden’s post, Running big retrospective at Spotify I finally moved from just talking about it to actually doing it. And it was great!

What I did was:

• I invited all how has been involved during a 6 month period.
• Booked a conference room for a hole afternoon.
• Prepared me well with agenda, post it notes, etc.
• No computer!
• Happy mode curve.

As I mentioned in the beginning the result wasn’t perfect, but it was ok. Unfortunately only developers attended, which only give one side of the project. What I missed was that several invited was invited as optional and not required. Yes, some people actually take notice of this.

The good part was I really believe everyone who was there really enjoyed it. One important part, that I also put extra care to, was that everyone should participate. It’s very common that there are only one or two who speaks all the time (some smart people sit silent in the back and don’t care about agile and processes). By letting everyone write down what they did during the gathering data phase, and put them on a timeline on the whiteboard afterwords, everyone got a chance to share there thoughts and feelings.

Another good factor was the happy mode curve. Everyone was asked to draw a “sinus curve” describing what they felt for the task during the hole project. Is was a clear correlation between the curve and “how well” the project went.

Another the last success factor was to not bring any computer. We did it truly kindergarten way. We used pencil and paper.

I will do it again!