Aug 13

In Agile SCRUM we size things to put an estimate of the effort and complexity involved in producing the work product. We might say that the size of something is extra-small, small, medium, large, etc. These sizes translate into velocity points. How many of these points we complete each sprint tells our product owner how much work he should expect to get done in a release. It is one of the most visible measurements of productivity that will be seen by upper management.

In my teams, the primary things that are sized are user stories and defects. User stories represent new work and defects represent work to fix a defect in the application. I have found that they way teams tend to do their sizing is different for user stories and defects. It is like a different scale is used.

In general a medium sized defect winds up taking a lot less work than a medium sized user story.

This creates an issue when measuring velocity and ultimately when measuring productivity. If your team spends a much larger percentage of time working on defects in one release than in the next, you will see a drop in velocity.

As we know velocity is watched by many folks in any organization. Perceived drops in velocity will raise questions and cause concern. It should! However, in this case what is seen as a drop in velocity really isn't. It is simply an issue with how sizing is being done.

I am now pushing my teams hard to consider sizes of defects in context of user stories that are also sized the same. 

It is very important for a scrum team to size work efforts consistently. Always push the team to compare the work effort of an item they are sizing to other items they have sized in the past- Especially when sizing defects. If you don't then your velocity metric will be misleading.

Tags: | |
Jun 21

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.

Tags: | |
Jun 14

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.


Tags: |