Recently I got interested in using LEGO for professional purposes and have tried it out to see how it can help to get the unspoken subjects from our retrospectives to the surface. In this blog post I will try to describe the why, when and how of this experiment.
First of all I can imagine that people are wondering how I got this idea to let my team members play with LEGO, at least the team members that were asked to play with LEGO wondered about this.
While I was at the agile coach camp in the Netherlands at the end of April I got inspired by a man called Thorsten O. Kalnin (you can visit his website at http://vinylbaustein.net/). The first moment I met him was during the lightning talks on the first evening and he was talking about LEGO. Which to me did not seem like the most relevant topic for an event for agile coaches, but Thorsten is a very energetic and convincing personality and his track record with agile teams speaks for itself so I thought “OK, LEGO, let’s see where this is going.”
No clue what to expect I went to one of his sessions. Unfortunately I did not go to the actual LEGO serious play session that he hosted but I went to the SCRUM training which he had entirely based around LEGO building exercises. I was definitely not the only one that was interested in this since almost every participant of the agile coach camp was there at that session. Of course being all agile coaches we easily successfully completed the training, which is what we as agile experts had all expected. Reality was however a bit different and we failed dramatically to deliver any useful business value. Nevertheless, the use of LEGO for professional purposes had my attention from there on.
When I returned from the agile coach camp I started researching the internet for information about LEGO serious play. And actually found that LEGO itself is promoting this use of their toys (http://www.seriousplay.com/). Next to that I also found an interesting article on the agileminds blog about using it for a retrospective (http://agilemindsblog.wordpress.com/2011/03/04/lego-%C2%AE-serious-play-%C2%AE-for-retrospectives/) which made me begin to think on using it for a retrospective as well.
Since May 2010 I have been working with agile development in combination with a near shore team in Ukraine so I guess I can say that I am somewhat experienced in managing distributed teams. All the issues encountered during these first two years have triggered me to write this post.
Ok, first of all to prevent myself from mentioning near shore and off shore development a zillion times in this post I will just refer to it as near shore development but everything applies to both.
Is Agile suitable for near shore development?
Many people working with agile methodologies always debate about the question if agile is suitable for near shore development teams. The real purists often comment that teams should be co located, which is of course the biggest problem when you work with near shore teams. And besides that, there are always numerous of small problems such as language, culture and time zone differences that make people doubt if a methodology that relies heavily on collaboration and communication, like agile methodologies do, can succeed in such an environment.
During a retrospective a while ago I asked the team “What can I do so that you can do your work better?”.
Initially people did not really know what to say and came up with some small suggestions . These were still good suggestions but not quite what I was looking for. Until a few days later one of the team members suggested “If you want to know in which area to coach us, how about joining us as a developer for a sprint”.
I immediately liked the idea. I have been working as a developer for this same company in the past so the technology they use is not completely new for me, but still I see it as a huge challenge. The last time I did some considerate amount of coding (apart from some pet projects) was about 5 years ago, since then I have been involved in management related roles. So my coding skills are probably a bit rusty.
Nevertheless I feel flattered that the team asked me to do this, so at the start of the next release (in a few weeks) I will be putting my management hat aside for a moment and will wear the developer hat for a sprint.
To make it even more interesting and useful I have thought of the idea to be at the office in L’viv with our Ukrainian team members for the full length of this sprint.
I am totally psyched about this plan and plan to hit the ground running so my team members will need to brace themselves because they will get the most motivated team member they have ever seen!
I will be keeping a journal about this experience so keep an eye out for it on this blog or my twitter account :).
While writing this blog post I am in a restaurant in the Vienna airport killing time until my next flight to L’viv will depart.
The reason why I am going to L’viv is to pay one of my regular visits to the near shore development company from which we hire a number of developers for our teams. I will be staying in L’viv to conduct job review meetings, job interviews with new candidates and of course socializing with our Ukrainian employees.
The last time that I visited this company there was a company wide meeting about their CMMI level 3 implementation. One of the procedures they were discussing during this meeting is that all teams, regardless of the project, technology or team members will use the same development process and practices up to details like using pair programming or not. This is quite the opposite of how I think an agile organization should be run.
In agile development methodologies user stories are a common way of capturing requirements that need to be implemented by the development teams.
In my opinion user stories are a very good way to describe functionality from a user perspective, there is however one big pitfall that people always fall into with open eyes (time after time).
The biggest mistake you can make with a user story is to see it as as static description of functionality, basically a small part of a design. This is definitely not how user stories were intended. A user story is an element on the product backlog that evolves over time. It’s alive… It’s alive…
User stories are often referred to as Card Conversation Confirmation (Jeffries 2001).
- Card; The basics of a user story should be small enough to be written on a card or sticky note. Within one sentence you should be able to describe the functionality that is requested.
- Conversation; The most important role of a user story is to trigger conversation. A user story is not complete, it represents a customers’ requirements but it does not document them. Team members, product owners and stakeholders should always keep that in mind. The story is there to get people talking, not to provide a “design” (damn I said the D word).
- Confirmation; Even though conversation is the most important factor of a user story, it does not mean that the results of the conversation should not be stored in any way. The outcome of discussions related to a user story should be added as acceptance criteria, development notes, attachments, etc to the user story.
Ok this is all very interesting but you are probably thinking “I can find this in any wikipedia article or agile related book, but how does this actually work”. And you are absolutely right about this so let’s look at an example of how a user story progresses through an agile development process.
I spend a lot of time being in L’viv with our employees that are working from there. While I am there I spend quite some time in inspiring environments.
Even though their office space is not the best of all places it is still quite an inspiring place. Everywhere you see people working together, there is music playing in the kitchen, there is a fish tank, a wall of fame (or shame depending on how you look at it), there are people playing foosball together and you can see that people have spent attention to their working place since most of them have some personal things on their work place such as pictures, etc. Basically it is a lively place where you see good things happening regarding human interaction combined with work.
Next to the working environment and the people that are working there I also experience the hotel, in which I am usually staying while I am in L’viv, as a comfortable place which brings out the best in me. Usually the best ideas that I have surfaced while I was enjoying a relaxing evening in this hotel after a though working day.
And last but not least the face to face work related conversations with the employees and also the CEO of this company always motivate me to find even better ways to manage these teams and get even more out of them.
Today I was driving home after a two day Certified SCRUM Product Owner training. During this two day training I met a lot of new people, people who were unlike me, completely new to SCRUM. In the discussions and the questions that they had I recognized a lot of situations I encountered when starting with SCRUM. I heard a lot of comments like “Our organization just won’t work that way” or “It all sounds nice but won’t work in reality.”
While driving home I was thinking about how I got first introduced to SCRUM and what my first responses were.
In 2006 I was working for one of the top 3 internet development companies in The Netherlands. The company was working in a very traditional way. First concept & design would create the look and feel for the web project, then information analysts would create the functional design. After the functional design was completed the software architect would create a technical design and after completing that, the developers would start working for several months to complete the functionality and then the test coordinator could let his team test everything. My role in this entire process was to be the information analyst who writes the functional design.
The development teams that I work with are either fully or party located in Lviv (Ukraine). This brings some challenges in managing these teams since all meetings require some form of video conference and information sharing. For the review, grooming, planning and daily standup meetings this was relatively easily solved with a simple form of screen sharing of our SCRUM tooling (VersionOne). However for the retrospecitve meetings we faced an interesting challenge.
I like to run retrospective meetings in an interactive way. When the team is completely located in a single location I let people put sticky notes with ideas and comments on a whiteboard and use dot voting to determine what the biggest problems are or what suggestion should be implemented first. When starting to work with a team that is partly in The Netherlands (4 team members) and partly in Lviv (5 team members) we needed some way to put this process in a software tool. VersionOne did not contain sufficient functionality for this so I had to start looking for another solutions and this proved to be a bigger challenge than I expected.
My search initially lead to no results and when the first retrospective meeting with a separated team aproached I had no clue on which tooling to use for it. Eventually I ended up on the website of twiddla (http://www.twiddla.com/). Twiddla is a web based shared whiteboard that also provides the possibility to add sticky notes to the whiteboard. In our retrospective meeting we used two computers, one in Lviv (Ukraine) and one in Wassenaar (The Netherlands) both were logged in to a shared whiteboard of twiddla.
People would add sticky notes with their comments to the whiteboard, after all notes were put on the whiteboard the team members would cluster their notes and then it was time to start voting to determine which items were most important. Unfortunately the only solution I was able to find for this is to draw marks on the sticky notes with the line tool of twiddla. All in all it worked and allowed us to perform the retrospective meeting, however I will be looking into other tools that hopefully suit our process better. Any suggestions are appreciated.