Let's Talk Dev

I had a situation where one of my teams had some local members and other members who were remote.

At first I tried having the remote team members participate in their daily status meetings via a conference line. That worked, but just not as well as I would like. It was difficult for the remote folks to keep up with what was going on and often there would be discussions that they would not seem to know happened.

After struggling with this for some time I decided to try holding the status meeting over the phone for the whole team. It worked very well.

In fact I have one team that currently is in this situation and I find that having all team members reporting via phone puts everyone on a level playing field. The status meetings run quickly, everyone lets the person reporting talk without interrupting, and the meeting gets handled quickly- just like a daily status meeting should.

From this I have formed what I will call Remote Team Rule 1.

Remote Team Rule 1: When a team has remote and local members, daily status meetings should be held as though all team members are remote.

I agree with the premise that communicating and team building is easier face-to-face than doing it remotely. That however, is irrelevant. We live in a world where remote working is a reality and will continue to be so. It is high time for software professionals and companies to recognize this reality and do what it takes to be good at handling things remotely.

If you question the reality of remote working being here to stay please take a look around. You will see more and more people working remotely. Just look at things like Facebook. People all over are connecting remotely and maintaining relationship at a distance. The kids going through college right now have vast remote networks of people they have never met. Plenty of people will embrace doing things remotely.

I am utterly convinced that over the next decade our profession will embrace remote teams and in a big way. I’m talking about remote working in ways that we have only begun to imagine now. The concept of needing office space for a software development team will be antiquated. Just wait until some 20 year old kid drops out of Harvard and starts up a massive software company using his network of remote developer friends located around the world to build a product line. Think that’s impossible? I think not. Even if that doesn’t happen lots of companies are embracing the concept of remote working. If the rest of us in the software business are not ready to deal with that kind of challenge we will find ourselves obsolete and out of work.

The end game is a matter of survival. Being good at doing things remotely is a necessary skill for survival in the future of software. Acknowledge reality and get good at doing things remotely.

So Going Forward…

In this topic I will continue discussing ideas on working remotely. This will include building remote teams, managing remote people, conducting remote meetings and anything else that come to my mind regarding dealing with remote work.

As managers we love to count how many widgets are produced and at what defect rate. In manufacturing you can easily count widgets and defect rates to determine productivity and quality. You just plain can't judge software development productivity this way. There is no good way to determine what we mean by 1 widget of software. All the numbers are subjective. Software development simply isn't manufacturing.

Because of this, productivity of a software team is not measurable so stop wasting time trying to measure it. Instead, measure the change in productivity. 

I know, this statement contradicts itself. If you cannot measure productivity how can you possibly measure the change in productivity? Well, you really can measure productivity; just not in a way that is useful for direct comparison from team to team. If we look at the change in productivity now we are dealing with something that is comparable and is useful.

Some well known processes like Agile SCRUM recognize this by stating you cannot compare the number of function points produced by one team to that of another. The idea here is that any point system used to measure the amount of functionality added to a system is subjective and will only be valid in terms of that particular product and the team that produces it. Sure a team can determine a point value for each piece of functionality they add to their system, but that number will always be in that team’s units. You just can’t compare that number to another team’s number so there is no way to know if that measurement represents a high or low amount of productivity.

How fast those points are added to the system is called velocity. You can examine a team's velocity and look at how it changes over time. How velocity changes over time can then be compared to how other team's velocities change over time. This can give a good understanding of how successfully a team is increasing productivity. You can even compare this rate of change to other teams.

Quality Also Counts…

You can also look at how many known defects there are in your codebase. This is absolutely necessary as we don't want to get inflated productivity numbers by building lots of things that don't work very well. Heck, you can even get fancy and measure that in relation to the number of function points in your application to get a real sense of the defect density.

By examining how velocity and defect density changes over time we can see if we are producing more functionality at a lower defect rate. If we are doing that, we're on the right track. We can even compare these rates of change to other teams to help us understand what team is being the most successful. We might even be able to start looking into what one team is doing that is working that other teams might want to consider adopting.

So Going Forward…

It seems pretty straight forward on the surface but there are lots of complications to consider. Going forward on this topic I will be discussing ideas on how to measure these things and how that measurement can be used to improve the overall productivity of a team. 

Every time I look there seems to be another article on http://www.physorg.com talking about a new research breakthrough in quantum computing and the physics needed to make it work. At the current rate of development it will not be long before quantum based communication is feasible on a much wider scale and those same techniques have the potential to usher in a new age of technology that will make the current level of speed, miniaturization, and raw computing power look like a Model-T compared to a Ferrari.

I do not expect that we will see this transformation within the next few years but within the next 10 to 20 you can bet on it. At some point in this timeframe this transformation will take place and once it starts it will take less than 5 years to become pervasive.

What can I say?  I am excited about the future of computing technology. Just think of the neat stuff we’ll be able to build with it! Whoever can leverage this computing power will be a force indeed.

Welcome to my blog!

This site is still being put together. You should expect to start seeing blog entries from me by the end of June 2010. I'll be discussing various topics related to software development and the management of those who do it. By then the site should make sense.

Hope to see you again when things are up and running.

Thanks! -Russell