February 2008 Archives

There are so many articles teaching you the management of software projects and teams. Lots of talks about processes,  motivation, and so on. In this post, instead, I would like to concentrate on the not so popular issue that most of companies are facing. The issue of too many programmers quiting your team every year.
 
Let's imagine...There is a company, lets call it SupaCo, which has outsourced all of its business critical software development efforts to good reputation offshore service provider - RepuSP. RepuSP has hired the team of 25 software developers constantly working for the SupaCo. Everybody is happy :) RepuSP charges 40 EUR per hour and is happy to have almost a 2 million yearly contract. SupaCo is happy to have professionals working for them and fewer problems they need to manage.

Interesting stuff starts to happen after one year. Vendor manager from SupaCo, who is responsible for relations with the service realizes the fact, that every quarter one developer quits the team. From service provider perspective it is no a big issue, as it makes only 16% attrition rate which is not too bad for the industry.

But SupaCo vendor manager tries to calculate how much the problems is worth in euros/dollars. Simple calculation gives him the following:

• SupaCo pais 40 EUR per hour for each developer (~6,400 EUR/month)
• It takes 2 months to train new developer
• 1 developer from active team should mentor the newcomer for this period of time
  

Simple formula 2 months X 2 developers X 6,400 EUR X 4 (quit developers) gives you more than 100,000 EUR per year. Not a small money even for super SupaCo...

But the training costs is not the only factor you should consider. Be also prepared for:

• Every quiting employee punches hard the good relations between SupaCo and RepuSP.
• Some know-how is not easy to transfer just by the training.
  
• There is a risk you would need to pay quiting employee to be available to answer questions.
• It could take another 3 to 6 months for new programmer to reach efficiency of previous specialist.

The formulation of the problem was the goal of this post. In one of the next posts I will try to cover some tips on fighting this issue and discuss how our product can help you. So stay tuned.

Good luck with offshoring/outsourcing/near-shoring/opensourcing/multi-sourcing
Mark 

There is another great tool for distributed teams - RescueTime. It is a replacement of old-fashion tracking tools or manual time reports that your employees are obliged to write. From their website you can read: "RescueTime is a web-based time-management tool that allows you to easily understand how you spend your time. One of the coolest things about RescueTime is that there is NO DATA ENTRY. You install a doohicky on your computer and we magically track all of your time usage." You collect valuable knowledge about yourself or/and your team-mates, without spending a minute and that is what I like about it. Simple. Powerful. Valuable.

It's principles are very similar in nature to the EyeQ product we develop at SourceKibitzer. I hope, one day we can launch something together with RescueTime guys.

To be objective enough I have to mention similar tools that I have found from the web:

• http://www.timesnapper.com/
• http://www.workingprogram.com/qlockwork.html
• http://www.hackystat.org/
• http://8aweek.com/
  

Good luck with offshoring/outsourcing/near-shoring/opensourceing/multi-sourcing
Mark

I though that post by Josh from oDesk about the top books he would like to recommend for managers of distributed teams could also be interested for readers of our blog. Here are some books, on my opinion most interesting, from his list:

• "The Distance Manager: A Hands On Guide to Managing Off-Site Employees and Virtual Teams", by Kimball Fisher, Mareen Fisher
  
• "Managing Virtual Teams: Practical Techniques for High-Technology Project Managers",by Martha Haywood
• "Multisourcing: Moving Beyond Outsourcing to Achieve Growth And Agility",by Linda Cohen, Allie Young
• "Intelligent IT Outsourcing: Eight Building Blocks to Success", by Sara Cullen, Leslie Willcocks

If you know better books, please post the links in comments. 

This post is the first in the series of "Tools For Multi-Site Development". I plan to write about the tools we use in our company that help us badly in the virtual world of software development. If you know better tools, feel free to share your ideas in comments.

So the first tool I would like to talk about is MindMeister - http://www.mindmeister.com/. It is tool that brings Mind Map concept into the online world. Just perfect. If you don't know what the MindMap is, here is the short intro. "Mind Maps, are an effective method of note-taking and useful for the generation of ideas by associations. To make a mind map, one starts in the center of the page with the main idea, and works outward in all directions, producing a growing and organized structure composed of key words and key images". As far as I know, it is Tony Buzan, who introduced this idea. Thank you Tony.

So what is great about MindMeister? Simple thing - now it is possible to do brainstorming over the internet. You get a bunch of guys on the Skype (later I will also cover this tool), start the conference call, then start new Mind Map, and you are ready for online brain-storming. Everybody can contribute to the Mind Map online and discuss the progress on the fly.

I have did some search on the internet to see who is behind the MindMeister service. I found the Till Volmer at LinkedIn who is stated to be running the company. Surprise-surprise, but he is also running a near-shoring outsourcing software company called Codemark. I guess we now know how he came with that idea ;)

If you have a team with at least two sites or locations. Try this out!

Good luck with offshoring-outsourcing-near-shoring-opensourceing
Mark

It is so tempting to compare building a software product and building a house. There are so many articles and books who comment on this topic. End-users and project managers badly want software to be built in similar way to houses. And not surprisingly programmers are mostly against this.

I would not go into arguments about whether it is good analogy or not. Instead, I would like to point out one difference that makes software development much easier to manage, than house construction project.

Imagine, you are building yourself a new house (or renovating). Knowing you are an IT specialist, I would assume you hire the constructing professionals to do this for you ;) Everything is great during the start. You talk to the leader of the team. He listens to you carefully, seems to understand all your needs. Even the next step is great when you see the walls of your house starting to grow. You have a great feeling. But then, small surprises start to appear. One day you come to see the progress and you find one worker is doing nothing. You don't pay attention, as you think having a small pause is good and you also take breaks at your job. Next time, you discover a new surprise - there is no visible progress have been made during last week. And typically more surprises are waiting for you. You start to worry and demand reports from the hired constructing workers. After that, you find yourself visiting your house every day instead of every week. And the atmosphere of trust is getting ruined day by day.

But, now lets move to similar situation in software development. It is much easier to achieve visibility into what is happening in your "construction" team. when it is a software project. How is that? Because, in most cases you can access your "house" over the internet. Sure, the best way to add visibility into your software team work is by using our EyeQ product ;). But you can also check the progress by looking into the version control system logs. Products like FishEye can help you do some analysis on these log entries. And you don't even have to stand up from your chair for that.

In my opinion, software developers should not try to be as good as construction specilists. Instead they should try to use advantages in their hands and make their customers more happy than in case when they build houses.

Anybody still to argue that house construction is easier than software development?