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.
Much too often people end up in a static state in their work. They might do their job and maybe even do it very well to the needs of the company for which they are working but a lot of people don’t develop themselves anymore.
To be able to develop yourself you need to step out of your comfort zone. It is comparable to physical training. It doesn’t matter if you are training for a world record on the marathon or just want to extend your weekly recreational run from 5km to 6km. If an athlete will run a marathon at the exact same pace as he is used to, he will probably never be able to break the record that he wants. He will need to stretch beyond the capabilities of his current strength and stamina to achieve what he wants to achieve. This will hurt in the beginning, but will make him stronger and achieve his goal faster.
Self development of people in their line of work works in a similar fashion. The best way to develop yourself is to step out of your comfort zone and use tools, technologies or approaches that you are not used to. Just as with physical exercise it will hurt and initially you will probably do your work slower compared to how it would be when staying in that nice comfort zone. And there is even the risk of not being able to complete your work at all because your experiment dit not work out the way you wanted it. But in the end, you will have learned and you have improved yourself.
So as a manager which people do you want? Which people will bring your company further? The people that will stay safely in their comfort zone, or the people that will take a risk from time to time? The second group of people will definitely make some of your iterations fail, but in the end they will also realize the improvements that your company needs to gain an edge of your competition.
Managers often talk about a phenomenon called team building. This insinuates that you can actually “build” a team and simply put a number of individual people together and expect them to work together as an optimal performing team.
Well let’s just burst that bubble, there is no such thing as team building, a team can only be created by growing it and nurturing it step by step through the forming phases of a team until it reaches the level needed to unleash the full potential.
As a team manager you need to work the system to create the best possible environment for the team, invest in and coach the team members to help them to develop themselves and the team. In this aspect you can compare a manager with a gardener who tries to create the best environment to let the plants and flowers grow to get that award winning garden.
To get the most out of a team, a team should be an entity within an organization that has its own identity including a name, goals, values, metrics etc. In essence it is an organizational unit on its own.
This also means that you cannot just create a team for projects that you encounter and tear the team up again when the project is over. Organizations use short lived teams like this a lot because they assume that people in an organization are just a big pool of resources that you can use to populate project teams with.
But let´s be realistic, will a short lived team ever be reaching their full potential? Most likely they won’t. A team needs to get used to each other, needs to grow, needs to develop an identity and then needs to learn from each iteration to improve as a team. A team that is going to be ripped apart after just a few months is never going to be motivated to develop the team, most development efforts will be individual, because in organizations like this it is the individual that counts and not the team, teams are just temporary groups of individuals.
If you want to reap the full benefits of being agile you will need to find a way to create and develop teams as multi disciplinary self organized units within your organization that can handle your projects instead of just looking for the individuals with the skill sets that match the requirements of your project.
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 :).
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.
When the multiple disciplines in software development such as design, development and testing were working completely separated from each other the most important task of a manager was to get people that are exceptionally skilled in their specialism. As long as a person was skilled in his own area of work a lack of the so called soft skills (teamwork, communication, etc) could mostly be overcome. The project manager was responsible to provide the communication within a team and it was his or her role to make sure that information from one specialist was transferred to the other.
This resulted in a controlled environment for all people in the different disciplines. Developers only needed to communicate with other developers, designers only communicated with other designers and the management communicated the artifacts from one discipline to the other and to the customers.
Even though it was still no easy task, life of a recruiter must have been much easier back then.
The introduction of agile changed the entire playing ground. Technical skills are low on the priority list when recruiting for agile teams. Suddenly developers need to communicate to testers, documentation specialist and UX specialists and vice versa. And if that is not enough they actually need to communicate with the customer as well. Add to that the need for a team to be self organizing and multidisciplinary and we end up in a recruiters worst nightmare.
As a manager of several development teams I often need to make a decision about hiring a new team member for one of our SCRUM teams. For me the following criteria are most important in making the decision to add someone to an agile software development team, in order of importance: