If numbers come into play then quantification is implicit. Most of the projects I begin, I start estimating use cases in “High, Medium, Low” or “Small, Medium, Large”. Before the development starts we need to know how long something is going to take, hence we estimate. When we arrive at an estimate and put a schedule in place, subconsciously every one gets tuned to the numbers.

The numbers help in planning and helps the first release goes through; then the economical activities begin. Questions start arising like ‘Why two use cases estimated to be of the same size when one of them have fewer tasks?’ or ‘Why did two use cases with similar sizes take different times to complete?’. The completion of the use cases is what shows up as progress and slowly an illusion is created that the reduction in estimate is equal to the money saved. This leads to addition of scope similar to salami slicing.

The effect of salami slicing becomes visible over the course of time and developers begin to compensate by increasing the estimate. This vicious cycle leads to inflation and deflation of estimates, which in turn affects the project management’s ability to predict and plan. Quantitative/Objective measurement gives an illusion of control but will eventually affect the team’s ability to deliver value because there are lots of parameters which affects how something can be done; attaching a number to it will create those numbers to behave like currency. When we have something like a currency then we have economics.

Should estimation be very accurate?; No, it is like saying that with all the historic data and current conditions, we will be able to predict the outcome of cricket matches accurate to the number of runs scored. We should have estimates only as a guideline for planning and acknowledge that pin point accuracy will never be possible. Productivity is a result of so many factors and trying to assess that with a single number will result in expending time and energy away from productive tasks.

Image: jscreationzs / FreeDigitalPhotos.net

I often come across the illusion that a productive day for a developer is to churn out as much code as possible. This illusion creates an  expectation to keep coding for the whole day and cut short time to design, reflect or retrospect.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight

The answer to the question of measuring productivity is very difficult especially in the application developer’s world. Every one wants something such that it either enables them to earn more money than what they spent on acquiring it or it gives a sense of satisfaction on using the product (Essentials and Luxuries). Same is the case with every business who wants a software and present the consultants with what software they want most of the times instead saying what is the problem they are trying to solve.

It is expected of every programmer to make sure what we do is what the customer really needs instead of being a human translator to get specifications into working software. After a careful analysis we may even have to ditch the requirements or spend more time in sharpening the tools get usable working software soon, most of the times do both. I came across this post by John D Cook, who illustrates that sometimes a programmer can be 10 times more productive than his/her peer but it will not be obvious at all.

Numbers are useful mostly to indicate an absence of something. If we concentrate on creativity and problem solving instead of  getting some numbers on board we would end up being very productive.

A hunter watches a mountain goat grazing on the pastures on the side of a highway. A speeding truck loses control and starts veering towards the grazing goat, in split seconds it jumps off to a safe place. The hunter’s kid who was watching all this asked his dad, “Did the goat escape because it is agile?”. The hunter replied “It is just common sense to avoid a speeding truck”.

There was a question posted in programmers forum in stack exchange site asking Is agile the new micro management? I am not sure why such an impression about agile has been formed in that person’s mind. It could be due to some recommendations being wrongly interpreted. First of all the recommendations like “a quiet place to work” is a necessity for development teams anywhere following any methodology. Interpreting that as a no talking zone requirement is against improving communication between the team members. My perception about why these kind of wrong interpretations arise is due to wrong sense of accomplishment provided by having something tangible. If someone has to show any progress in adopting a new process or a method then it is natural for him/her to incline for a support in some form which could be seen or measured. This has led someone to believe that following some guidelines verbatim and measuring the level of adherence to it is equal being successful in adopting a new process or method.

I have not been aware that I was part of agile teams for a few years until I met someone who joined my team because it was an agile team. We were a team of 12 people doing weekly releases to production, wearing different hats of Dev, QA, BA and had everyday interaction with the customers. That is how I started my career and I never felt the value of it until I worked in a conservative setup. There was one golden rule of thumb we followed in the teams I worked, treat the team (client team included) as your own organization and do what makes sense to deliver the right value.

I asked one of the directors of a company that how come he never used the word agile though he was part of agile teams for quite long, he replied  “talking to your customers often; keeping the code well tested, integrated  and delivering the right value on time is all about common sense. There is nothing agile about it!”. He sure left me to figure out what agile meant.

Is there a prescription? Check the answers given out in that forum for that question.