Edge of Chaos | Agile Development Blog

Why do teams gel? Why some teams are trustful, enthusiastic and passionate; while other teams are apathetic and boring? There is no recipe to build a great team. You can’t add 5 grams of trust, 3 grams of fire, pour in some communication and boil till ready.

Why we need teams at all?

Working Alone

Team adds some new qualities in comparison with individual. When you program alone, you don’t need trust. Of course, you most likely trust yourself, otherwise you need  medical help. Besides you don’t need communication skills, if you speak to yourself very often you need medical help as well. All you need as a lonely programmer is problem solving, technical skills and passion to move forward. However, these are not enough to work effectively as a team.

If you work alone, you are free to make any decision fast. You have zero overhead: no meetings, no discussions, no phone calls, no questions.

If you work as a group of people (I mean, team), everything is not that shiny. Suddenly, you have to visit meetings. You have to participate in various discussions about technical issues and solutions. You have to answer questions and sometimes you have to do things you disagree with. Is that all so awful? Yes, it is.

So, why people do form teams? Simply, to solve problems that can’t be solved by a single person. Team is a necessity and it suddenly brings more formality to problem solving:

You have to communicate to have aligned vision. Otherwise you will solve two parts of the problem differently and solutions will not fit.
You have to coordinate work. Otherwise you will have huge delays and inefficient process.
You have to find common language to understand each other.

Team brings an additional overhead.

Working as a Team

In general, an effective team reduces overhead to minimum and lets people really solve problems and focus on main activities (I mean development). If we think about team from this interesting angle, we can easily find good practices to  improve team’s efficiency:

• Less people. Small team has less overhead.
• Common language. All should understand each other as quickly as possible. That is why offshore teams have huge problems.
• Less meetings. Ban all meetings and activities that don’t help to solve problems.
• Minimum people on meetings. Invite only those people who can really bring value to problem resolution
• Team isolation. It is generally a bad idea to have 2 teams working on different projects sit in one room.
• Fast communication channel. In general, the goal is to have less communication. Really. It is. It means if you have to discuss something, you should do that using the fastest available way, and it means in person talk most likely near a whiteboard.

But. Improving team’s efficiency, we can easily decrease team’s creativity. It may happen that team will solve problems quickly, but these solutions will not be the best. It may happen, that some unstructured chats about stupid things cause a genius idea. We can’t predict what will help us to find a really cool solution. Most likely we should not strive for complete rigid team that communicates only about problems and solutions. There should be a slack, and it is always there. People instinctively feel that unstructured chats are good and helpful sometimes.

Trust

You can’t have a good team without trust. Why? Simply because trust reduces communication time and helps to solve problems quickly. Imagine a team where people don’t trust each other. You immediately have political games, suspicious questions, indirect wording and rounded phrases. You have hidden conflicts, but polite discussions on a surface.

If you come and see this team in action, you will be astonished by stupid decisions and dumb solutions. Everybody’s goal is to cover his ass in such an environment.

Trustful team doesn’t spend time on all that shit. Discussions are hot and straight to the point. People can even scream on each other sometimes, but if they trust each other it does not really matter. They critique bad decisions fearlessly and don’t hesitate to provide fresh ideas.

Trust saves time on communications and leaves more time to do the real job.

Passion

We all saw people with extinct eyes. We all saw boring and semi-dead teams that work from 9 to 7 and can’t wait to leave the office. Nobody wants to work in this place. But still many do. I personally can’t understand why people do that. I don’t accept any usual arguments like stability, money, habit. I can’t work in a boring place on boring projects. It is not fun, it is not interesting, it is not valuable.

Passionate team is built from passionate people. That is it. They really care about what they do, they focus on real problems, they do everything to improve things. Passion is an ultimate team’s engine. No passion — no drive.

Wrap Up

Great software development team is built from passionate skilled professionals that trust each other. They collaborate effectively to solve problems and improve team work.

Our company is quite small (25 people). Most companies of this size focus on rapid growth and don’t pay much attention to learning. We are different. Fortunately, learning is very important in our company. We boost it in all possible ways:

• We highly encourage people to try and learn new things.
• Every employee can dedicate up to 12% of their time to unstructured learning (5 hrs per week).
• We organize internal trainings twice per months.
• We organize so-called Friday Shows every other Friday where we watch and discuss some interesting videos about UX, development, business, etc.

About a month ago we decided to structure our trainings in a better way. The resulting idea was internal mini-conference. Mini-conference is a full-day event dedicated to sessions and discussions. All sessions are prepared internally. The idea is to have a very focused learning event instead of several trainings over 2 months.

Our first conference will take place this Friday. Here is the program

10:00 Registration, “wake-up” coffee
10:15 Data Visualization Alex Tsayun /45 min
11:00 coffee break /15 min.
11:15 Node.js intro Vadim Gaidukevich /30 min
11:45 MongoDB (NoSQL) intro Oleg Seriaga /30min
12:15 coffee break
12:30 Exploring Good Experience Seth Godin (guest video) /20min
13:00 History of Kanban Anton Marchenko /30 min
13:30 lunch
14:30 Performance Metrics Alex Fomin /1h
15:30 coffee break
16:00 Marketing and Sales @ TargetProcess Andrey Mihailenko /1h
17:00 free discussions.

I am really curious about the outcome. Wil people like it? Will we keep this practice? Not sure. But we are trying new things :)

If we think about conferences in general, the traditional understanding is: people come together to share their knowledge, to learn, to discuss, to network etc.  Some people expect that if they attend a conference they for sure must learn something totally new, something that will change the way they work or even their lives.  Some people come to see who’s out there, to network and to have some fun. In a nutshell, as many people as many reasons to attend conferences :)

I tend to think that with all the  information we’re consuming, it’s very hard to come up with something totally new to a thinking and knowledgeable audience. If you’re engaged in agile community, and if you’re a thinking person, you thrive in the blogosphere and you practice agile  - it’s hardly that something will be totally new to you (“totally” is the keyword).

Recently we attended Agile Central Europe conference in Krakow. I’d say that my #1 enjoyment about this event was live cross-twittering. Broadcasting Agile CE to the Twittersphere has really been fun. I liked tweets by Andy Brandt, Marc Loeffler (aka scrumphony), Pawel Brodzinski and Robert Dempsey (for the two latter, it’s not only tweets, but their presentations that I enjoyed) .  As opposed to most attendees,  I didn’t very much like the closing show by Gwyn Morfey and Laurie Young. The guys have done a great show, but it was more about dramatic presentation of what’s going on in any dynamic agile team :) I’ve seen a bit of those “paper sword fights” :)

After attending Agile 2009 in Chicago, I’ve really got a little bit skeptical on the conferences overall because what I’ve seen was people talking about simple truths but with such an air as if they were uttering epiphanies. So, when going to Agile CE I wasn’t expecting epiphanies. It was more about going out there with our team, watching people and taking every opportunity to enjoy everything that comes up on the way  (including live jazz night in Krakow).

This approach worked better than huge expectations. Strangely, this small cosy conference has become an unexpected source of inspiration.  In a sense,  that it’s not always you have to come up with an excellent new topic or idea no one else knows about. The main thing about conferences is confidence and freedom to express yourself, share your personal experience and absorb experience of others. Somehow someone will find it useful. There’s no need to be afraid to appear too simple. People will listen and admire  even if this is your first experience as a speaker.

And.. it’s great that there’re many more agile conferences to come :)

Recently I’ve read a very interesting post by Anna Forss called “Stupidity of the Team”.  While Anna concludes, that it’s healthy to introduce diverse opinions and invite opposing minds to dissolve the like-mindedness of homogeneous teams, I think there’s one important nuance that shouldn’t be overlooked.

Let’s think:  teams exist for some purpose. To resolve some goals. If it’s a small product development company – then this team exists to develop a product. Permanent rebels are not welcome in any group – because what they do with their rebels, argues, drawing attention to themselves – they blur the focus of the whole purpose why team exists. Of course, a team will naturally outcast this person.  Next, if a team is bombarded by controversial opinions and judgments, they will spend all their time evaluating and thinking if this is right or wrong. They will get busy sticking tags on new opinions instead of focusing on their work – and they will inevitably lose their focus.

Life in a small development team can be compared to living in a sheltered reality, with it’s particular culture. An isolated sheltered reality will not last for long if it’s completely isolated, so emerging on the surface for a gulp of fresh air is really needed.  As a member of a small team – can you remember when the opposed rebels and opinions really did help? When they triggered something that the team would not have thought by themselves? Well, of course, if someone comes up and says – “your UI is bad” – then another person comes up and says – “your UI is bad” – then you start thinking that it’s indeed something wrong with it. You’ve got this signal from outside world. You work on it. Basically, you know what you should work on. The outsider’s opinion has accomplished it’s task – the outsider’s opinion can now go, because you’re not interested in hearing variations of one and the same opinion.  You get to work, and you work to develop a nice new UI.

There’s no need to focus on outsider’s opinions and pay too much attention to them. Outsider’s opinion is just a trigger to team’s actions – it’s not something that the team should busy their brains with all the time. In a way, diversity of opinions may be even harmful. I guess that’s why we’ve got leaders – authorities who tell the crowd “THIS is your Holy Grail”.

My conclusion is: healthy vaccination with opinions opposing a team’s culture is  good. But don’t overdo with them. Too many opinions will not increase collective intelligence for this team’s specific purpose, they will blur it.