Apr 19

Wow! It has been a really long time since I have posted anything. I really must resolve to post more often.

Today i stmbled upon an article about open workspaces that made me think about the question of Why do business go to these plans?

Consider for yourself and the answer becomes quite obvious.

http://www.washingtonpost.com/posteverything/wp/2014/12/30/google-got-it-wrong-the-open-office-trend-is-destroying-the-workplace/?tid=pm_pop

Tags:
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 14


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