Wednesday, August 6, 2008

Productivity - A myth

What is productivity?

If you ask me, I would say that productivity is the most confused term I have ever heard. If you ask three people what do they mean by productivity you would probably get three different replies. Many people try to keep productivity and efficiency in the same boat. This is an attempt clear the air around what Productivity is. Do not mind if this adds a little more the confusion. Share your ideas and I would to learn from you.

Productivity in economics refers to the measures of output from production processes, per unit of input. Productivity is different from Efficiency which takes into account both the value of what is produced and the cost of inputs used.

In software product engineering, Productivity is the number of lines of code generated by a programmer in a given time period.

Do you agree with this? If you agree than it is important to read further. Time to clear some doubts.

If you disagree, you are welcome. Read on till the end and let us know if you still disagree.

Actually this definition is wrong. If this is true, I can use a code generator which would produce 50 times more code which I normally produce on a business day and I would be the most productive developer on that day. That is why most of the matrices related to lines of code are useful for nothing.

Let us think ahead. What about the following definition.

Productivity is the rate at which the end users enjoy new features. Looks interesting! Let us elaborate it using Agile methodology.

In Agile Software Development world, the productivity would be the business value delivered per unit. Here Unit can be iteration/release depending on at what level we are trying to measure productivity. Productivity and team's velocity would go hand in hand. The Velocity as measured in story points would be the productivity of that iteration.

But this is not as easy as data can be easily manipulated. Here we are considering story points as a measure of productivity. But it is easy to manipulate the story points and the team can show that the velocity a.k.a productivity is increasing iteration by iteration. The same case is with business value. Who would ensure that business value associated with easy story is correct. This can neither be measured nor validated.

Let us think further. Productivity is the rate at which the teams increase partner's (end users’) profits. What about this?

This would again be wrong. It is not the programmer's job to make the users profitable. Too many other departments are involved in between and too many actors who do not want to increase profits in any way.

The closest possible answer to what productivity is that no one has managed in 50 years of trying to define productivity in programming in any way that can't be corrupted by some means.

Tuesday, August 5, 2008

Collocated team vs. Distributed team – which is more productive?

Is there really any difference in working in a collocated team vs. working in a distributed team? I have worked in teams which were completely collocated as well as worked in teams which were so distributed that no two members were collocated. In my experience working in a collocated team is easy because of the effective and quick communication which is possible because all team members are sitting together but at the same time it would be wrong to say that there is a major difference in the productivity of collocated and distributed teams.

It is easy to claim that Productivity of collocated teams is more. This claim is based on the easiness and effectiveness of face to face communication. But the distance is not a barrier to those who want to communicate. Instant messengers, wiki or forums provide a quick and easy way to communicate even in a distributed environment. In the end it all comes down to how the team members communicate with each other.

In the following paragraphs, I have tried to share the challenges of collocated and distributed teams and how some of those can be addressed. Read on to go through my views and feel free to rave and rant through your comments.

It is easy to talk about the difficulties of distributed teams. Let us start with that. First and foremost, it is difficult to achieve the alignment and commitment of the whole team to the same goal and purpose. People do not really know each other and it is hard to build personal relationships.

Not everyone can perform well in a distributed team environment. The members should be self motivated, cross-functional and able to work independently. They need to be able to keep working effectively without much of big brother watching.

Some people feel isolated while working alone and therefore not able to remain focused.

To overcome these challenges, distributed teams rely heavily on communication and information technologies, such as internet, conference calls, e-mail, video conferencing, and various networking applications like instant messengers to tap into the intelligence expertise of team members.

It is time to move to challenges of collocated teams. Some people might think that there are no issues in collocated teams but that is not true. Face to face communication can bring issues if we are working in a multi-cultural and multi-lingual team. It is sometimes difficult to realize that we are getting affected by body language or other factors like hair style, clothing, smell, accent or whatever. Most of the communication in a collocated team goes undocumented and teams have to discuss the previously discussed topics again and again. If some key members miss the discussion then revisiting of same topics becomes more prevalent, obviously because of no formal documentation of previous discussions. People are more informal and they speak in their local language (slang, code words etc) in formal meetings too which is another problem. The body language might not support the words spoken during a conversation thereby reducing the effectiveness of what is being communicated.

Another interesting problem which is observed in collocated teams is that people avoid dropping emails and notes but rather waiting for other person to become free for a discussion. They continue to wait and sometimes it happens that the issue waits endlessly.

All the impediments whether working in collocated and distributed mode would impact productivity. Since I've had the opportunity to learn about agile methods I have realized that it’s literally a matter of choosing the communication methods that are suited to our environment.

To summarize, I’m not trying to claim that the potential problems of collocated teams outweigh the benefits. I prefer collocated teams, but I also acknowledge the benefits of distributed teams and distributed teams supported by the tools supporting effective communication can be equally productive. Distance would not be a barrier anymore!

Sunday, July 20, 2008

Is Business Continuity Management a priority in the Software Development Industry?

44% of the Companies in India have faced some form of disaster since 2006. Companies that promise 24*7 services, are heavily dependent on IT and data management. Let us look at a survey to get more information

In April 2007, Market Pulse, on behalf of Business continuity Management Institute, conducted a Survey. This survey gives us an insight into BCM practices in fifty-four organizations, having the most progressive BCM programs in India. Let us look at some of the findings.

More than half the respondents reported at least one significant business disruption in the last year.


Over half the respondents felt that their organizations were not sufficiently prepared to face business disruptions.



Following are few more stats:
• As many as 17% of the respondents report that their organizations do not have Business Continuity Plans. Most of these expect plans to be formalized within a year.
• The maximum loss reported due to a single disruption was Rs 100 crores (USD 24.4 million) and the average reported loss due to disruptions was Rs 7.7 crores (USD 1.89 million).
• Most organizations do not feel secure about their level of BCM preparedness. More than 80% have not planned for all four of these situations - loss of facility, prolonged power or communication breakdown, disruptions from service providers/suppliers and mass absenteeism due to reasons affecting the masses (like strikes, bandhs, epidemic situations etc).
Conclusion: It makes common sense to implement business continuity management solutions.

What is ideal tester versus developer ratio?

There would not be one single answer to this question. It depends on many factors namely environment, culture and intended use of software. For a gaming software the tester verses developer ratio would be low while for critical medial equipment software it would be high.

Let us look at what can be a possible ratio for a software development project which is neither a mission critical nor just gaming software.

Project needs both black box and while box testers. The testing activities to happen include functional testing, regression testing, acceptance testing and performance testing.

- One black box tester to test the source code developed by 3 engineers
- One tester to write the functional & regression (automated) test cases for the code developed by 3 engineers
- One tester to write the performance test cases for the code developed by 4 engineers
- One tester to write the acceptance test cases for the code developed by 6 engineers

The final ratio which comes out from the above is 13 testers for 12 developers. This is not an ideal ratio but certainly one which can be used to ensure that various quality controls are in place.

Sunday, July 13, 2008

Why Greene is gone?

The unexpected exit of Diane Greene, co-founder and CEO of VMware, is one of the biggest events of the year. This is end of an era. VMware is at such a big stage in virtualization market because of Diane Greene.

Diane is considered by many as one of the greatest visionaries of last 20 years and a great leader. Many of us might not know about her but a quick reading would be good enough. Read the following link to know about Diane Greene.
http://www.networkworld.com/includes/ads-pre.html

I too was one of those who did not know about Diane Greene and VMware but the recent event created enough curiosity in me to dig further.

I found that the departure of Diane is not a small event but would make a big impact. It has already made a big negative impact on the company’s share price. The share price has already moved down by a big margin in two days. While reading, I also learnt that VMware IPO was one of the most talked IPO in recent past (only second to Google IPO).

Diane is technology freak and gave birth to a new wave called virtualization by starting VMware in 1998. VMware’s first product “VMware workstation” was almost magical. It was amazing to run an operating system on a virtual machine. It was not heard before. VMware went ahead with their further offerings called GSX and ESX servers which consolidated on server consolidation and service isolation.

By bringing such products, VMware became not only the front runner in the virtualization market but became so big that it had more than 100000 customers and nearly 14000 partners which made it one of the fastest growing companies on the globe.

Now with the time, competition increases in every business and VMware too started to feel it. Few major competitors of VMware in virtualization market are Microsoft, Sun and Citrix.

In technology space when luxury becomes the basic need you never know? In last few years virtualization has become such a buzz word that every company wants to virtualize. Linux now has a virtualization support in the name of KVM (Kernel Virtual Machine). Intel and AMD made sure that hardware platforms are compatible and even thinking further whether virtualization can become part of the platform itself. This new thinking is so radical that would change the face of virtualization at all.

Microsoft is already planning to ensure that its recently launched Hyper-V hypervisor is part of Windows server 2008. And who is not aware of aggressive marketing campaigns of Microsoft.

Oops, you might be thinking that I am digressing from the topic. But I thought to give you a brief of Virtualization market before coming back to current event.

Now Greene is removed from VMware’s top post at a time when the company needed her most. She, being the technology champion, could find ways to consolidate company’s position in such a competitive world.

She has been replaced by a business person, Paul Maritz who spent most of his time with Microsoft and was crucial contributor in the aggressive marketing of Windows 95 and NT. I would not talk about his accomplishments in detail J

EMC has around 85% of the stake in VMware therefore it can take such aggressive decisions but I seriously doubt whether such moves ever help. If we agree with what market forces are talking about, VMware (or Greene) was not able to take certain forward looking decisions because the decision makers (board of directors) were not willing to cooperate. Diane was looking for a free hand while EMC chief Joe Tucci was against such freedom.

I have few doubts in the entire event

- Is it justified to remove somebody like Diane who is not just a founder of the company but ensured that VMware is such a big name in the market?
- Is it justified to replace her by a person who is new to virtualization market?
- What would be morale of VMware’s executives who are so closely associated with humble natured Greene?
- Did this change happen on the personal grounds?
- Would there be further consolidation between EMC and VMware?
- EMC and Microsoft maintain a healthy relationship. EMC even won the 2008 Microsoft partner of the year award. Did this partnership trigger this move?

We have not heard anything from Greene or her husband on the turn of events and when they share their side of story (if they?) we would get more clarity. Eagerly waiting!

I would like to end my thoughts on a funny note. When such an event happens anyone can quickly refer to the following joke

Joke:
The new CEO is given three letters by his ousted predecessor, and told to open them in times of crisis. Six months later, when things are not falling in place, new leader opens the first letter which reads 'blame everything on your predecessor'. So he issues a press release denouncing the former director and disaster is averted.
The following six months brings more problems, so he reads the second letter which tells him to reorganize the company, and he promptly fires a lot of staff making shareholders happy again.

A year later analysts and press are still demanding his blood, so he opens the last letter and reads 'time to write out three letters'.

Business requirement specification document?

Following question was raised in one of the forums on LinkedIn.

What do you expect to see in a business requirement specification document?

Here is what my reply was:
As per the 2003 metagroup report (later on metagroup was acquired by Gartner), 60-70% of the projects fail because of poor requirement gathering. In other words these projects fail because the Business requirement specification documents do not describe what they are supposed to. Or may be this is what happens
- SRS is written the way customer described the requirement
- Project manager reads this document and understands it in his own way
- Architects take inputs from project manager and SRS document and design it in their own way
- Programmer takes the design documents as inputs and program it in their own way

At all the above mentioned stages humans are involved!

Humans involved?
Two different people would understand and interpret a document in a different manner. This happens to requirement specification documents and therefore to software being developed rarely meets customer’s need.

Keep in mind that the customer does not want software. Customer needs a system which would help him in solving a business problem. It is always hard to articulate on paper what type of software would help customer.

More statistics – On an average 20% of the features described in SRS document would carry more than 80% of business value. Why not work on these 20% features first? How to come to know about those features? Would customer involvement help?

In most of the cases customers too do not know what they want. But because they have only one chance to mention (through SRS), they would write about everything which might be helpful even if not mandatory. Most of these features are nice to have but not must have.

Most of the time, when we look at SRS document, it looks like these requirements are fixed, while should not be so… Requirements evolve with time and there SRS document should not be written in blood.

Customer collaboration?
For me, the more than SRS document, involvement of customer (or customer representative) is important who can really keep a check on whatever is being developed is usable. This involvement should be from the beginning because changes at a later stage are difficult to absorb.

It is better to have SRS document having clarity of user stories which can be evolved by the continuous involvement of product owner. On high level, product owner would be responsible for the following:

- He would be the voice of the customer
- He would describe, prioritize and refine the requirements continuously
- He would be with the team and would ensure that the development team understands his (or customer’s) needs
- He would be responsible for the ROI and release plan

Opps, I gave the discussion a totally different direction but I thought to mention what came to my mind.
Vikas Hazrati , who is an active figure in Agile community in india, has come up with his thoughts on the effectiveness of seminars and webinars conducted to create Agile awareness. Please read his views at http://vikashazrati.wordpress.com/2008/07/12/spreading-agile-awareness/

Here is my point of view:
I agree with Vikas's thoughts. Whatever awareness we can create by conducting seminars and workshops would reach mostly to “decision followers” and to some extent to “decision influencers”.

But situation is not as bad. “Decision makers” are well aware with the fact that Agile is need of the hour. These days’ Venture capital firms are hesitant to invest in firms not using agile development. Decision makes are facing this fundamental change and are working towards that.

Agile is a revolution (revolution?) and mass public has to play a significant role for the success of it. A grassroots movement, motivated by these seminars and workshops, is required to increase the agile awareness level. I believe that not more than 20% of software world is aware of agile methodology at present.

As it happens with every good change, people first embrace the easiest part of it. The organizations (which started to follow agile) have gone through the agile methodology and started using it in parts. Therefore they do struggle and not able to see the real value behind it.

These seminars and workshops would ensure that the grass root level is very much aware of Agile methodology and would help in embracing methodology in its full form.

On using word revolution:
For me Agile is a revolution against those practices or rules which ensured that companies deliver what is written in requirement specification document but rarely delivered what customer actually wanted.

Sunday, June 15, 2008

The Nokia Test - Are you doing SCRUM?

One of the most popular methods to understand if a team is doing SCRUM or not is through the use of what is called “Nokia Test”. It is a very simple yet very strict test and almost 80% of teams who claim to be doing SCRUM do not pass even Level 1.

Here is an overview of the test:


LEVEL 1
- Iterations must be time-boxed to less than six weeks / Do your sprints start and end on planned dates
- Is the software completely tested and working at the end of an iteration
- Can the iteration start before specification is complete


LEVEL 2
- Does the team know who the product owner is
- Is there a product backlog prioritized by business value
- Does the product backlog have estimates created by the team
- Does the team generate its burndown charts and knows its velocity
- Does the team have outside people disrupting the work of the team during the sprint

Tuesday, April 8, 2008

Dividend vs Growth?

Investors can have an endless debate on what should be given the priority - Dividend or Growth?
In my opinion, the answers lies in the economy. In an emerging market like BRIC where growth is the key, the wise decision would be to choose a growth oriented company. The companies which reinvest their earnings become highly successful in the growing market. Reinvesting the money is better than giving it back to shareholders as dividends.