Teamwork appreciation

No Comments »

For a past few years i was lucky enough to work in some kind of teams. At first they were project dependent (formed for the project, and dismissed after the project ended), later they were stable groups of people who liked working with each other. It was obvious for me and all my co-workers, that sitting together in one room, and crunching the code as a team, was efficient and productive. Lately I’ve  stumbled upon radically different approach, and for the first time, I had to think-out why I loved so much working in teams, and why teamwork is better (at least for me). It turned out, that for many companies teamwork is unknown abstraction, or pure fiction. I’ve witness horrible things supporting this statement – like programmers working in 1,5m x1,5m almost completely closed cubicals with their headphones on and insulting testers for interrupting their ‘important’ work. Pure blasphemy in XXIth century, as far as I am concerned.

Nonetheless, I’ve had to come up the benefits of teamwork (and why they trump “people like their current desk, and they won’t be willing to give it up to sit together”). There are lots of posts on web explaining the same topic, so I’ll just try to sum  up the most important things from my point of view.

So, why forming real teams and teamwork matters?

1. It breaks down “my tasks, your tasks” culture. I believe, that such an attitude is one of the roots of all evil, responsible for many dysfunctions from poor department cooperation, to hundreds of bugs in supposedly finished part of code. Teamwork introduce other perspective, enforcing people to look at the project as a whole (or at least within the responsibility of the team), rather than only on their own tasklists. It leads to better quality, better design, and more care for the final product.

2. Teamwork implies shared responsibility for the work to be done, and usually enforces acknowledgment  that all the team members are responsible for all the tasks. So if two pieces of code are not working well together – it is the team’s fault, not John’s who wrote part A, or Mike’s who wrote part B. It’s worth noting here, that the closer people work together, and the smaller the team is, the greater the sense of responsibility. Six people should care more for the upcoming sprint review, than thirty people for whole milestone. If the human psychology worked differently, the communism would be a great success ;]

3. For stating the obvious, there are also benefits of better communication. The feedback loops are shorter, people talk rather than write long discussions over some communicator (Agile Manifesto!), and so on. This leads to better knowledge distribution (both domain, and technical), and in the end it leads to product with less bugs and better suited for the client needs, or at least for what the analyst wanted ;]

4. Better communication leads also to better design of the application, especially when conjoined with practices such as CodeReviews, or just brainstorming.

5. Task sharing helps avoiding the >40h behemoths-tasks, that are responsible for narrow domain specialization of people, that drastically rise the  truck-factor. Such tasks should be avoided at any cost, so there’s no area of code that only one person knows well. Teamwork helps fighting with that, usually enforcing well-grained small tasks, that are easily maintainable and interchangeable between team members, thus enabling people to work on the same feature together.

There are a lot more reasons to go with the teamwork instead of the sum of the single worker’s efforts – just use Google. Those mentioned above are the most important to me.

 

P.S. I’ve noticed that perhaps the true reason of my disappointment with lack of appreciation to teamwork among some organizations is in fact the misuse of “team” and “teamwork” terms. For me, ten people working for the same project, but scattered across the floor, without paying any interest in each other’s tasks are NOT team, and the DON’T DO teamwork. That leaves us with the question, what’s the difference between them and The Team, but that’s a good topic for the whole new post, so stay tuned :)


The Unwise Uniformity Exaltation

No Comments »

For three weeks now, I’ve been working for a very small software company within the aerospace industry, and I want to believe I’ve made a fully conscious choice to challenge myself with  absolutely non-agile environment. There is a lot of challenges here, and I hope I might be helpful to steer the mindsets to agile way of thinking and doing things – thus helping my new employer to deliver better software and grow.  I’ll try to post here some more interesting parts of problem solving and my thoughts on project development and management.

Today, I was talking with four new colleagues about tools and their bugs piling up in one project, when one my colleagues’ sentence hit me unexpectedly. One of them told something like “I believe all employees amongst all projects should use exactly the same tools (i.e. OS), to avoid unwanted old-habits and unnecessary drawbacks when they switch projects. It takes too much time when people are becoming used to new tools, and new ways of work”. At first I had no idea why it hit me so hard, but I felt it in my gut that something stinks there. The more I thought about it, the more clearly it appeared to me – the whole idea of uniformity is pure crap.

First of all, people are not uniform – we differ in countless ways, we work differently and we have different expectations of tools we’re working with. It seems at least unwise to me, to think otherwise and push total uniformity at all cost. And this cost is in my opinion far greater than few hours taken to learn tools the new teem uses:

1. Uniformity kills knowledge sharing – each employee knows only the standard tools, the standard way to solve problems, and there’s no new knowledge to share,

2. It kills trying out new things – people are curious in their nature, and they love to try out new things, so the idea of total uniformity is against our nature,

3. It kills creativity and new ideas – if everything would be uniform, there would be no place for creativity, and thus no improvement in anything,

 

4. Diversity makes the company resilient – it’s whole another (long) topic but in short: uniformity is the enemy of resilience; you simply do not put all your eggs in one basket, unless you want your company to be extremely fragile.

To be perfectly fair thou, I have to admit, that at some level some uniform tools and procedures have to exists, but it should at least start at the management level. Each project team have to be able too shape their own way of work – empowerment is the only way to true performance and good atmosphere at work.

 


10 things you can do to destroy your company and loose your poeple’s trust

No Comments »

A lot of time has passed since my last post, and I have to make up for it. Recently I’ve finished reading Peopleware by Tom DeMarco and Timothy Lister and it struck me, that after almost thirty years from first edition, this book is still up to date. It’s really sad, especially if you find antipatterns described there, in your own environment. It inspired me to sum them up, and compile a neat list presented below. Of course I have to mention that any similarities to real persons, companies and behaviors are purely random and they were not intended that way ;)

 10 things you should do, to destroy your company and loose poeple’s trust

1. people should not be trusted If you were thinking about trusting your people at any time, you have to be crazy. Many, many years of  capitalism, proved without a doubt, that if not watched, everyone is looking for a way to not to do his job. It is obvious, engraved in our current economy model, and I’m more than confident that you have similar experience so far. So to emphasize it once more – you should never trust your workers, but rather constantly monitor their every step. The tightest your spy network is, the more hours are spent on work, rather than on slack. It’s perfectly fair too – you pay them to work, not to waste time, right?

2. kill any signs of fun at work It’s part of the previous thing, but it’s definitely worth pointing out. You pay people to work, not to have fun, so if they do, there’s something wrong. The most probable cause is that you’ve assign too few work to a person, and he has started to enjoy his tasks. That is unacceptable and it leads straight to slacking off. Countermeasure is simple, and it consists of only one thing – assigning more work until all the joy and fun is killed. After all… hey – it’s work! it shouldn’t be fun.

3. don’t inform people with anything Don’t bother with anything like information policy or things like that. People won’t be working better if they knew, that their salaries will be delayed again, or that bonuses were cut off this year. They won’t be working better if they knew any good news either (as if there were any :P), so it’s just a waste of time and resources. After all, if it’s something really important (like those salaries), you might send a memo a day before or so, or just assume that people will find out everything from gossips, as always.

4. don’t keep your promises  It might seem tough but there is no need to keep your promises. People should be grateful that they’ve got work at all, so you don’t have to remember all the things you’ve promised them. Besides, keeping your promises makes you weak in front of your workers. It might be the sign of carrying for them, and you have to preserve your image. 

5. be tough to your workers, and submissive to your client Being tough to your employees is already explained, but you have to remember that the client is the king. You should be as submissive as you can, allowing any requests from the client side, including quicker delivery, impossible deadlines, big last-week changes, and so on. Remember – client is paying, and the workers are… to work, right?

6. be defensive You need to make sure that the failure of your people is not your failure.  You have to put out as many defenses, confirmation mails, documentation, as you can, until you are perfectly safe from your people’s incompetence. It all boils down to one simple rule – control the monkeys!

7. prevent forming teams Make sure, that your company is free of any personal attachment. To do so, throw people in and out of projects, move them physically between the floors and change their environment as often as it’s possible. You have to prevent the situation where people working together develop personal bonds, or simply feel like anything more than genuinely gray rat. All teams and guilts that might form are eminent threat to your authority.

8. use free overtime as part of project planning It’s absolutely normal to plan 120% of your people’s capacity. We’ve established above, that they are slacking off right now, so if they’d stop doing it, they’d actually might do more work. If they don’t they’d have to use their spare time to catch up with their tasks. It’s nothing but fair – you’ve already paid them for that time!

9. don’t hold on to people Any attachment to people is a sign of weakness, and you have to maintain your carefully knit image of  The Boss. Besides, everybody can be replaced with infinite number of students or off-shore workers.

10. don’t plan projects Planing projects is usually impossible and it’s wasting your time. You should take all the projects you can get, and start thinking how to do them after signing contracts. There’s no need to loose your precious time earlier, and so far there were no problems with that approach, right? You can always switch and mix people some more, to fulfill the contracts, and I’m confident that they will gladly use their spare time to help, and to learn skills that they’ve been proficient for five years, according to your contracts.

11. bonus – make sure that some workers are irreplaceable In some way it’s opposite to number nine on above list, but in fact, it’s not. It’s based on the virtue of negligence and supporting the “my code is my castle” behavior. It’s obvious that you have to allow people to keep their secrets and know-how to themselves, as good developers do. Fortunately you don’t have to  do anything at all, with this one. Just don’t support any knowledge sharing events and ways of work. Remember, your shining stars have to keep their secrets, to shine amongst the dark matter of feeble rest.