Samuli Heljo | Productivity

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

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

Whatever happened to programming

published March 13, 2010

There is a discussion about Whatever happened to programming at TheServerSide.com. It is a fact that programming nowadays is more like gluing components together to solve a problem than coding low level data structures from scratch. Some people are seeing this as a bad thing and feel that programming has become monotonic and uninventive. However, we must remember the real reason why we are writing the code (or gluing the components) in the first place.

Every single line we write should have a valid business reason to exist. Every line should have a measurable ROI for the business, which is of course very hard to measure, but this kind of thinking should be reasoning behind all actions taken in a project. As size of our problems increase we must increase our level of working as well as our producivity. The program code is not written for programmers, it is written for the business. For the business, quality and productivity matter way more than the fact that a programmer might feel his job monotonic. Tough luck, there are about billion future coders in China, someone will be interested. I feel that software developers in general should be more interested in business ROI than they currently are.

Samuli @ 18:56 (No Comments)

tags: Business, Lean, Productivity

Trackback URL

Future user interfaces

published February 2, 2010

Now that Apple revealed the iPad, Goole is showing a concept for Chrome OS with some pictures, Microsoft is working with Windows Surface as well as project natal, and Nokia is unveiling N900, you got to wonder if the new era of user interfaces is upon us. Natural ui is coming which will bring interesting times for web development. Generally, a developer does not make a great user interface designer and natural ui will likely to make things more complex for the poor developer.

In the mean time I would very much like to see progress in modular user interfaces and software development modularity in general. I am not talking about mere software reuse but more like Component-based software engineering. As our problems are growing in size, the need for modular applications is coming more and more evident. There is absolutely no point of doing same thing over and over again.

Could there be a way to combine natural ui with something like component-based engineering? A platform that would provide needed ui components and intuitive user interaction that could just be hooked into a custom made service layer with a rich domain model?

natural-ui-design