The Blog

How to measure team productivity?

published May 26, 2010

Imagine this. Team A is producing 500 lines of php code per sprint whereas team B is producing 400 lines of Java code per sprint. Sprint length for the team A is 3 weeks, team B is doing two week sprints. In the team A there are 5 developers and one tester, team B consists of 4 developers. Both teams are “scrum mastered” by same person. Which one of these teams is more productive?

I have given lots of thoughts to team productivity and to systems and processes that could reliably measure it. Today, I finished reading Leading Lean Software Development and found a very nice gem from it on the page 235, where authors discuss about productivity.

First they state that there is no good definition for software productivity. Software development is rarely the goal of a system but a way to solve a customer’s problem. Therefore, measurement of  function points and lines of code is irrelevant and the real productivity should be measured from value provided to the customer.

This is very powerful stuff as I have many times witnessed how a project is measured against a-year-old-and-out-of-date project plan which is pretty crazy. What is the value we are providing to a customer? How much value are we providing per developer? These are the questions we should be asking.

So, was team A or B more productive?

Samuli @ 21:16 (No Comments)

tags: Customer, Lean, Productivity

Trackback URL

To fix a design flaw or not to fix?

published May 24, 2010

You know the case: a situation in which you must decide whether you should do something about that design smell that was introduced earlier. You suspect that it will not have any effect to a whole system, but still, leaving it like this is not an optimal solution.  There is a link at InfoQ.com to a blog post about sufficent design. In short, the blog is about this very same issue, a decision, whether to refactor existing design flaw or not. I feel that this question arises quite often and there is not one correct way to handle it.

The main point with this particular “flaw” is that it was carefully analyzed by a team and a decision was made to leave it as is. For me this is a valid argument to do so. Everything cannot be perfect, but I would like to know how much time the team has spent on the issue? Author states that the issue has been revisited many times, so I have to ask what if the code had been done differently at the first time, would they have saved time in the long run? I find this question intriguing and claim that companies are consuming huge amount of time and money to things that could just be fixed and forgotten. Worst cases are those where a team continually reopens issue without actually doing anything about it.

Shortcuts are unavoidable but they have to be managed. Firstly, you should never take a shortcut if you are dealing with an architecturally core component, that is a sure way to shoot yourself in the foot. If the component can be classified as “not-so-core”, then I see no fundamental error in leaving a minor flaw in the code as long as the flaw can be isolated from the rest of the codebase. Ideally, you would fix it but it is not always that simple. Secondly, I recommend keeping a document about architectural shortcuts that are left in the code. These things have a tendency to be forgotten, so a Toyota-A3-like document is a working way to keep team conscious about shortcuts.

Samuli @ 22:01 (No Comments)

tags: Productivity, Software architecture

Trackback URL

mod_rewrite 101

published May 11, 2010

mod_rewrite is a popular apache module for rewriting urls and making redirects. I decided to write small introduction about it, since I had to configure it on project test server. Reason why we are using it, is our upcoming release in which we will need to forward our customers to new liferay community instead of default /web/guest.

So, after rewrite engine is turned on from apache configuration, it will filter all matched requests and apply special rules for it. Request is passed through this chain of rules and if match is found, redirect is sent by apache.

mod_rewrite’s work horses are RewriteRule and RewriteCond directives which are used to build rule chain. Processing works so that

1) config files and .htaccess files are parsed for RewriteRules from top to bottom.
2) First RewriteRule is selected and request is compared against RewriteRule’s pattern.
3) If match is found and there are RewriteCond elements introduced, they are tested against the request.
4) If conditions match, redirect to new rewritten url is made.
5) If there was no match, request is passed onwards to next RewriteRule in chain, if such exist.

Configurations
Below is a simple configuration for redirect

# Turn on rewrite engine processing
RewriteEngine On
# Write log here
RewriteLog /var/log/httpd/rewrite.log
# Log everything
RewriteLogLevel 9
# Redirect context root to new community /web/new/
RewriteRule ^/$ http://%{SERVER_NAME}/web/new/
# Do not allow access to old /web/guest
RewriteRule ^/web/guest(.*)$ http://%{SERVER_NAME}/web/new/

There is loads of stuff you can do with this module, check it out.

Samuli @ 19:59 (One Comment)

tags: Liferay, Software

Trackback URL

Agile project ramp up

published May 6, 2010

The current project I am participating started without ramp up and the whole team was brought on-site right from the beginning. Now, 2 months after the start, I feel that some kind of team ramp up would have been useful. We started the project without a real product backlog, architecture plan, wiki or bug tracker. First two sprints were pretty much filled with infrastructure work, initial architecture design, backlog work, and the “normal sprint 0 stuff”. Still I feel uneasy.

Do not get me wrong, our customer is really good and in my opinion, doing lots of things right. But I think that we would have been better off had the project been started only with a team member and a scrum master. Then say after 3 sprints, rest of the team would have been invited to the party. I feel that in the beginning there are too many obscurities to fully utilize whole team potential and unnecessary waste is generated.

Also, Scrum.org’s Scrum guide says:

The ScrumMaster works with the customers and management to identify and instantiate a Product Owner.

But for my current project, it was other way around.

One could argue that by inviting whole team from the start, each member will know project history from the beginning which will help them grasping social representations among other things. Also by ramping up the team, you will unintentionally divide the team to “old-timers” and “newcomers”, but that will hardly be a problem because team is still very much forming and open for the newcomer innovation. During ramp up period there would be time to get product backlog started and initial prototypes/mock-ups made.

What do you think, do you ramp up your agile projects?

Samuli @ 19:19 (No Comments)

tags: Process, Productivity, Scrum

Trackback URL