The scope was quite large so I couldn’t use any specific way of gathering information and insights. I had to allow room for a very wide variety of topics.

Without further ado here is the skeleton I used for the retrospective.

1. Get a mood reading (max 5min)
2. Gather insights (max 10min)
3. Decide what to do (max 35min)
4. Form an improvement backlog (max 5min)
5. End with a different goal in mind (max 5min)

Getting a mood reading

I wanted to know and I wanted the participants to know what are the prejudices we are working with. I used the EVSP (Explorer-Shopper-Vacationer-Prisoner) as the ice breaker. With a closed vote everyone wrote down a single letter defining their current attitude towards retrospectives at the moment. Here are the results:

Getting something to chew on

Then it was time to move forward and start to gather information to support our aims. Due to the amount of issues known in advance I decided to include last two sprints (we have 2 week sprints) in our time-line exercise. I had two different coloured sticky notes: green ones to signify memorable events and yellow ones to signify meaningful events. Time-line itself was very simple with only two dimensions: time and impact. Time runs from left to right and impact from top to bottom. The higher the note was placed the better the event was and the lower it was placed the worse the event was.

In small groups, 2 or 3 persons, people started and recalled the most important moments and placed them properly on the whiteboard with respect to both the time axis and the Good-Bad axis.

Now we had something real and concrete to work with.

Morphing events into concrete form

After we had looked into our near past it was time to turn the history into actionable issues. I had prepared one whiteboard with three columns: Stop Doing, Start doing and Keep Doing. I told the team to use the info we just had gathered and by themselves write sticky notes containing issues that mattered to them. I instructed them to keep the notes secret until placed on the whiteboard. The notes were placed one at a time so that we could discuss each and every note immediately.

Ta-daa! We had concrete issues we could address! Next I lead the team to find themes within the notes. You can see the notes that address the same issue connected on the image. This proved to be extremely fruitful and good discussion and analysis followed.

Then it was time to create our improvement backlog. I gave the team 5 minutes to create actions based on the discussions and notes on the three columns.

If you look closely, on the right corner of the image you can see a bunch of red notes. Those notes are the actions that the team found. They are prioritized based on importance and effort required. Effort is significant here, very often the actions are such that the team can not accomplish them alone. Thus, it is very important to have actions that can be implemented immediately.

Ending the show

We had found really good candidates for the team to improve on and it was time to move on. We’ve had all kinds of retrospectives from good to bad to boring so it was appropriate to give the team a possibility to improve on the retrospectives. So, the last item was retrospective process improvement, what is good and what needs to be changed.

Got some very good feedback, ideas and improvement suggestions :)

Required ingredients?

1. Preparations in advance
2. Storyline sketched
3. Neutral facilitator
4. Fearless people

I had prepared the team room in advance, 2 whiteboards and 2 large paper sheets, enough sticky notes and pens/markers. Timer for timekeeping and enforcing time-boxes. Healthy attitude so that I could leave myself out of the retrospective even though I am a team member. Gentle guidance to allow everyone the chance to speak up.

I was pleasantly surprised how well this went and I want to thank my team for excellent attitude and a sincere desire to improve and discuss even the most difficult subjects. There’s definitely improvement ahead!

None of this would have been possible without the help of the excellent book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. I recommend it for everyone interested in retrospectives.

I posit that this is a dangerous for a couple of reasons.

Too tight focus

In my experience it is very hard to make corrective actions while in the zone. The Zone has the same effect as speeding, your sight narrows and with high enough speed you can see only forward. How do you verify that you are solving the correct problem? Are you really going to the right direction? Are you sure? When in “The Zone” do you ever stop and wonder “Is this the right thing to do?”. Do you ever question the task at hand? Is this really the most valuable feature? Could there be something that would provide even more value?

The Zone is a state of extreme focus and motivation. The problem is that your focus is very likely too sharp. This leads to blindness to your own errors and makes it really hard to change direction. This leads to false productivity as the risk of rework grows very fast. With great speeds even the slightest mistake become huge almost intantly. Think about a steering error while driving over 200km/h.

Susceptible for interruptions

“The Zone” is fragile. Even the slightest disruption, an email, innocent short question from a colleague, can drop you out of it. Getting back is difficult so your productivity is going up and down very frequently. This can be really frustrating and a real motivation killer in the long run, especially when you consider the nature of software development which emphasizes team work and continuous communication.

You may have your own private room you can hide in but is it smart to shut out others? If everyone is locked up in their rooms what does it do to your team spirit? Privacy is ok and should be respected but isolation is not. With people spread out in their rooms how can you ensure that you are all pulling the same rope and in the same direction? Which leads us to the next pitfall.

Silos

Everything that is done alone encourages silos. It is always harder to spread knowledge afterwards. Spend too long on one task and you become the sole source of information. In other words a single point of failure.

Isolating yourself to ensure uninterrupted “zone” prevents you from learning from others, gaining information from others and spreading your knowledge to others. Silos prevent sharing the code and the code wants to be shared. In other words you have too long feedback loops.

Too long feedback loops

While in “The Zone” you are alone. Very alone. How can you be sure that you are doing the smartest possible thing? Is it the right thing to do? You practice TDD so technically you are on the right path but logically? Have you been derailed from your original goal? When is your next code review? Can you afford to wait that long? Are you sure that your domain knowledge is deep enough? While you worked in the zone and progressed did it actually move you forward in the right direction?

What if you had understood something incorrectly? Depending on the size of your task this can mean all you have delivered was waste (excluding your own learning). Did you write too much code? Did you try to anticipate the future?

The antidote

You can overcome some of the issues of the zone by ensuring frequent communication with the business and making sure that all tasks are small enough in order to shorten the feedback loop. This still leaves you in a more fragile state than we would want.

But there exists a very effective practice that renders the negative aspects of the zone very close to non-existent.

Pair programming.

Pairing

In psychology terms “The Zone” sounds like flow. Flow is described as a state of focus, motivation and productivity. I want to make a semantic difference between these two states and add negative connotation to “The Zone” and positive connotation to “The Flow”.

Pairing gets you into a flow fast and it is easy to stay in the flow!

Pairing gives you enough focus but it isn’t too tight. It’s like having someone to read the map to you while driving to an unknown location for the first time. And it beats the GPS and other map utilities hands down. You always have someone there to question your train of thoughts, helping you to take the right exit or turn and to stop when it is time to stop.

While pairing interruptions don’t cost even nearly as much as they while in the zone. The pair can very quickly regroup and maintain their momentum. You can momentarily split up and continue after the interruption has been dealt with.

You can’t hide information while pairing and you can’t become a silo. You will learn, teach and gain information while pairing.

Pairing while programming gives you a feedback loop of seconds. Your thoughts are evaluated as soon as you articulate them. And articulating your problems is the best way to solve them.

Don’t keep zoning, start pairing

It can mean that we should keep things in the open, no secrets or that our doings are audited and we can back-trace them every time we need or want to. In other words, saying that there is not enough transparency means that there is not enough trust. Sometimes the word transparency is used masking the desire to know what is going on.

Demanding more transparency smells a lot like green-washed management. Instead of saying “Keep me posted on whatever you do!”, require transparency. I say it is just a management intent in a disguise!

Thus transparency is attached with a bad echo. Especially if the people involved are not co-located or there are no clear backlogs for work. The person demanding transparency wants to gain assurance that everything is going as planned. This leads to micromanagement and reporting.

In other words, there is not enough trust.

Sometimes the word ‘transparency’ is used to replace the word visibility though. Using it this way is in my opinion harmful because it is very easy to confuse with the previously mentioned management-loaded term. Avoid it.

There are at least two ways out of these situations. One is to increase the visibility, especially if people are co-located, to increase communication. The other way is to build up the trust. Trust that the other party is doing her best.

I’d like give huge thanks to the organising posse for trusting me with a slot! This will be the first time for me to speak in a conference. It’s quite funny since I have participated in exactly one conference, the one that I was organizing.

My presentation is still very much in its infancy, but the topic is quite clear. I will be speaking about software craftsmanship. It’s very important topic for me and I want to share my ideas what it means in practice and what are its consequences. It will be a 45 minute presentation so I will have or should have enough time to consider the topic from multiple angles.

The conference main site is here.

I’m in a team of four very experienced and smart people, we have a product owner who is tech-savvy, knows what he wants and sits in our team room! On top of that we have an excellent room where single every wall is covered with material that you can pin stuff into. We have been given control over our tools and we are given a lot of trust (which is as it should be ;) ). We agreed to start with kanban as our development process and that made me extremely glad since I haven’t been able participate in a real kanban project yet!

We are now roughly two weeks into our green-field project. We started out with a simple three swim lane kanban-board where one swim lane is for product backlog stories, one lane for team stuff (environment, tooling, etc.) and one lane for the PO. Almost all work flow states have a WIP limit of 2, one has a limit of 4. At any time only two user stories can be under work. your basic kanban stuff.

We have the categorised the product backlog stories and pinned them on the wall. They form a vague big cloud, a chunk of things, that we are supposed to make. And this chunk is annoying since it does not provide a coherent vision, idea or goal for the team. Well, of course the goal is make the whole product, but that doesn’t really help in daily work. The team needs a short-term goal and a vision to support its work. The vision could be described as an epic, a collection of stories. Simply put, we need to know where to aim at on a shorter time interval. Our initial kanban board didn’t give this vision but our PO had already defined it and written it down on one of our whiteboards. So it was there for us but it wasn’t part of our kanban board. How could we incorporate it with our board?

I devised a kind of a funnel, a new stage if you will. Epics are pulled from the Big Cloud and placed into a funnel. It will be the teams goal and provide a clear path for us to work with. The contents of an epic are coherent and we can easily see, for example,  interdependencies between stories. It is also extremely useful when we manage to get some data about our lead time to help us estimate when a certain product increment is ready. This can then be conveyed to the stakeholders and business people. We can estimate and tell them when to expect a set of features instead of the whole product or just a single story.

To put it short, we now have three stages in our kanban wall. From the backlog cloud the PO can envision an epic for the team that will guide us to the next composition of increments. From the epic stage we pull stories to the kanban board for the teams daily work.

To some of you this may feel like we are aspiring for things that Scrum gives you out of the box. Well, we are but rather than restricting us with Scrum we are doing things that we feel benefit us and our stakeholders. We have retrospectives, we are going to show (or demo) what we have achieved and we are going to estimate the big chunk of stories. But we do an activity only if it will bring value. For example, if there is no value in estimating the backlog, we won’t do it. But we are going to try things that are deemed valuable either by the team or the stakeholders. And remember that the epic can be withdrawn at any time as it is not taken under work, we still do work only on story level!

I am eagerly waiting how the process will evolve and what is the direction it will evolve?

(picture by cantoni)

stole the boot sector. Some issues with stability though, most likely due to NVidia drivers, which were at least partly solved by installing nvidia-current and running nvidia-xconfig and nvidia-settings as root. So far this has been the best work setup I’ve ever had, plenty of memory and CPU power, the OS I want and no prohibiting policies or idiotic restrictions. Just the way it should be. Anyway, had to make some loops to get Adobe AIR installed so that I could install Tweetdeck (sigh.). Skype was fortunately a painless installation.

Albeit slightly annoying, the tech issues are become fun in the end and after some struggles it was a joy to join again the Nitor irc-channels. So many like-minded geeks there (I was at the office, others were at the customer sites). And immediately there was a  debate about mocks and unit test quality, just the way I like it. Smart people with different views, ideas and wide experience provides very fertile ground for tough discussions and a good place to test ones ideas. And a very supportive group it is. Everyone willing to help the new guy.

I think I’m gonna like this place a lot!

Anyway, suddenly I found myself browsing the Netty documentation. I’ve always had a secret crush with IO so with a little free time in my hands it was a perfect opportunity to explore Netty. Thus, my journey to 7 languages was turned into 7 languages and one framework as I wrote a very crude chat command line application using Netty.

Netty provides very good documentation and the chat app was up and running in very short time. The biggest obstacle was actually generating an executable jar file with dependencies using maven. And even that was solved in less than 10 minutes. So, Netty seems to be an excellent asynchronous, event-driven network application framework. I hope that I could use it for some serious coding @ work!

Now that I’m derailing once again form my original plans, I may have to come up with more strict wip limits for my journey so that I can actually move forward into the direction I want to instead of jumping around everything that seems even remotely interesting.

There was something about Ruby that intrigues me so I convinced myself that I must do something with it. And the easiest and maybe obvious choice was Ruby on Rails and a web application. I’ve heard that it does amazing things to developer productivity so I might as well give it a shot. Now, I’ve had an idea for sometime about a very simple browser based utility which I actually might try to implement now with RoR.

Of course I will enhance my Robot Framework skills by trying do this web app in true ATDD style. Starting with one user story, writing a Robot test for it, running the Robot test and seeing it fail and only then starting to think how on earth am I going to implement this thing with Ruby and more specifically how do implement it doing TDD with Ruby (or should I try BDD with RSpec)?

I will get back on track with Io as soon as I find the strength in me to spoonfeed the compiler and to satisfy the linker…

I found pp, a pretty printer for Ruby data structures, lot in vein of Perl’s Data::Dumper. It is not as good at first glance but my experience with is still in its infancy.

The idea of open classes is marvelous although it requires some discipline from the developer since dynamic typing allows the usage of methods and functionality that might be defined somewhere else. The compiler really can’t know it yet. Improper usage will result in run-time errors. This is one of the major drawbacks of ducktyping. It gives you freedom but with that freedom comes responsibility. Don’t ignore it.

I fiddled a little with modules, mixing functionality into other classes. This is one of the experiments

module Tweetify
  def tweet(str)
    puts "[Tweet!] " + str
  end
end
 
class Speaker
  include Tweetify
  attr_accessor :voice, :s
 
  def initialize(voice)
    @voice = voice
    @s = {
      'loud' => lambda { |str| puts str.upcase! },
      'low' => lambda { |str| puts "[shhh!] " + str.downcase! },
      'default' => lambda { |str| puts str }
    }
  end
 
  def speak(what)
    @s[@voice].call(what)
  end
end
 
s = Speaker.new("loud")
s.tweet("twit twit")
s.speak("am I yelling?")
s.voice = "low"
s.speak("I SHOULD BE WHISPERING NOW")

I learned through a struggle that instance variables must be initialized within a method, otherwise their content is lost. Or I just don’t know the intricacies of Ruby well enough. Overall the books Ruby exercises are good. Exercises touch the parts that Ruby is good at. Something more difficult could be useful and something to be done from the scratch instead of extending the books code snippets.

Now it is time to move forward to the next language (io!) but I would love to stay with Ruby a little longer. I just may have to find something for my own pleasure. Stay tuned!