This year, instead of focusing on what happened, I wanted to focus on the future. Therefore it’s a futurespective rather than a retrospective.

I create a custom agenda for every big retrospective. This one was created for this year, exclusively. For a different example for a year 2015 retrospective have a look at this writeup from my colleague Pat Kua. If you need help creating yours feel free to reach out to me.

You will notice that the agenda’s focus is creating a vision for my life in the future. I have been making very good progress with smaller goals from retrospectives in the past, but I felt it was time to more big picture.

“The best three days of my life” (Day one)

I first imagined, how the best three days of my life could look like. These three days are in a glorious future - not necessarily in 2016. I didn’t want to restrict my imagination.

Steps

1. Brainstorm circumstances and events that should take place within these three days. As a result I have a big collection of ideas that could form the three best days of my life. One of this events, for example, was giving a keynote at a conference.
2. Create a schedule of the events. Remove obsolete ideas or circumstances. Fill in the gaps in the days. The result will be a schedule of how the best days of my life could look like. As an example, I chose the keynote to be on Friday at 10:00am (day one¹).
3. Write an essay about these three days. The result will be a story of the three days. Writing a story helps to make it more real. To make it more vivid, I also imagined less relevant facts - for instance a concrete topic for the keynote.
4. Analyse the underlying needs of the events and circumstances captured.

Find goals for 2016 (Day two)

On the second day, I reviewed some retrospective material and created goals for 2016. It was helpful to do the second part while the material from the three days was still in mind.

Steps

1. Read the last retrospective letter and review events since the last retrospective.
2. Reflect on life patterns that I want to change. Use the 5 Why’s to understand the root cause and how they could be changed.
3. Brainstorm stretch goals² for the year 2016. The goals need to be in relation to the needs identified on day one.
4. Select a maximum of two stretch goals for 2016.
5. Assume when I fully reach the stretch goal, it is a status 5. Also assume that the current status is a 0. Write up all statuses from 5 to 0 with one or two sentences. The result will be two big goals and also smaller steps to get nearer to these goals³.
6. Create a plan for a weekly heartbeat retrospective to support the achievement of these goals.
7. Summarise the retrospective by writing a retrospective letter for this retrospective.

Results

I’ve now done this futurespective and gained some interesting insights. I also have two stretch goals for the new year⁴. I noticed while executing this plan that I also need space for goals besides the two big ones. Amongst the four I selected is learning to draw and start to learn more from other people rather than books. But, none of the side goals is a stretch goal.

Hope this writeup was interesting or useful to you.

I learned more about agile software development and I worked with interesting technologies. I am also dealing with clients and represent my company at a client site. I did learn of all that - and I don’t expect to stop learning anytime soon.

But there were a few things I learned, which I did not expect to learn at ThoughtWorks. I want to share three of them with you.

1 - It is OK not to know everything

It seems like pretty common sense that we cannot know everything. If you had asked me in April 2012 if I needed to know everything, my response would have been “no”. But it is a difference to know it, or to feel and act upon it.

When I joined, my impression was: “I needed to foresee potential problem which might arise in a project”. So I needed to know all the technology and all the implications, right?

Well, I couldn’t. Nobody can. But I learned that we have a different approach. At ThoughtWorks we tend to deal with problems when they arise. This is the moment you know the most about it. We avoid dealing with problems that might arise at some point.

This is engrained in the company. “I don’t know” is a sentence you’ll often hear. But it is usually accompanied with: “But I’ll find out (when it’s necessary)‘.

2 - Everyone can contribute

Since I heard what pair programming is, I always wanted to try it. I had tried pair programming before - but not as extensive as at ThoughtWorks. Pair programming gives developers the opportunity to contribute to the movement of a project. Starting on day one.

When I joined my first billable project, I didn’t know anything about the project. Nor did I know anything about the client. But I knew Ruby. In fact, I had done more Ruby programming than any other developer on the team.

It was my the first day on the project. I was a grad consultant in a team full of senior developers. And I could suggest improvements in the application while my pair was showing it to me.

This is not limited to pair programming. Everyone - be it a graduated or an experienced developer - has a different experience or point of view. Maybe it is even a stupid but important question. Everything can be valuable input.

3 - The most fun you get is out of people you work with

Before ThoughtWorks, I believed that the most important thing about work is what you do. But it is with whom I work, which has the most influence on my work happiness.

When I joined, I had a 4 week project simulation for training with a simple technology stack. Nothing new, nothing exciting. Before ThoughtWorks, I had been working for almost three years with a similar technology stack. I had even been teaching it to other developers. So technology wise it could not have been a more boring start.

But I was there with a bunch of other graduate consultants. Some of them new to the technology. I learned, how fun it can be to pair and work with people who immediately pick up what you are coaching them. And the next day, they will teach you something!

Can there be more fun than this?

In this article, I will share some code how we did this. The example works in Google Chrome - for DOM manipulation I will use JQuery.

Starting simple, we have one file input for images and an area to show the uploaded images.

1
2
3
4

<body>
 <input type="file" accept="image/*" class="js-image-upload"/>
 <div class="js-image-container"></div>
</body>

When the user select a file, we want to store the image.

1
2
3
4
5
6

$(document).on('change', '.js-image-upload', function (event) {
  var file = event.target.files[0];
  var fileName = createTempName(file);

  writeImage(fileName, file);
});

The image storage is handled by this method.

1
2
3
4
5
6
7
8
9
10
11

function writeImage(fileName, file) {
  getFileSystem(function (fileSystem) {
    fileSystem.root.getFile(fileName, {create: true}, function (fileEntry) {
      fileEntry.createWriter(function (fileWriter) {
        fileWriter.onwriteend = writeSuccessFull;
        fileWriter.onerror = errorFct;
        fileWriter.write(file);
      }, errorFct);
    });
  });
}

What is happening here?

• Retrieve the file system
• Create a file by the specificied name on its root
• Create a writer for this file
• Configure a success and error callback when the asynchronous file write happend
• Write the blob of the file using the writer

The retrieval of the file system is a two step procedure. We need to request quota from the browser and than get the file system.

1
2
3
4
5
6

var SIZE = 100 * 1024 * 1024; // 100 MB
var getFileSystem = function (successFct) {
  navigator.webkitPersistentStorage.requestQuota(SIZE, function () {
    window.webkitRequestFileSystem(window.PERSISTENT, SIZE, successFct, errorFct);
  }, errorFct);
};

The user will be asked to grant the website the access to a persistent storage. There are some errors you can get, e.g. when the user does not accept our request.

But let’s assume the user trusts us. Then we want to react to the successful write and show the image. We can use a local file storage url and add the file to a queue to upload the file to the server.

1
2
3
4
5
6
7
8
9
10

var showImage = function (fileName) {
  var src = 'filesystem:' + window.location.origin + '/persistent/' + fileName;
  var img = $('<img />').attr('src', src);
  $('.js-image-container').append(img);
};

var writeSuccessFull = function () {
  addToSyncQueue(fileName);
  showImage(fileName);
};

I’m omitting the queue logic here. You can keep a queue of images for uploaded in the web storage or IndexedDB of your application. To read the image from storage you can use something like this

1
2
3
4
5
6
7
8
9
10

var readImage = function (fileName, successFct) {
  getFileSystem(function (fileSystem) {
    fileSystem.root.getFile(fileName, {}, function (fileEntry) {

        fileEntry.file(successFct, errorFct);

      }, errorFct);
    }
  );
};

So this is a brief overview of what we did here. The working example code can be found here: https://gist.github.com/jthoenes/3668856a188d600e02d6

Hope it has been useful to a few people dealing with similar issues. Feel free to ask questions, when something pops up in your mind.

I facilitated a retrospective using the Lean Coffee exercise. This helped to generate some good discussion, but in the end there was no action item. Is that a bad thing?

Let me give you some context.

I facilitated my fourth or fifth retrospective about two weeks ago. For the ‘gather data’ and ‘generate insight phase’, we ran a 40-minute Lean Coffee. This means:

1. everyone writes topics to discuss on post-it notes
2. the topics get democratically prioritised by dot-voting
3. the topics with highest priority get discussed in a time-box

I used this exercise for the second time in a retrospective. Both times it was good, because it created an open discussion and thought exchange about topics important to the team.

But each time, the discussion ended with no concrete conclusions or action items.

I think the Avoiding the Do-Nothing Retrospective principle is quite important (see Agile Retrospectives). And this kind of retrospective violates this principle in my eyes.

Nevertheless, I believe that this is fine in some situations. There may be topics in a team that need to be discussed. Sometimes even topics which linger for weeks to months. I feel these topics cannot be discussed in a one to two hour iteration retrospective.

For me, starting a discussion is the outcome of the retrospective. Maybe the discussion will continue during the iteration or within the next retrospective and eventually yield action items. Would you agree?

I was wondering if there is a way to keep the very open format of the Lean Coffee (or something similar), while still generating to more action items. Is there some exercise to do later to pick up ideas shared? Maybe by helping the team to set potential milestones in discussion?

Do you have some ideas?

But how can you deal with low safety in a team outside the retrospective, e.g. in stand-ups or estimation meetings?

A few retrospectives ago, I had the feeling it was time to do a ‘Safety Check’ - grading the participants willingness to share from 5 (highest) to 1 (lowest). The result with 6 people was:

1. -
2. 2 people
3. 3 people
4. -
5. 1 person

The exercise indicated that safety was an issue. I used techniques to continue the retrospective supporting people who are not willing to share ideas publicly (e.g. they could ask to not discuss a topic without revealing their identity). I had explained how I would react to a low level of safety before performing the check, so participants knew the result would not be a show stopper. The retrospective was surprisingly well received and we actually discussed a few things more openly than usual.

While I felt it was good to do the safety check, I’m unsure how to deal with the outcome outside of the retrospective. Before the team worked together under the unspoken assumption that it was actually safe to speak up.

I know there are plenty of good ideas out there how about to handle safety issues in a retrospective. Unfortunately, I feel I don’t have a good answer on how we can handle or improve the situation on a daily basis working.

What came to my mind was:

• Talking to people individually and casually.
• Running another safety check about 2 month later and discuss the result with the team.
• Don’t take the result personally.
• Don’t overreact. This has been a snapshot and maybe there are certain barriers to speak - but it’s not the end of the world.

What would you suggest?

Then you put the letter in an envelope and close it. At the beginning of the next retrospective you open the envelope and read the letter. Thereby you can bridge two personal retrospectives together.

Purpose

The purpose of the ‘Write a Letter to Yourself’ exercise is to write an essay to document the most important hopes, wishes, lessons and decisions of your personal retrospective. It’s a little bit like the final declaration.

Besides that, you do it create a continuity and strengthen the ritual of a personal retrospective.

Steps

• Get a clean sheet of paper - I always use special letter paper for the exercise.

• Start with “Dear ”.

• Summarise the following things (each is optional):

  • What you did in the retrospective.
  • What you experienced in the retrospected time frame.
  • What you learned during the retrospective.
  • What you decided to change until the next retrospective.
  • What you hope or wish to happen until the next retrospective - caused by your commitments.

• Close the letter positive.

• Put the letter in an envelop and close the envelope.

• Store the letter somewhere safe and read it before your next personal retrospective. Alternatively - give it to someone you trust and ask them to send it to you at a defined date.

• At the beginning of the next personal retrospective: Read the letter and see what happens.

Remarks

The writing part of the ‘Write a Letter to Yourself’ is done at the end of the retrospective, therefore it belongs to the Closing the Retrospective phase. The reading part will happen at the very beginning of the next retrospective and therefore belongs to the Set the Stage phase.

In a personal retrospective, I think it’s very difficult to have this phases explicitly. The letter exercise helps me to work them out.

I like this exercise a lot, because it helps me to focus on the most important things I hope for and want to achieve for the next few month. It helps as well, to build a continuity between two retrospectives.  I do this exercise in every personal retrospective I hold, except for my weekly heartbeat retrospectives.

Some people asked me, if it isn’t weird to write a letter to yourself. I have to say: yes it is. But it’s an interesting experience and easily done. So you should try it at least once.

I did it first after a seminar in rhetorics about 12 years ago. For me, it was really helpful to get a fresh summary of my own lessons four weeks later. When Linda Rising mentioned an letter exercise during her SE Radio interview, I adopted it to be used for personal retrospectives.

Alternatives

To be honest, I haven’t used any other exercise to creating a final summary of my retrospective.  I can imagine people drawing a picture, creating a mind map or even writing a song about it. But other than that, I don’t know a real alternative which really helps to strengthen the Closing the Retrospective and Set the Stage phases as well as supporting the ritual of a personal retrospective.

Do you know or use any alternatives?

Picture: http://www.flickr.com/photos/gbaku/3770390554, Creative Commons: http://creativecommons.org/licenses/by/2.0/ 

I use it, to capture thoughts that otherwise are in danger to be forgotten. This is especially helpful during focused exercises like the timeline ([1] and [2]), where there will be thoughts coming up, you cannot process into the current context.

Purpose

During a personal retrospective, you think about a lot of things. So it can be hard to focus on the things which you want to focus on. The ‘open thoughts paper’ is a way, to dump ideas on a paper and out of your brain - to allow the brain to focus on the subject matter.

Steps

• Before you start the retrospective, you place enough paper with a separate pen at the side of the table.

• While you do other exercises, when there is a though you don’t want to process within the current exercise, write it down. Continue with the original exercise.

• Examples for these thoughts are:

  • “Oh, I really need to book that train ticket.”
  • “Shouldn’t I have called my mum yesterday.”
  • “Hm, the connection between what happened at that party and my behaviour at work the next day is intersting. I need to spend more time thinking about it.”

• At some point of the retro, you need to have the time to process these thoughts.

Remarks

I use this in all my retrospective. It helps me, to not be afraid of flowing thoughts while still being focused on what I really want to reflect on. I usually catch up on the paper in a specific exercise at the end of my personal retrospective. For example, I can use the content for ‘an essay’, the ‘retrospective letter’ or the ‘retrospective questions key point lists’. Simple tasks will of course find their way in my todo list.

The ‘open thoughts paper’ is not really an exercises. It is a continuous companion of a personal retrospective. You could group it somewhere between the Gather Data and the Generate Insights phase.

Alternatives

I don’t know any direct alternatives to the ‘open thoughts paper’. Of course, you can note the ideas down on a tablet, notebook or anything else. But I think, its important to have them written down, so your not afraid of forgetting them.

But maybe you have an idea? Have you ever tried something similar? Will you share it with me?

Picture: http://www.flickr.com/photos/freddyfromutah/4424199420, Creative Commons: http://creativecommons.org/licenses/by/2.0/

A timeline is a chronological overview over the period you are reflecting on. This has been filled with facts before. Now you analyse it deliberate by using colours to describe your feelings.

Purpose

When you have filled a timeline, now its time to analyse it. On way is to colour code the events, so you can see, when you had which kind of feelings over the timeframe. Use this in the generate insight phase, to get a clearer understanding of the connection of what happened and what you did.

Steps

• In the previous steps, you filled the timeline with events.
• Choose colour coding for specific feelings you had, e.g.
  • Happy: green, Sad: red, Surprise: yellow
  • Mad: red, Sad: blue, Glad: green
• Take a step back and look at the patterns over the timeline.
  • Can you see new connections?
  • Can you explain why the red came in?
  • What happened to make it all yellow?
• As a result, you can
  • Add more colour to the timeline.
  • Connect events with colours.
  • Have multiple colours in one event - potentially of different strength.
  • Write down things you noted.
• Iterate over this a bit until you feel your done.

Remarks

I’ve so far always used colours in some form when I did a timeline. It’s fairly easy, because I can easily model my feelings. Also, the colours help me to quickly get an overview over certain periods of time. Was there a red month? Oh, suddenly everything became green? That’s interesting.

I write this down on a ‘open thoughts’ paper, save them for ‘an essay’ or even put then on ‘retrospective questions key point lists’.

The ‘colour the timeline’ exercise belongs to the Generate Insights phase. As such, you want to use the timeline you have, to find out what happened with you and your feelings.

You can, if you want to, colour anything in the timeline. Feelings is just what I always have done so far.

Alternatives

A part from all the other ‘generate insights’ exercises, there are a few tailored to using a timeline.

One is the so called ‘emotional seismograph’, where you draw a seismograph of your feelings under a timeline. I’ve done the exercise a few times, but I think its more useful for team retrospectives as you can see the different seismograph curves.

The ‘mine the timeline for gold’ is rather for thinking and writing insights down in a list. This is especially helpful, I think, if you have a focus of your retrospective.

As always, you personal retrospective has to be tailored to you. Any thoughts? How would you analyse your timeline?

Picture: http://www.flickr.com/photos/7897906@N06/487018802, Creative Commons: http://creativecommons.org/licenses/by/2.0/

I use timelines often - therefore it’s the first exercise I share with you. I’ll try to keep the structure of this post for the following posts as well: purpose, steps, remarks and alternatives.

Purpose

The purpose of the timeline activity is to get a chronological overview over what happened in the timeframe you are reflecting on. Use it to gather data and excel your remembering by finding temporal connections between events.

Steps

• Select a paper to do the timeline on. I usually tape together three or four A4 papers horizontally, so I have a long line of paper on the table.

• Divide the paper into sub timeframes,  for example weeks, and mark them clearly, for example with the start date.

• Go through your calendar or diary and write events relevant to you at their appropriate place in the timeline.

• Use other sources as well to remember important events:

  • I have a weekly log from my heartbeat retrospective. This is a great resource for a yearly or quarterly retrospective.

  • Others Ideas for sources are: call history on the phone, e-mails, text messages, twitter/facebook status updates, etc.

  • Any kind of log  at work serves as well. I used: git/svn commit logs, jira ticket logs and my engineering log.

• When filling in the timeline, you will probably recall other events, which are not from the sources. Put them in the timeline as well.

Now that the timeline is filled, you can analyse it. I will write about how I analyse it in future posts.

Remarks

The timeline exercise is the heart of any of my long term retrospectives. I like to use it, because the temporal connection between the events helps me a lot to remember things I otherwise would have overlooked.

The ‘fill the timeline’ part belongs to the Gather Data phase. The analysis of the timeline is part of the Generate Insights phase. There are a few exercises, you can use to analyse it like ‘emotional seismograph’, ‘colour coding’, ‘mine the timeline for gold’ etc. I will write about some of them, give a comment if you are interested in a particular one.

While doing the timeline, I often already get ideas for the Generate Insights or Decide What to Do phases. I keep an ‘open thoughts paper’ on my side, to not forget those - but still focus on the gathering of the temporal data.

Alternatives

As this exercise is for gathering the data, you can use any other means to gather data. I have been using ‘collecting notes on the move’ and the ‘feedback mind map’ exercise for it. But to be honest, for me personally the timeline feels the best way.

Of course, this will be different for other people. What is your favourite? Any thoughts, ideas, suggestions? Please share them with me! I’m really looking forward to hear them.

Picture: http://www.flickr.com/photos/94168846@N00/1461630711, Creative Commons: http://creativecommons.org/licenses/by/2.0/

This is what I came up with:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

protected
def wait_for_javascript_event event_name
  selenium_bridge.setScriptTimeout(Capybara.default_wait_time * 1000)

  selenium_driver.execute_async_script(
    "var callback = arguments[arguments.length - 1];
    $(window).one('#{event_name}', function() {setTimeout(callback, 1); return true;});"
    )
end

private
def selenium_driver
  page.driver.browser
end

def selenium_bridge
  selenium_driver.send(:bridge)
end

So, what is going on?

• Capybara does not provide the feature to execute asynchronous JavaScript. So I get the selenium driver in and grab the private Selenium bridge. The bridge gives me access to this API: JavascriptExecutor

• I set the script timeout to the timeout I set in Capybara. I found, that otherwise there is a timeout of 2ms, which was not enough for me.

• Then I execute asynchronous javascript. This Javascript will get a callback as last parameter of arguments injected, which I need to call, once I’m finished with waiting for the event.

• Inside the JavaScript, I set up a listener for the event I’m interested in. When I get the event I’ll immediately return true - so the event propagation goes on and I don’t change anything in the actual website.

• A millisecond later, I execute the callback. Why later? Because without it, the execution of the normal JavaScript in the browser stopped. I guess, but haven’t verified, that otherwise the Ruby code will directly come back - therefore the JavaScript in the browser is in a weird state.

Is there a better solution?

I don’t know. I googled a bit and found none - so I came up with this solution. If there is a better one, I would be really glad. The code is not really obvious, has a lot of technical details and is tied quite strongly to the selenium bridge. I cannot switch to another driver, say poltergeist.

Do you have a better solution? Tell me!

Why do we need to do that at all?

When looking for solutions, I found a lot of people who asked how you actually can wait for events in Capybara. The answers were mostly around changing something in the websites JavaScript itself, e.g. showing a hidden element.

That’s not possible for us. We are building a smoke test. The event is coming from a different system, which is not under our control. In theory, I could try to get the other guys to change something in their page. But that’s not something to be done easily and fast.

What is the book about?

According to the book, crucial conversations are define as those conversations were:

• there are high stakes

• there are opposing opinions

• there are strong emotions

The aim is, to hold these crucial conversations as a dialog.  A dialog is a conversation where everyone can freely contribute to a growing pool of opinion. In non-dialog conversations people tend to make accusations or don’t contribute their views. In other words: they get violent or silent.

The book outlines a strategy to manage your own emotions in those conversations. Your emotions are created based on your interpretation (named story) of the facts you observe. It presents techniques to notice your interpretation explicitly and thereby handle your emotions better.

What was particularly interesting?

The most important learning for me was the part about being silent in a conversation. I have been silent in multiple crucial conversations in the past. In fact, I was confusing it with being diplomatic. But the authors of the book stress, that it is important to get all ideas freely on the table.

It was helpful to me to learn which techniques you can use - they are usually presented with an acronym. For instance the AMPP (ask, mirror, paraphrase and prime) technique to help others to overcome the silence, or the observe, tell a story, feel, act technique for understanding how emotions develop.

What is my conclusion?

I think the book has very interesting content. I'll definitely incorporate some of the ideas into my conversations. The book was presented in an easy to read way including many examples, which made the ideas presented very obvious.

I was expecting a bit more advice on conversations which don’t necessary involve so strong emotions - but maybe I should have rather picked a moderation book for that.

I didn’t like the introduction. It sounded a lot like an advertisement - and like the book would solve all problems humanity every had (which it doesn’t).

In summary, I think it is a good book to read for everyone who wants to learn about how humans communicate in emotional situations.

Format

The conference is one track and every speaker has 30 minutes or an hour to present his topic. At the end, there is no opportunity for questions - that is were the open spaces are for.

There are open spaces for two hours on both days. You can and should use this time to talk directly with the speaker about their ideas or your questions and suggestions. This allows you to really dive into the topics - rather than only getting the answer to one question. And of course, you can discuss any other topic you like.

Content

I’m not going to cover all topics - you can find them here. And there should be videos out soon. But I will summarise a bit.

As the guiding theme was Kanban, there was a lot about Kanban in the program. The recurrent theme to me was to look at the human side of Lean and Agile, mostly on Kanban as example: How can we communicate with Kaban? Why are we doing Kanban? And when should we stop doing it? How do we understand and respect individuals as part of the Kanban process?

We also had a very interesting discussion about Personal Kanban in the ‘Personal Lean and Agile’ open space. It definitely made me curious to finally read the book and see how I can combine it with my Personal Retrospectives.

There are three talks I would like to mention specifically. You might want to watch them once the videos are available:

• The Keynote by Dave Snowden were he introduced the Cynefin framework, which is a very intersting idea to get into your mind. Also he introduced the concept of an invention as an helpful error: serendipity. A very interesting idea.

• Jasper Sonnevelt talked about Kanban, remember why? were he reminded us, that we introduce Lean and Agile for a reason - not for itself. And that we need to challenge the system, to spot the big improvement potentials.

• In The Other Side of Kanban Chris McDermott explained the importance of understanding and respect for the people in a Agile or Lean adoption process. Especially to those who are resistant.

Reflections

So, how was it for me?

I met a lot of people and was engaged in a lot of interesting conversations. The open spaces especially support interactions between participants. I really liked that.

I come back, with a ton of new ideas what to do and at least five books which I would really like to read (well, there have been some before in this category).

The way the open spaces were ran, could be improved.

What I think is sad, was that sometimes open spaces were in polish. I know, that its hard to discuss in a foreign language. But please think of the people, who want to join a open space later.

Also the groups were a bit big - in some conversations I had the feeling, a lot of people were not really able to engage in the discussion. Maybe more smaller spaces could help?

Of course, in such a conference the number of things you find to be directly applicable to your context are limited. However, there were a lot of things which got me thinking - what is all you can expect from a conference. And there is at least one thing I would like to try out.

In conclusion: I really liked the conference. The discussions and topics were very interesting. The people were open and positive - and Krakow is a lovely city to visit.

So I’m sharing what I plan to do at the 2nd or 10th of January:

• Intro Music: Listen to my retrospective song, to start the retrospective ritual.

• Read Retrospective Letter: I write a letter to myself at the end of every longer retrospective. This time I’ll read the letters from 2011, Q1 2012 and the letter from the TWU retrospective.

• Social Interaction Analysis

  • Queries: I’ll search in Facebook, Xing, LinkedIn, Twitter, E-Mail, Call-Log for some interesting patterns. I will prepare some statistics before the retrospective. In this step I’ll analyse those data.

  • Social MindMap: Integrate the insights gained from the queries into the a MindMap which should includes also the feedback I received directly from my peers.

• Timeline

  • Enter Facts: Put the facts into a timeline to see the development over time. Data sources will be: Calendar, Heartbeat Retrospectives, other Retrospectives, Notes and my brain.

  • Color the timeline: green for positive feelings, red for negative feelings and blue for surprises. Which each color, try to find out, why this made me feel this way.

• 5 Why’s: Select the three most important topics and ask why five times to find out the rood cause.

• Decide what to do

  • Define goals: Define a limited set of main goals for next year.

  • Define measures: Find way to archieve these goals. Select the ones which I want to pursue. Reject some as well.

  • Select SMART-Objectives: For every measure find at least one SMART-Objectives so I can commit to it. The commitment itself happens in a heartbeat retrospective.

• Heartbeat Retrospectives

  • Effectiveness: Think about, why heartbeat retrospective lost their effectiveness this year.

  • Time: Think about, why heartbeat retrospectives were not so regular this year?

  • Goal: Find means to make heartbeat retrospectives to support the goals I defined before.

  • Plan: Create a new plan and form for the heartbeat retrospective.

• Write Retrospective Letter: Write a letter to yourself to be read before the next retrospective.

• Outro Music: Listen to the outro music to close the retrospective.

That’s the plan for now. What do you think? Do you have any questions?

I plan to do an article on every item of this plan in the first 6 month of the next year. So if you are interested, stay tuned.

I have done personal retrospectives at different times, using different schemes.

There are two basic schemes I separate the timing of a personal retrospective into:

• regular retrospectives
• event triggered and topic oriented retrospectives

Regular Retrospectives

Let’s start with the regular retrospectives. A regularly held retrospective has a fixed time, when you do the retrospective regardless of your current situation. You do the personal retrospective simply because it is the time for it.

This has the obvious advantage, that you spot things about yourself in a retrospective, which you might not have noticed when you were in the middle of your daily stress. In a way such retrospectives are the more natural ones - their reason ia, to take time, breathe a little bit and notice things about yourself, which are important to notice.

Topics oriented retrospectives

There is one problem with regular retrospectives though, especially with the very short heartbeat retrospectives. You might feel the lack of time to think about an individual, but important topic. These topics can come up, in relation to a certain event in your life. For instance, when you moved into a new city or switched your job.

These topics can become the topic of a special targeted retrospective. You can prepare yourself thoughoutly, gather feedback from important peers and tailor the retrospective timetable towards this very topic.

The caveat of this kind of retrospective is, to not start them open minded. Preparation can lead you to conclusions before the retrospective. This can be fine - but it can also make you blindsided for other solutions.

My timing scheme

My current strategy is - as you may have guessed - a mix of both schemes:

• A regular heartbeat retrospective every week
• A topic retrospective at certain event or raised from the heartbeat retrospective
• A regular year-end retrospective in the first week of a new year

I conduct my heartbeat retrospective every week. It takes place on the evening before the next work week starts. This is mostly sunday evening, but the rule is adaptive to covert e.g. a bank holiday on monday.

This type of retrospective helps me to notice, if there are topics I need to dive into. It is both a weekly planning session and a safety net, to notice bigger topics in my live to reflect upon. The heartbeat retrospectives are structured very simple - they take between 10 and 15 minutes and can be held nearly everywhere.

The topics raised in the heartbeat retrospective are extended into a topic oriented retrospective. This helps to keep the heartbeat retrospective short. A topic retrospective can take from one hour up to four hours. Sometimes they need some pre-research, e.g. in my private wiki, in my mails or in my calendar. Depending on the topic, I might talk to people and ask what they think about the topic in question.

A typical example for a topic retrospective is a retrospective I recently did, when I came back from India having been a grad of ThoughtWorks University. I reflected on everything which happened in these six weeks - and tried to infer the lessons I can learn from this time.

The final retrospective is the year-end retrospective. It takes up to 8 hours and when doing the retrospective, I try to look back on my whole year. I try to cover all important topics and distill the most important learnings from one year.

In terms of topics, I don’t do any research upfront. However, there is a lot of things I do in preparation in terms of time, food, material and ritual support.

What about you?

As I wrote before, everyone needs to develop his own way of doing his personal retrospective. So, do you have a specific timing scheme? What do you think might work for you?

How often do you do a your personal retrospective? What are your timing schemes? Where is you approach different from mine?

This article will describe what I did. I will give an overview of my journey to actually find the root cause of what was going on. My goal with this article is to highlight examples of techniques you can use, to actually track down strange and random bug.

In the end, I found a pretty clear explanation what and why the problem happened.  And it is not a coincidence, that there is a ‘random’ in the title of this article.

Start - What was the problem

The problem was, that when following the guide for using a development virtual machine, sometimes starting up the application took a long time and then failed. I had the issue right away, after starting the application twice. Other people had the same problem.

I was told, nobody really knew, why it was behaving this way - but restarting the VM would probably fix it. It didn’t for me.

But I enjoy digging into problems - so I wanted to know, what was going wrong.

Rake File to Solr

The error occurred when running rake app:run, sometimes. From running rake with –trace –verbose, the debug option, I was able to see, that the application was waiting for sunspot to start the Apache Solr search service.

So the question was, where does the process take all the time? The good thing to start with was, that rake and sunspot are written in Ruby. So I read the code and added a few output statements to see, which statement took so long. It turned out, it was the Java process starting Solr.

Digging into the Java

Apache Solr sends some output to sdtout - but sunspot hides it from you. But as any output is very helpful when debugging, I wanted to see the output.

I used ps -aux to find the exact command-line arguments sunspot was issuing and started the process manually from the command-line. Luckily, it still took some time - so I knew the problem was not in the Ruby Code.

With the port mapper nmap I found out, that it took between 2 seconds to over 2 minutes to start the service. But the rake task only waited for 10 seconds.

Now having the the console output, I could see, that Solr internally uses Jetty - and it was Jetty in version 6.1.3, which took all the time - in the case, it took the time. So I downloaded the tag for version 6.1.3 from source control and looked into the code.

I found a system property called DEBUG which increases the output. I enabled it and saw that the last debug output, before it took so long, was something about starting the session service (I’ve lost pointer to the code - unfortunately).

This didn’t really help me. I unsuccessfully tried to make the Jetty log work with log4j to eventually see more - but I failed and had to give up for the evening (the 2nd one).

Debug the Java Code

So if your not getting anything out of the log, you can still use a debugger. The code was however failing on the VM - an Ubuntu box, but not on my local machine. But fortunately Java has a remote debugger.

I started the Java process with the remote debugging arguments and attached a listener in IntelliJ with the Jetty code from SVN. I tried to get the execution stopped at a breakpoint near the last log output - but this method was called very often and I didn’t get it to hit the breakpoint at the right moment.

However, when something takes very long, it can be helpful just to stop the running process and look at the stack trace. So I stopped the execution and searched for the last method frame from Jetty, which was calling into the JDK - and there I found the following comment:

1
2
3
4
5

//This operation may block on some systems with low entropy. See this page
//for workaround suggestions:
//http://docs.codehaus.org/display/JETTY/Connectors+slow+to+startup
Log.debug("Init SecureRandom.");
_random=new SecureRandom();

The Solution

Finally - I did go to the Jetty wiki page referenced. I found out, that Java’s java.util.SecureRandom uses real entropy from the operating system - which can block when there is none available.

The solution from the wiki page, just to use the normal java.util.Random, would have been difficult, because the configuration file lives deep inside sunspot and Solr. But the line ‘NB Some workaround reports use /dev/./urandom instead of /dev/urandom’ gave me a hint, were to look otherwise.

I googled for the solution and found on Stack Overflow, that you can replace /dev/urandom random with /dev/./urandom in your Java process. This can be done by using the command-line argument -Djava.security.egd=file:/dev/./urandom or by replacing it in the file /usr/lib/jvm/java-6-openjdk/jre/lib/security/java.security (on an Ubuntu box).

So what was the matter? Java’s secure random will not accept /dev/urandom as source for random numbers. /dev/urandom is unblocking, which means it will return random numbers which can be guessed - when there is no real entropy available. So Java defaults to /dev/random which will block and wait, until entropy is present.

This is the reason, why blocking is very unlikely to occur on a production or development machine - however it did happen, when using a virtual machine, which does not have a lot of network traffic and IO. It happens especially often, when you restart an application often - as you tend to do, when something is not working.

The fix is a little funny. Java rejects /dev/urandom based on the string. It does not reject /dev/./urandom which of course points to the same potentially unsafe random number generator.

Last Words

The fix introduces a potential security risk - but on a development virtual machine this is not a problem.

As you can see, finding a bug or problem in a system involves to use techniques, which bring you nearer to the root cause. However, there is no golden path. Sometimes one technique will not get you any more information. So you will have to try a different technique. Sometimes your gut feeling might help you as well.

Having arrived here, what are your thoughts on the story?

A retrospective has to be “tailor made” as Derby and Larsen [1] point out. This is in my opinion even more important for personal retrospectives. They need to fit to your thinking, your needs and your timetable. However, it is good to start with something - and over time adapt it to your own needs. I have done this, and probably everyone doing personal retrospectives is doing it.

So here are three approaches you can derive and mix and match from.

Write, Re-Write and Read Retrospective Notes - Linda Rising

For Linda Rising[2], a well-known retrospective facilitator, personal retrospectives are an important tool, to know about herself. She writes:

The cognitive psychologists tell us that it’s difficult, perhaps impossible, to really know ourselves and why we make the decisions in our lives. Our only hope, it seems to me, is to use some of the same techniques that we use to discover what teams have done well, what they might think about doing differently, and what still puzzles them :-)!

After finishing an activity she thinks she might do again, she will think about that activity and note her thoughts on paper. She usually does this right after finishing the activity while traveling. When she arrives at home, she will type the notes and safe them into a folder called “Retrospective”.

__Before she will start doing a similar activity, she will read though the retrospective notes to prepare for it. She noticed, “that many of the lessons learned become internalized over time, but there are always surprises - things we have completely forgotten”.

On activities Linda shares with her husband - like traveling or going to a music workshop - he is joining in to the retrospective. On the way home, they talk about their experience and Linda takes notes of it. Arrived at home, she will send him an e-mail to give him the opportunity to add his comments. When they do a similar activity again, they’ll read the retrospective notes together.

All this writing, re-writing and reading is not without a purpose.

Cognitive scientists tell us that writing is important so I always write or sketch first and then type to save. Going through the comments twice also helps with learning – and that’s what it’s all about :-)!

Shared Feedback MindMap - Ilias Bartolini

Ilias Bartolini[3], my colleague and coach at ThoughtWorks University[4], has an approach centered around a mind map. He started with his self-review in the beginning of 2012, with a small mind map. He collected the data of what happened in 2011 both for work and life related aspects. The mind map grew and evolved over a couple of weeks - having the mind map always open on his laptop and capturing any important thought, when it came to Ilias' mind.

An important part of this mind map is the feedback Ilias received from friends and colleagues. But then he moved one step further: He shared the result of his personal retrospectives with the people who gave him feedback. Seeing their feedback was recognised encouraged them to give more feedback to Ilias. They supported him in his efforts to change himself and gave input how he can implement the feedback they gave.

In his blog series about his approach to self-reviews ([5], [6], [7] and [8]), Ilias tells us, that this approach helped him to create an epiphany of what happened in his year 2011. Doing the self-review gave him self-confidence and helped him to improve his effectiveness. Most of it, because he started to understand what really matters at his work and at his life.

He internalized this approach so much, that he is constantly applying it. Recently, he put parts of his mind map onto a whiteboard and asked his colleagues to give their comments to it. Here is what he got:

Currently Ilias is perpetually changing his feedback mind map. When he receives new feedback, he will update the mind map. This is his way, to keep track in which areas he needs to work on himself. But more important, it gives him confidence by clearly documenting what he already has archived.

I find going back to the mind map summary very useful in many more situations!

Building on top of Retrospective Practices - my own approach

In 2008 I listen to the excellent Software Radio Episode 105 “Retrospective with Linda Rising”[9]. I was excited about potential retrospectives could unveil inside a team. But at this time, I was a student and had no team were a retrospective could be hold. However, in the beginning of the episode, Linda told that she believed, everyone should have a retrospective of their own. It sunk into my brain and stayed there unused for a while.

In mid 2009 I graduated and got my first programming job. I started to work, moved to a new city and met new people. All was going as planned. But I was not clear about what my next goal in life would be. Up until this point, my whole life was working towards this very point. But what to do next?

This became clear to me shortly before christmas, as I told it to my father. Telling it someone, made something explicit to myself. But I suppose it has been in me quite a bit earlier. Consequently, I decided to do a year-end retrospective for 2009.

I bought some nice food, drinks paper and coloured crayons and blocked 4 hours in my calendar on a Sunday afternoon. Then I created a timetable of the retrospective practices I wanted to do

• Create a timeline of the year 2009 and then make your feeling towards the events visible with colors.

• Make notes and later write an essay about: ‘What works well’, ‘what to do differently’, ‘What did I learn and what puzzles me’

• Make a mindmap of the result of the retrospective.

I executed the plan - and was very delighted with the outcome. It really helped me to see things in my life, I did not notice before. On this day, I started to understand more about myself - and I did set goals for myself and selected action items to reach these goals.

One action item was to make personal retrospectives a ritual every three month. Six month later, during one of these quarter-retrospectives, I decided to do a heartbeat retrospective every week. I have adapted the way I do retrospectives and the scheme of having them since. I’ll write about this in a different article.

There are more possibilities

There are hundreds of more ways to do personal retrospectives. I’ve talked to someone, who travels home by train for one hour every day. Instead of reading or listening she spends the time reflecting about her day - having a retrospective every day.

Aisley Nies[9] takes some time around her birthday every year and travels somewhere. She gets “away from everything” and spends some time thinking about herself.

You can also read the retrospective reports from Aimee Daniells [10] and Mark Neeham [11] on their blogs. This gives you a hint, how they did their own personal retrospectives for the year 2011.

What about you?

Have you started or scheduled your own personal retrospectives? How will you make personal retrospectives work for yourself? What hinders you to start?

Please leave a comment or blog about it and drop me a link. I’m very interested in the different approaches.

To make sure, this is working in the way we expect, we want to write functional tests to check if the events are send to Google Analytics when we expect them.

In this article, I will describe how we created a solution were the events sent are made visible on the website in a ‘debug mode’. They are captured and tested against in our Cucumber Test suite using Capybara and Poltergeist.

Testing Google Analytics Custom Events

Custom Events in Google Anayltics are a great way to enhance your usage statistics by tracking events specific to your website. However, as they are specific to your web page, they require you to write custom logic and call ga.js when done: gaq.push(‘trackEvent’, ‘Contract’, ‘scrollToEnd’, ‘landLine’).

This means you will want to test this behaviour. So, let’s assume for this article you want to satisfy a Cucumber behaviour like this (./features/google-analytics.feature):

[code] Feature: Google Analytics Tracking

Scenario: Reading land line contract Given I am on the “/contracts/land-line” page And I scroll to the bottom GA should get an event {“Contract”, “scrollToEnd”, “landLine”}

1
2
3
4
5
6
7
8
9
10
11
12

So how to test this? We are currently working in Ruby. And there is a Ruby framework called [WAAT](https://github.com/anandbagmar/WAAT-ruby) to help test what is send to Google Analytics. It uses the [Ruby Java Bridge](http://rjb.rubyforge.org) and the [jpcap library](http://netresearch.ics.uci.edu/kfujii/Jpcap/doc/) to monitor your HTTP traffic and capture the events send to Google Analytics. While this is working, we didn't like to use Java and jpcap, especially on our CI and preview boxes.

So we thought of something different: What if we have a 'debug mode' where we just print the messages send to Google Analytics to the HTML and read them from Capybara? Turns out is no to hard.


## Print Messages send to Google Analytics


When you send any data to Google Analytics, you are using the global variable _gaq and call the push method with an array as argument. To hook into this mechanism, just implement and own push method and replace calls to _gaq.push with your own method:

javascript

var Example = Example || {}; Example.Analytics = Example.Analytics || {}; var gaq = gaq || [];

Example.Analytics.push = function () { gaq.push.apply(gaq, arguments); }

1
2
3
4

Next, add a hidden DIV somewhere to your website and use CSS to style it the way you like (I include my styles in the gist for this blog post).

html

1
2
3
4

This should be made visible (e.g. with the help of [JQuery](http://jquery.com/)), when there is a get parameter google-analytics-debug somewhere in the in URL, so for example in http://example.com/contracts/land-line?google-analytics-debug:

javascript

Example.Analytics.is_debug = window.location.href.match(/[\?&]google-analytics-debug([&#]|$)/);

$(function () { if (Example.Analytics.is_debug) { $(“#google-analytics-debug”).show(); } });

1
2
3
4

And then you can add code to make the message send to Google Analytics appear in the DIV:

javascript

Example.Analytics.push = function () { gaq.push.apply(gaq, arguments);

if (Example.Analytics.is_debug) { var args = arguments[0]; $(function () { var li = $(“

”).text(JSON.stringify(args)); $(“#google-analytics-debug ol”).append(li); }); } }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

This will add any message send to Google Analytics to the DIV. In my example this looks like this: [](/wp-content/uploads/2012/09/Google-Analytics-Debug.png) ## Write Cucumber steps with Capybara and Poltergeist Now we want to automate the testing using the [Cucumber](http://cukes.info/) BDD framework. To handle the browser part in a headless mode, we use [Capybara](http://jnicklas.github.com/capybara/) and [Poltergeist](https://github.com/jonleighton/poltergeist)/[PhantomJS](http://phantomjs.org/) to simulate JavaScript. I assume you have cucumber already running on your project. To get going, install PhantomJS, add the following gems to your [Gemfile](http://gembundler.com/gemfile.html) and run bundle install: [code] group :test do gem 'cucumber' gem 'capybara' gem 'poltergeist' gem 'rspec' end

Next add the following lines to ./support/env.rb

[code language=“ruby”] require “capybara” require “capybara/cucumber” require ‘capybara/poltergeist’

require “json” Capybara.app_host= ‘localhost:4567’ Capybara.default_selector= :css Capybara.default_driver = :poltergeist

include Capybara::DSL

1 2 3 4 5 6 7 8 9 10 11 12

Now you can use capybara to read all Google Analytics events pushed. Add a file ./support/google_analytics.rb with the method ga_pushes to extract them from the website: [code language="ruby"] def ga_pushes ga_pushes = [] all('#google-analytics-debug li').each do |li| ga_pushes << JSON.parse(li.text) end ga_pushes end

Finally implement the steps for the cucumber feature above:

[code language=“ruby”] Given /^I am on the “([^”]*)“ page$/ do |path| visit "http://localhost:4567/#{path}?google-analytics-debug” end

When /^I scroll to the bottom$/ do page.execute_script “window.scrollBy(0,100000)” end

Then /^GA should get an event {“([^”])“, ”([^“])”, “([^”]*)“}$/ do |category, action, value| ga_pushes.should include([”_trackEvent", category, action, value]) end

```

When you run the Cucumber feature you should see a passing test result.

Discussion

The solution I propose in this article to test Google Analytics Custom Events consists of two parts:

• Making Google Analytics Events visible with JavaScript

• Reading them from Cucumber tests

The underlying assumption of this is, that the ga.js library actually works - which I think you can. The other assumption is, that the first line of your Example::Analytics.push function does work as well. You have to make sure, this is true by code review and by manually testing using the ga_debug.js library or Chrome extension.

A nice benefit of this mechanism is, that you can see what Google Analytics Events are send even when you are doing development or manual testing.

On the down side, because of the get parameter, you have slightly different code in production than development and testing. You have to make your own judgement if you want to make this trade-off.

Another thing we discussed is, that people will be able to actually turn on the debugging in production as well. We don’t see a security issue here, because this will only tell people what they could already know, e.g. when using the Google Analytics Debugger Chrome extension.

All code presented in this article can be found at https://gist.github.com/3600363.

]]> 2012-08-02T23:00:05+00:00 http://blog.jthoenes.net/2012/08/02/java-8-testing-the-lambda-water Java 8 is about a year away and comes with a language feature I really look forward to: Lambda Expression.

Sadly the other big feature, Modules for the Java Platform, has been delayed to Java 9. But nevertheless, bringing lambda expressions (or closures if you like) into the language will make programming in Java much better.

So nearly one year to go - but as Java is developed open source now, we can have a look and try to use it right now. So let’s go!

Download and Install Lambda enabled Java 8

First, I expected that I have to compile Java 8 myself, as it has not yet been release. But I was pleasantly surprised to see, that there are binary build available for all platforms at http://jdk8.java.net/lambda/. So I just downloaded the latest developer preview build and installed it on my computer.

To make sure it works, I created an LambdaIntro class containing a “Hello, World!”, compiled and executed it:

1 2 3 4 5

~ $ export JAVA_HOME=~/Devtools/Java/jdk1.8.0/ ~ $ cd spikes/lambda-water ~ $ $JAVA_HOME/bin/javac  src/net/jthoenes/blog/spike/lambda/LambdaIntro.java ~ $ $JAVA_HOME/bin/java -cp src net.jthoenes.blog.spike.lambda.LambdaIntro Hello from Java 8!

Note: I use the command-line to compile and execute here, because IDEs do not support Java 8 as of now.

The Non-Lambda Way

As an example lets assume I want to loop through a list of objects. But for my business logic, I need to have the value and the index of the list item.  If I want to do it with current Java, I have to handle the index together with the actual logic:

1 2 3 4

List list = Arrays.asList("A", "B", "C"); for (int index = 0; index < list.size(); index++) { String value = list.get(index); String output = String.format("%d -> %s", index, value); System.out.println(output); }

This will output

1 2 3

0 -> A 1 -> B 2 -> C

This is not too bad, but I did two things in the same few lines of code: controlling the iteration and providing some (very simple) business logic. Lambda expressions can help me to separate those two.

The eachWithIndex method signature

So I want to have a method eachWithIndex which can be called like this:

1 2 3 4 5 6 7

List list = Arrays.asList("A", "B", "C"); eachWithIndex(list, (value, index) -> { String output = String.format("%d -> %s", index, value); System.out.println(output); } );

The method receives two parameter. The first one is the list and the second one is a lambda expression or closure which instructs the method what to do with each list item. As you can see in line 3, the lambda expression receives two argument: the current value und the current index. These arguments do not have a type declaration. The type information will be inferred by the Java 8 compiler. After the arguments, there is a -> and a block of code which should be executed for every list item.

Note: You will have to write this method in a normal text editor or ignore the error messages inside your IDE.

Implement the eachWithIndex method

To use a lambda in Java 8, you need to declare a functional interface. A functional interface is an interface which has exactly one method - the method which will be implemented by the lambda expression. In this case, I need to declare a method which receives an item and an index and returns nothing. So I define the following interface:

1 2 3

public static interface ItemWithIndexVisitor<E> { public void visit(E item, int index); }

With this interface I can now implement the eachWithIndex method.

1 2 3 4 5

public static <E> void eachWithIndex(List<E> list, ItemWithIndexVisitor<E> visitor) { for (int i = 0; i < list.size(); i++) { visitor.visit(list.get(i), i); } }

The method makes use of the generic parameter , so the item passed to the visit method will be inferred to be of the same type than the list.

The nice thing about using functional interfaces is, that there are a lot of them already out there in Java. Think for example of the java.util.concurrent.Callable interface. It can be used as a lambda without having to change the code which consumes the Callable. This makes a lot of the JDK and frameworks lambda enabled by default.

Using a method reference

One little handy thing coming from Project Lambda are method references. They are a way, to re-use existing methods and package them into a functional interface object. So let’s say I have the following method

1 2 3 4

public static <E> void printItem(E value, int index) { String output = String.format("%d -> %s", index, value); System.out.println(output); }

and I want to use this method in my eachWithIndex method, than I can use the :: notation inside my method call:

1	eachWithIndex(list, LambdaIntro::printItem);

Looks nice and concise, doesn’t it?

Summary

This makes my first lambda example run. I couldn’t avoid a smile on my face to see closures running in one of my Java program after longing for them so long. Lambda Expression are currently only available as a developer preview build. If you want to find out more, read the current Early Draft Review or go to the Project Lambda project page.

I uploaded the full example code to gist.

]]> 2012-07-31T19:01:58+00:00 http://blog.jthoenes.net/2012/07/31/creating-a-ritual-for-a-personal-retrospective

Creating a ritual is a core part of planning your personal retrospective. In this article I will share briefly some thoughts on how make them a ritual.

This article is part of my Personal Retrospective Series – so read the other articles, if you want to learn more about personal retrospectives.

Why creating a ritual?

You might have noticed that it is fairly easy to notice mistakes of other people. But it is very hard to notice mistakes you made yourself. After all, you probably would have avoided the mistake in the first place if you knew, right?

Detecting own mistakes requires reflection. And as such, reflection is not something which is natural to human kind. So if you want to do reflection to learn from yourself, you can give yourself some support by creating a ritual: your personal retrospective.

It is not a coincidence, that the first section in the introduction chapter of “Project Retrospectives - A Handbook for Team Reviews” is named “The Need for a Ritual”. A ritual helps teams as well as individuals to acknowledge that this is a special time.

Your personal retrospective is something special: You are spending time just with yourself to improve yourself. The ritual character helps you to get in this “Retrospective Mode”.  It gives your retrospective the necessary structure and meaning.

Preparations

There are a bunch of things I do before going into the retrospective, which help to create the ritual and make the retrospective productive. I noticed over time, that my retrospectives are more effective the more careful I plan them.

Enough Time

The most obvious and maybe hardest part is to plan enough time. It is essential to have the time in my schedule - because than I can start with other preparations.

For a year-end retrospective I need about four to six hours time. I usually try to have the day free from anything except the retrospective. This helps me to focus on the retrospective rather than rushing through it, because I need to be somewhere else afterwards.

Material and Environment

The next thing I make sure is to have the right material and prepare environment for the retrospective. This includes a few things:

• A space were I can be uninterrupted.
• A room and table different than my usual desk to stress the fact that I’m doing something special.
• Paper and coloured crayons so I can express my thoughts on paper and in color.
• Other writing equipment like ruler, whiteouts, pencils and an eraser.

Prepare Snacks & Drinks

If I do the retrospective for four hours or more, I certainly need something to drink. And having nice snacks available is an easy way to make myself more comfortable. So I select something special I usually don’t buy. This is a reward to myself for taking the time to do the retrospective.

No Interruptions

Minutes before I start the retrospective I make sure, nothing will pull my focus from it. So I switch off my phones and make sure nobody needs something from me for the time being. If I use a computer for the retrospective, I also make sure everything which issues notifications or is otherwise suspicious of pulling away my attention is turned off.

Now I’m all set for the retrospective.

Ritual Supporting Exercises

I do a few personal retrospective exercises supporting the ritual. They are:

Music

Every ritual has a clear start and a clear end. For example in Christian marriages, the ritual starts with the bride walking into the church (with her father) and it ends with the bride walking out of the church (now with her newly acquired husband).

To start my personal retrospective ritual I have music. I have a special starting song and I have a special ending song. They are the same since I do retrospectives. This makes it both consciously and sub-consciously obvious when the retrospective starts and when the retrospective ends. The lyrics of the ending song have a very strong impact on me, as they support the execution of decisions I made in the retrospective. The starting song is just a non-vocal song I like.

This exercise is very helpful because I can apply it very easily even in the short weekly heartbeat retrospectives.

A letter to myself

At the end of a quarter or yearly personal retrospective I summarise my insights gained in the retrospective and my wishes for the next period in a letter to myself. This helps me to debrief and end the retrospective. Also, it is kind of a micro retrospective of how the retrospective itself went this time.

It helps me to create the ritual the next time, because the first thing I do the next time is reading this very letter. This creates a nice continuum from the last retrospective to this retrospective.

The exercise is stronger than the music exercise because writing a letter to myself is not happening as often as listening to music. I do it on longer term retrospectives, because for a heartbeat retrospective it would take too much time.

Summary

As you can see, there are a few things I do to create a ritual. They have developed themselves more or less unplanned over the time I practiced personal retrospectives. As you can see it is not rocket science.

What do you think? Would this work for you? Do you do other things to create a ritual for your personal retrospective?

]]> 2012-03-30T10:15:50+00:00 http://blog.jthoenes.net/2012/03/30/prime-directive-of-a-personal-retrospective

In this article, I will write about the directives or rules you should put in place for yourself while doing a personal retrospective. This article is part of my Personal Retrospective Series - so read the other articles, if you want to learn more about personal retrospectives.

Norman Kerth Prime Directive

Norman Kerth - the author of “Project Retrospectives: A Handbook for Team Reviews” - formulated the following prime directive for retrospectives:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

This is true for team retrospectives. But it is true for your personal retrospective as well. I did adapt this directive a little bit for my personal retrospective. You can and should adapt it, too. A personal retrospective is your personal thing.

However, you should keep in mind, that a personal retrospective is not about blaming yourself, just like project or team retrospectives are not about blaming others.

This is hard, because we (or at least I) get easy in the mode of blaming ourselves. But by doing the retrospective, you need to accept that you cannot change the past. You will analyse it. And you will learn from it.

An example

So let me make an example. Let’s say I failed an exam - how would I treat this in a personal retrospective?

• “Why did I fail the exam?”  - “Because I did not learn enough.”
• “Why didn’t I learn enough?” - “Because I was lazy.”
• “Why were I lazy?” - “Because I felt exhausted.”
• “Why were you exhausted?” - “Because before I was doing  XYZ.”
• (And so on ….)

The key here is to break the circle of blaming yourself. Especially when it comes to “I am to lazy” - which could be something other people might have said about you. Don’t fall into that trap! Nobody is harming himself and his goals on purpose.

As you can see, being positive about what you did does not mean you shy away from problems. You need to tackle problems. But to tackle them, you have to understand why the problem occured. You need to find the reason why you acted in some way. And than you can think about strategies, how to tackle the problems. Tackling might mean, to change things - or to stop expecting to much from yourself.

How to live Prime Directive

So, how do you make sure you really follow the prime directive in your retrospective?

The first step is to accept intellectually, that the this prime directive is the right strategy. You can do this by reading this article, as well as other resources on project and personal retrospectives.

If you have accepted it, the next step is to get it into your heart during the personal retrospective. I do this in two ways:

• By calling it into mind during the retrospective. I do it by reading the prime directive aloud before the retrospective to myself. Or I write it on a paper and keep it visible during the whole retrospective. You could use other means, like writing it down every retrospectives or anything which is appropriate for you.
• By experience you can convince yourself. If you practice the “the best you can” strategy as outlined in the example long enough, you may learn and therefore start to believe it. At least it worked for me. I found out, that  there is always a way to explain my actions afterwards - even if they seem strage at  the time.

Were can you learn more?

This article is the part of my Personal Retrospectives Series. I was strongly influence by other people – look at the Further Material section to find out more.

]]>