In my work, where I serve multiple software development teams as their coach and manager, one of the most important aspects in the performance of a team are the team dynamics. Something hard to grasp but when a team manages to hit that sweet spot of collaboration together they can accomplish things that seem impossible from an outsiders perspective.
But reaching that point of ultimate collaboration and performance does not come easy. A team will run into several obstacles along the way that they will need to overcome. The very first thing for a team to tackle would be to learn the collective team capabilities and a common understanding of the current situation and how to improve it. Without that there is merely a group of individuals with their own individual capabilities and understanding of the work that needs to be done.
I have often seen teams struggling with this and one part of my role is of course to help them overcome this hurdle. Quite recently I got confronted with a similar situation in my own life. Not in a work related context but during something completely different and I would like to share this story with the readers of this blog.
The Daily Scrum is probably one of the most well known Scrum “ceremonies”, often it is the first agile practice that is adopted by teams and sometimes even the only one.
Unfortunately the Daily Scrum is also an event of which teams can easily forget what the reason is to take the time each day to go through it. Quite often it becomes a practice which is conducted out of habit, without the actual intention of it in mind.
However, when done right, the Daily Scrum is one of the most powerful practices in the Scrum methodology. I have written a blog post on the Mendix blog about the Daily Scrum, to read the full article, click here.
Everybody knows them, the heroes in the organization. They are the ones that know all the ins and outs of the product, architecture, frameworks, infrastructure and the cleaning lady’s schedule. They are the ones that stay late to finish the last tasks before the sprint ends, that refactor the code in the middle of the night and that have worked over night to fix that critical bug.
The hero is often put on a pedestal, protected, worshipped and treated very carefully knowing that if they leave, the entire company will collapse. Almost nobody considers that the hero is actually a big impediment in the organisation, a risk and definitely a situation to avoid.
Now what is so bad about having a hero that always saves the day? Especially in an agile environment the hero is one of the most dangerous impediments to have:
- Having a hero makes you company depending on one single person. What if this person goes on holiday, gets sick or leaves the company. This makes your company vulnerable and puts the hero into a position in which he or she can demand everything.
- In agile environments the hero undermines the self organization of your team. As soon as people have the feeling that the company sees a person as the hero within that company, they will start acting accordingly, accepting his estimates, never questioning his opinion and definitely not challenging him. The level of the hero will automatically become the limitation you won’t get past.
- The hero will put unhealthy pressure on people. What will the rest of the team do when the hero ignores the sustainable pace and works in the evening and in the night? Most likely they will feel obliged to do the same, putting them in a difficult position.
- The hero will hurt his / her peers self confidence. Imagine that you are a team member in an agile team. Now imagine that you log in in the morning and find your code modified or that task that you just picked up already finished.
- Heroes tend to be egoistic. There is a very unlikely chance that when working during the night, our hero picks up the less fun tasks from the taskboard.
- Your hero will chase people away. Heroes tend to achieve a position that is untouchable and unquestionable. Either people will accept that or people will walk away. Usually the people that will walk away are the ones that you would like to keep.
A lot of managers have the tendency to look for hero’s, often called key personnel. In my opinion having just a few people as key personnel is a flaw and a clear sign of bad leadership. Everybody in your organisation is key personnel. Creating a structure in which certain people are allowed to achieve the hero status is setting your organization up for a big problem, possibly even threatening the existence of the organization.
Good leaders create an environment where the team as a whole is valued and appreciated, not just a few individuals.
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.