Thoughts on Multi-Site Software Development

EyeQ is cool and innovative. And now it has been proved by SoftwareCEO Innovation Awards lately. SourceKibitzer EyeQ service has been chosed into the finalists in the category "Most Innovative Software for the Software Industry".

Let's see if we can win this award. Award winners will be announced at the Software Marketing Perspectives conference this May in Santa Clara, California. Looking forward to that.

It is so cool to see your product discovered by specialists. This time it was Gordon Graham from SoftwareCEO, who conducted tips & tactics column for outsourcer.

Tips include:
* tip #1: Assign enough resources at home to manage the remote team
* tip #2: Write the clearest, most detailed specs you can possibly write
* tip #3: Don't expect a lot of domain knowledge from a remote team, especially at first
* tip #4: Contact the remote team on their schedule, not yours
* tip #5: Review deliverables from your remote team quickly

I would also encourage you to read the full article at www.softwareceo.com .

We are very glad and excited here in SourceKibitzer. Today we are announcing the next milestone in the development of the EyeQ - the LITE version of the service. We wanted the key metrics and indicators like developers know-how, contribution size to be easily available for any company doesn't matter what its size, budget or business model is And we think EyeQ LITE can really help us with that vision.

It's better priced, simpler, and supports almost any technology.

• It is always free for first 5 users. Meaning if you have only 5 developers you can start using the tool and never pay for the service.

• Reports are simpler. We have left only the most important personal indicators in the reports.

• The price is really low. The monthly fee is just 20 EUR per developer. So there is no more need to fight with the cash-holder in your company to make him buy the EyeQ lite. 

• You are allowed to publish generated reports on the web or your intranet without any restrictions. If you want we can even publish you team reports on "the wall of fame" on our website
  

• Limitation 1. Unlike the full version, EyeQ LITE monitors the development of only one code branch. It is totally up to you to choose the monitored branch. We suggest you to take integration branch like trunk in Subversion or HEAD in CVS - in most of the cases it would mean the most important work of your team.

• Limitation 2. The lite version is only offered as a hosted service. But isn't it great for you? You don't have to install or administrate anything related to the service. You just  keep doing your work and  SourceKibitzer will do all team monitoring work for you.
  

So now you understand our excitement. Would like to try? Call us today.
We also encourage you to share ideas and suggestions for the service. Please, use our community support website here: http://getsatisfaction.com/sourcekibitzer

Mark 

As I have promised in the previous post, I would like to share some tips on how SourceKibitzer EyeQ helps you with the problem of high attrition rates.

Basic idea is simple: identify your key programmers, and be prepared if they go away.

1. How to identify key programmers. I already can hear lots of opinions telling that it is so simple and that it is always clear who is the key developer in the team. In some cases it is true. For example, if you have 5 developers in your team and they sit in one room, it is indeed very simple to know who is the guru. But finding the key developer is getting very difficult if the team is distributed, you use outsourcing service provider, or just your team is so big that you just can't be up to date with everything.

So here comes the EyeQ team report into the game. Take a look at Team Benchmark. Pay attention to the metrics know-how and unique know-how. Those indicate the employees breath of knowledge in your project. With know-how metrics it's fairly simple to see who actually holds the critical knowledge in your software project and therefore is the key developer. All developers who have know-how higher than 5.0 should be treated as key developers. You should pray for those who have higher than 8.0. For example, in SourceKibitzer we plan to introduce following motivation rules: developers with know-how higher than 5.0 will get 25% salary increase, developers with know-how more than 8.0 will be provided with share options scheme.

2. OK, you have done a lot to keep you developers with high know-how indicator. But it is not always possible. What should you do if you have just learned that one of the best developers will leave your company in just one month. Unfortunately, you don't have too many options...you have to find programmer to replace the leaving guru. Companies deal with this problem differently, but here I wanted to show you how EyeQ alumni report can help you with that issue. First, take a look at Unique Know-How Distribution. The orange section of the graph give you the idea of how big your problem is or in other words how much unique knowledge is in hand of the developer who is going to leave your company. The higher this number, the worse your situation is. But don't give up :) and take a look at Components with Alumni Know-How section of report. Here you will find the list of all components that the soon leaving developer(s) has unique know-how in. This information can make you feel better, as now the scope of the knowledge transfer is more or less clear. Great. But EyeQ Alumni report can also help you to find the suitable employee from your team to overtake the knowledge. Take a look at Know-How Holders report section now. On the left you see the developer who is planning to leave and on the right you see the list of developers who has shared know-how with him. Those are your best candidates inside your team to replace the quiting developers.

So to conclude the post, here a short summary. It is a huge problem if your programmer decides to leave your company. SourceKibitzer EyeQ can help you to handle this problem with 1. Track know-how metrics to know you key developers; 2. Estimate the size of alumni know-how; 3. Find out risky components, that quiting developer has worked on; 4. Identify best candidates from the team to take-over the knowledge.

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?