Archive for category Teamwork

Things I’ve Learned, the Hard Way

Don’t Procrastinate

It’s always easy to leave things for later, but the consequences are almost always bad. Usually, there is no logical reason to defer anything, starting with simple things such as paying your bills, and ending with dealing with your project’s problems. They won’t just get solved by themselves, they are only going to get worse as time passes. What is more, there are for sure some people relying on you and waiting for you to finish, in order to be able to do their job. You owe these people to get your job done as soon and as well as you can.

Respect Your People

They’ve made it to this team thanks to their qualities and strengths. They have developed into experienced professionals, or they are just taking the first steps. Anyhow, they are the ones directly helping you do your job, and respect is one of the key factors in any good relationship.

Trust Them

There are two kinds of people. The ones thinking that trust is to be earned, and the others who trust people from the beginning, only to lose it if they get let down. I personally belong to the latter, but I find worth mentioning that trusting someone doesn’t mean being naive. You still have deadlines to meet, you still have to make sure your team is producing quality work, so there is a very thin line between being trusting and being too loose.

Don’t Lose Control

There is an old saying: Trust is good, control is better. You may be shocked to find out it belongs to no other than Joseph Stalin, but I consider this only proves that even villains can be pretty wise from time to time. Even if you are lucky to have competent people in your team, you still have to find non-intrusive ways of keeping track of your schedules and commitments. Thinking about that fine line again…

Don’t Micromanage

While being confronted with stressful situations or tight commitments, you can easily turn into a control freak. You may feel the need to know every aspect, every detail, in order to be able to have everything under control. Humans however, are not that “multi-threaded”, so they need to surround themselves with trustworthy and skilled people who they can rely on, rather than trying to squeeze every bit of information into their 20%-used brain.

Listen and Make Sure They Listen to You

You want to be constantly aware of your people’s needs and problems, while making sure they know your expectations. You have every reason in the world to be attentive while in meetings with your fellow leaders and managers, but also to be able to leave relieved that they all know your team’s status or your personal points of view, when the meeting is over. Finding the right ways to communicate is therefore crucial, and yet so different from one situation to another.

Never Wait

Leaders aren’t waiting, they’re acting. Being reactive, or even worse – passive, isn’t part of a leader’s job description. A good way to tell if you are being proactive enough is to ask yourself this question: Usually, when my manager asks me something, do I know the answer on the spot, or do I have to find it out? If you are always being told what to do, you probably aren’t much of a leader after all.

Be What You Want Them to Be

Being a leader means heaving people follow you. But if they find you worthy in any way, they will also borrow from your way of being, more or less consciously. Your behavior is therefore crucially determinative for their own, so unless you don’t want to be surrounded by jerks, make sure you’re not one. Unfortunately, negative behaviors are easy to imitate, but the good news is, positive things are also quite catchy.

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: , , , , , , , , ,

Burning Down the Reports

Burndown Chart

For years I have relied on different reports, pie-charts and graphs for tracking my team’s progress, as well as my own. I had filters for the tasks which were in progress, for the ones overdue, and for the ones assigned to myself. I had pie-charts rendering the bug count for each of the guys in my team, and also for each product component (architecture-wise). I used a graph that was telling me how many issues were created, in contrast to how many were resolved over a period of time.

But why…

Well, I guess we were driven to this kind of management by the way we used to work.
Our teams were built around the omniscient Team Lead figure, the one who had all the answers to any question, from anyone – “above” or “below”; the one who was reporting, and was being reported to. Each developer was focused on his or her components, not “needing” too much knowledge of others’, so the lead was playing a key role in keeping things together and working. Testing was perceived as a somewhat external job, as there was a completely separate team for that, with their own schedule, and their own way of doing things. The developers pretty much thought their job done as soon as the product of their work was delivered to the testers.
You have probably figured out by now, that the team leads had all the reasons in the world to make sure that they were aware of the detailed status, problems, and interdependencies with other teams, while still struggling to avoid doing micromanagement. Tough job.

This is exactly why we had to change something.

And we did. After countless attempts to correctly understand and adopt the Agile practices and principles, after reading many books, attending some conferences and trainings, and after having failed so many times, we have now finally come to a point where we’re doing things much different than before.

The all-knowing team leads turned into trusting scrum masters, relying on their people, who now need to work closely together to get the job done. The teams are now composed of both developers and testers, so everybody finally got on the same page. We don’t develop anything that can’t be tested right away, developers receive useful input from the testers just from the analysis and design phase, basically everyone works together from the start ’till the end. This doesn’t only happen inside a team, but to some extent, throughout the entire “big” team.

I still have my reports and pie charts, but I don’t recall when I’ve last checked any of them. Instead, we all use a continuously updated Burndown Chart. Not only it tells us how much work we have done, but most importantly, it tells how much we have left to do until we’re done. This also means that we can use it to tell whether we are able to finish everything we’ve planned, and also, what we are going to get done by the end of the sprint. Combined with the task board, containing cards for what’s to do, in progress and what is done, we’ve got all the information we need.

If anybody asks about progress, problems or status, anyone in the team can answer, because we’re all together in this. We are all estimating, planning, reestimating when needed, together, so we all know and care about what’s happening anytime.

And it’s all in one single chart.

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: , , , ,

When Democracy Fails

Science Laboratory

In a sane working environment, everyone seeks consense whenever decisions are to be taken, whether on minor or important matters. It is desirable for everyone involved to feel ok with the future plans, as it really helps not only for people’s morale, but also for getting things done.

Humans tend to be good at what they do if they do something they like. There are however cases when correct decisions can only be taken on – if you will – scientific grounds rather than their popularity. Consider, for example, the architectural redesign of a pretty large software application, which had evolved year to year into something difficult to debug, develop, or even understand. You will most probably organize technical meetings with the right people (not too many!), in order to figure out a solution. In those meetings, there is a significant possibility of rather different views to take shape. In such times, the handy approach would be to select the solution by voting, but it would be much preferable to do it by weighing the advantages and disadvantages of each alternative.

It may not please some for the moment, but in the long run, everyone will be happy to benefit from a wise, however not popular, decision.

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: , ,

All the Right Pieces

Cube Toy

Building a strong team usually relies on finding skilled people you can trust, each one of them bringing value to the whole, by their personal, unique strenghts and qualities. Once you succeed in this, it’s up to you to take the challenge of offering them the opportunities to develop their skills, enabling them to become trustful experts which you will always rely on, when being asked for estimations, plans or just plain technical oppinions.

In this context, thinking of them as replaceable only makes you set an artifficial barrier on the way of their personal and the team’s evolution. The only replaceable one should be you, as achieving this translates into a powerful, self-organizing and tightly bound team. You don’t have to be afraid of this, because your company will most probably see it as an act of performance; and if they don’t, you wouldn’t probably want to work there anyway. :) Also, it’s nice to know you can take a one-week holiday once in a while, and when you come back things wouldn’t be a mess.

People usually like taking challenges, so empowering them to do things a little beyond their current knowledge will only help them develop. No proffesional would like to do the same well-known things every day, so by offering them tasks that require study, prototyping or exchange of knowledge with senior colleagues would usually motivate them in their work, so it’s a win-win situation.

Letting your people know about their value should make them feel more responsible for what they do. Still, remember to avoid establishing an environment where everyone tends to be a “star”. Try to create a Star Team rather than a team of stars, by encouraging them to collaborate rather than compete. They need to understand that they all need each other in order to succeed.

When you are fair to your people, they are fair to you in return. This enables them to benefit of evaluations, and improve their skills by taking your positive or negative feedback as useful input in their own development. It is therefore up to you to provide them useful information about their actions, and not theirselves - you don’t want to change them, you want to help them act as needed.

Having the right pieces, sometimes unfortunately means parting with the people that don’t “fit” in the picture you and the others are part of. If there is nothing you can do any more to help a person be on the “right” track, it is in everybody’s interest that he/she moved on. This doesn’t necessarily mean firing them, as you could help them find their place in another team in the company. However, it’s good to keep in mind that negative influences spread quickly, but so do positive ones.

Title picture © Ilya Postnikov | Dreamstime.com

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags:

Say It Out Loud!

Communication is one of the key factors that drive teams towards their goals, making possible the exchange of ideas, plans or problems. It is therefore crucial to do it efficiently, while keeping in mind that you’re still talking to humans and not some kind of information processing machines.

It is therefore essential to choose your media wisely according to each situation, but to my experience so far, nothing compares, in terms of efficiency, to just saying out loud what you have to say. Emails may be useful for storing decisions or ideas, but it’s by live talking that you can transmit them in the best way.

Personally, whenever I need to discuss something with my team, I always prefer talking to them rather than exchanging emails or leaving offline messages on their IM accounts. I do write emails on important matters, but mostly aiming to archive the discussions for later reference, or when they involve many people which may not be in the same office or on the same schedule.

Title picture © Ghubonamin | Dreamstime.com

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: ,

What’s in it for Me?

Change is one of most people’s greatest fears, and therefore introducing it usually meets significant resistance. We all tend to stick to what we know, as we usually get quite good at what we’re used to do. Thus, when being faced to important changes in our lives, work or habbits, we will most probably react by trying to reject them, unless we really understand the benefits.

This is why, whenever you need to introduce new concepts, technologies, or working styles to the people you are working with, you need to ask yourself “what’s in it for them?”, as you can bet they will all ask themselves the same question in their own minds. If you are really lucky, they’ll even say it out loud.

Even if they didn’t, it’s still fair to ask yourself this question, as you wouldn’t want to introduce something that brings them nothing useful, you wouldn’t want to do the change just for the sake of it. It’s up to you to take the challenge of finding the fair arguments that will make them understand the benefits of walking a new way, rather than accept a decision.

Title picture © Ilya Genkin | Dreamstime.com

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: ,

There Is no “I” in “Team”

Teams work thanks equally to all of their members, as they all share the same goals, problems, successes and sometimes failures.

As each one of them has a very important role, in the end there can be no good result unless they all work well together. Even if at some points, some of the members might seem to balance the team “weight” towards them, due to special events that might involve them more than the others, in the long run they all have the same contribution.

I like to think of a strong team as an orchestra playing a symphony: each instrumentalist plays his own score, contributing to the beauty and completeness of the whole concert. If any of them would stop playing, the symphony will just not sound right any more.

Let’s take the well-known Canon in D by Johann Pachelbel and see how it sounded if only some of the instruments would have played (the complete track is played by a violin, a cello and a viola).

Here is the violin playing what you might call the main tune. However, you will see later on that this tune sounds so much better when it is accompanied by the other two instruments.

Taken out of context, the cello’s part seems to have no meaning, even though it has a significant contribution to the whole musical piece:

In the end, please take some time to listen to the complete track. If you focus, you will probably be able to isolate each instrument’s part, but most importantly, you will surely be moved by the beauty resulting in their teamwork.

Title picture © Les Cunliffe | Dreamstime.com

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: ,

“My Code Has no Bugs”

Bugs

Even though it is practically impossible to write bug-free source code, some people really think they do.

It was the case of one of my former colleagues from a company for which I have worked for a couple of years. He was really thinking that he was extremely skilled (and he was… but not as much as he thought), which unfortunately for him, has led him to adopt a quite arrogant and distant attitude towards everybody. And I mean everybody, as you are about to discover later on.

Durig a tremendously difficult installation for an important customer – a pretty big hypermarket which had just opened – the service team has discovered a blocker bug within the system: transactions weren’t properly saved to the application’s database. After spending a considerable amount of time in order to properly reproduce and describe the problem, it came out that there was a problem in one of this guy’s modules. So they called the company’s HQ and described him the problem.

Well, this is where arrogance and ignorance came in. He totally denied that the problem existed, even though the service people were looking straight at it. There was no bug. They’ve uselessly struggled to convince him, but the problem was so big that they had to escaladate the issue. As ridiculous at it may sound, it was the CEO himself who tried to convince him to look after the problem. Even then, he kept denying that there was a bug, and only when the boss became really “persuasive”, he took a look at the source files.

It appeared that his code did have bugs.

So when you’re thinking your code is perfect… better think you didn’t test it properly.

Title picture © Alexandr Anastasin | Dreamstime.com

  • Facebook
  • Twitter
  • Google Buzz
  • MySpace
  • Yahoo Messenger
  • Google Gmail
  • Yahoo Bookmarks
  • Yahoo Buzz
  • AIM
  • AOL Mail
  • Blogger Post
  • Delicious
  • Digg
  • Google Bookmarks
  • LinkedIn
  • Orkut
  • StumbleUpon
  • Technorati Favorites
  • Windows Live Favorites
  • Share/Bookmark

Tags: