So I claim to be a Stoosian. I already hear all of you thinking “What the …. is a stoosian?!”. Well to explain that I will first have to explain what Stoos is.
In January 2012 a group of 21 people gathered together in a Swiss ski resort in a small place called Stoos. This group of people consisted of the major thought leaders on management practices, being:
- Catherine Louis
- Deborah Hartmann Preuss
- Esther Derby
- Franz Röösli
- Jay Cross
- John Styffe
- Jonas Vonlanthen
- Julian Birkinshaw
- Jurgen Appelo
- Kati Vilkki
- Klaus Leopold
- Melina McKim
- Michael Spayd
- Peter Hundermark
- Peter Stevens
- Rod Collins
- Roy Osherove
- Sanjiv Augustine
- Simon Roberts
- Steve Denning
- Uli Loth
In each profession there has always been the urge from management to measure the productivity of employees and software development is not different in that. Over the 12 years that I am professionally involved in software development I have seen different attempts to measure teams or individuals on their performance in:
- Lines of code produced
- Bugs solved
- Bugs created
- Amount of features completed
- Hours worked
I totally understand that management wants to measure teams but the first thing to ask yourself is what you really want to know. All too often teams or individuals are measured on metrics because those are the metrics that they can measure and not the metrics that they need to measure.
Going after the metrics that can be measured instead of the metrics that should be measured usually results in measuring things that the team(s) see as a burden instead of something that can help them. The result of this is quite often that the team starts gaming the metrics which results in even less useful information from these metrics.
To measure what actually matters you will have to start with the basics and the basic measurement for teams should be the happiness of the employees that work in the team and the happiness of the customer that works with the products that are delivered by the team.
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 :).
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.