Archive for March, 2009

Project Learnings for Team Members

March 23, 2009

If history repeats itself, and the unexpected always happens, how incapable must Man be of learning from experience

This quote by the great  George Bernard Shaw is so true in software development!!! The experiences gained (good or bad) in one project must be cherished by all team members. There will be learnings for all members of the team, irrespective of their hierarchy in the team.

A developer should be able to look at his performance in the project and see where he went wrong. Other questions he has to look at include:

  • How many review comments and testing defects were raised against his code?
  • How can he improve his code so that in the next project, he has lesser issues raised against him?
  • What are the areas where he sees he needs to improve?
  • Does he require training on those areas?

A QA resource should check his performance areas that include:

  • How many defects were raised by the Customer? How come it was not found by him/her?
  • How can I ensure that I have covered all possible areas in the application?
  • How can I improve the robustness of the application?

A Project Manager can definitely find lots of areas that can be improved. Some of them are:

  • How did the team perform? How can they do better?
  • Why did the issues that occurred in the project, occur? How can you ensure that they don’t occur again?
  • What were the people issues that were encountered? How can we prevent them?
  • and many more…

If the team members do not use these learnings in the new project, there is NO WAY they will learn and grow in their careers. Learning from your experiences is the best way of learning, more than any class-room learning that you might have done in your life.

Once, you can argue that things went wrong in the project you executed/managed. But, the next time you work on a similar role in a similar project, the same mistakes should not happen again. If it happens, it means that there is no learning. Only when you learn from the successes and more from the failures, you will be able to say you are experienced. Otherwise, you have just worked on development projects.

Advertisements

Software Developers need other skills too

March 10, 2009

It is not necessary that Software Developers are trained on technologies alone. The immediate response to that statement would be – Yes. They are trained on Communication Skills also. Agreed. Communication Skills are also equally important for software developers. They need to talk/write properly to Customer teams for project reasons.

Is that enough? NO. Then, what else is needed?

Software Developers need to be taught other skills that will impact their work. Things like Lateral Thinking, MindMap, W5H come to my mind. These tools and techniques are not good for Leaders and Managers alone – even Software Developers can make use of these fantastic concepts. How? Let us see.

Lateral ThinkingEdward de Bono defines Lateral Thinking this way:

Methods of thinking concerned with changing concepts and perception. Lateral thinking is about reasoning that is not immediately obvious and about ideas that may not be obtainable by using only traditional step-by-step logic.

The definition itself has enough clues on where the Software teams can use Lateral Thinking. Some of the deadlocks that are usually met in project execution can be removed if people think a little different. Of course, experience helps the process but it is very important to have a parallel line of thinking in a team.

Mindmap – This is a good way to represent your thinking. They are usually used to generate, visualize, structure, and classify ideas. While Brainstorming, they give a good idea on how it is progressing. This is definitely useful for the Project Manager or an Architect, as it will give him a way to capture all the necessary tasks to take care. An example is the SDLC mindmap that my good friend has come up with.

W5H – Another Management Jargon standing for Who What Where When Why How. As with the others mentioned earlier, these are also very useful for brainstorming discussions within the team. It is good to have these questions in mind when a project review is done (can be on technical grounds or quality purpose or from a domain perspective). If these questions are answered, then there is a good chance that the review has been completed to the maximum extent.

Other than these skills, of course it goes without saying that there must be all the other skills like Team Building that are essential as well. These are usually taken care in all Corporations by the regular Training Departments. Here, I have mainly tried to highlight the not-so-regular skills that will impact the project (team) in a big way.

Reasons for Attrition

March 6, 2009

Attrition – If one looks up this word, the synonyms that I get are abrasion, erosion, eating away, wearing away, etc. This shows that this is a very dangerous issue. This is prevalent very significantly in the IT industry, more than any other industries, for a host of reasons.

If you talk to any Manager in the IT industry on what is the most biggest challenge he would face in a project, the answer will be not technology, not schedule, not cost, it will be more often than not the resources and the attrition that comes along. We will try to find out why we have the high levels of attrition in the IT companies (especially in India) in the due course of this note.

There are several theories that are in place – Maslow’s Hierarchical theory of needs, McGregor’s Theory of X and Y, etc. – which deal with the psyche of any person and what are his needs, motivations and other factors which will retain a person in any organization. Here, I will try to split the associate who form the focus of this note to 4 different categories based on their experience:


less than 3 years experience – The nucleus of this group belongs to freshers and comparatively newcomers in the industry. For these associates, money is the primary factor. The company that offers these associates more money, irrespective of the work that they do (let it be maintenance, production support, documentation, etc) , will be able to attract them. There is not much of a retention plan that can be built for this group of resources – What the Manager will have to prepare is a Work-around, not a Mitigation strategy.

The trigger can be anything as small as a dispute with another team-member or big as dissatisfaction in the work-content, if not money. Mainly, the point I am driving at, is that “Prevention is better than cure” doesn’t work in this case. One has to be alert to be able to gauge the mindset of the associate and have an alternative available. Effective usage of Buffer resources is one of the alternative solutions. Most often, the associates tend to compare themselves with their other fellow associates with the nature of their work and feel that the Grass is greener on the other side, whether it is to do with money, technology, culture, etc.

3 to 7 years experience – Most of the associates having this experience are virtually non-existent in India. If they are present in India, it is either that they are forced to, because of some constraints like family, health, etc. Otherwise, these associates will be forced by the organizations to go on-site since they are one of the senior members in the team, if they haven’t already voiced their interests to go onsite. Also, typically, the average IT person will leave behind his bachelor phase and would want to work in a less-demanding environment, more like an extended honeymoon (which according to him, is possible in onsite Maintenance jobs) – in fact, the organizations also motivate these individuals in this way so that they can bill these associates in foreign currency.

The associates who stay back in India ideally become either an Architect or a Project Lead, which gives them a good sense of responsibility in the organization, ensuring that they remain satisfied. If you lose associates in this category, the organization is in a big soup for the future of the organization (who had proved their value all this time) are suddenly missing. The organization has to groom another person at this juncture and this will again take time.

So, how do you take care that these associates stay on in the organization? Give them technically challenging projects which will keep them satisfied and probably give them less time to think about any changes that will crop up automatically in a person with less-intensive work environment.

7 to 15 years experience – The category of people here will get into Management roles and hence have an idea of what goes on in the organization and understand the rationale of the same. The organization also would like to take advantage of their vast experience and hence, give more responsibilities to the individuals. Money ceases to be the most influential reason for this set of associates. The reasons for this set of people are more often the challenges that they face in the project. They would require work that will involve them in a larger capacity than that of a mere developer or designer. They will want more challenges, responsibilities, decision-making abilities, more power. Lack of any of these will typically make them restless and start looking at other avenues.

There is some amount of fear in this set of resources of how any change in the Higher Management will impact the way in which they have been working so far and that might also impact some of the associates. There have been instances where the associates have worked on high-technology projects with stiff deadlines and tough client interfaces. Once the project was completed and the associates moved on to a less demanding project, the tempo dipped, and people started looking outside for want of more similar challenges. Providing these resources with more challenging responsibilities and maybe, if possible, stock options are definite means of retaining these associates.

>15 years experience – These are a small set of associates typically, in an organization. They move out usually when there is a change in the guard in the organization or if there was a change of focus within the organization and they feel that they might not be able to cope with the change. These resources typically give way to a lot of chaos and disturbances among the minds of the associates much junior to them, regarding the future of the company and how it might affect their immediate future.

Also, there is a tendency for these associates to take with them a core group to their next company so that their comfort feel is retained even in the new work-place. These are the people who take care of other associates and avoid retention of the junior resources. Hence, retaining them is probably a task for the CEO and his immediate successors.

There are several common factors that are prevalent irrespective of the experience, however:

  • Money – This is one factor that can attract anyone away from his organization, though the probability will change based on the person’s experience and the person’s need at that instant.

  • Morale – This can be one’s own morale or generally the team’s morale. If your morale is down, the associates will feel immediately that this is the time for them to make their move.

  • Motivation Factor – This has to be provided by the Project Manager and the Team Leads. Without this, the team members feel lost and think that they don’t have a clue of where they are in terms of the organization and what is their career plan.

These factors will change for each person. In all, the retention of associates within a project group, forget a company is a major challenge that all Indian companies are facing in recent times.

In order to reduce this, we need to have a retention plan customized for each associate (as each of them have a different need) and this plan has to be visited regularly with the associate in order that there is no lag in the aspirations of the associate and what his expectations are, from the organization. Without this, the attrition levels will never come down at all. That will not be good news to the Senior Management and the various stakeholders of the company.

RUP is dead

March 5, 2009

RUP, according to Wikipedia, is an iterative software development process framework created by Rational Software. This has been successfully followed for many projects by all the Major System Integrators over the years. Until Now.

2 things have changed this. Open Source, Agile. One can say that the 2nd one is an assumed entity of the first initiative. Nevertheless, both of them have combined to make change to the way Software Development used to happen.

No longer are customers willing to wait for years to see their end-product. That is a big risk in current times. Customers also don’t have the patience to wait for a longer period to see how their application is evolving. Regular demos are very important in a project (so that early feedback can be provided).

In fact, new development projects are rare to start now. In the current recession, if projects can wait, they are put in cold storage.

The fact that each of the phase depend on a bunch of documents to be produced – which may or may not be used subsequently – is also discouraging project teams in adopting the RUP methodology. Code is always the best documentation of an application. If you have properly documented your code, chances are that anyone maintaining the application will be able to understand it better than a set of UML diagrams.

The Open Source Movement has also shown how well the Agile model of developing working code has worked. The use of Wikis and other Web2.0 methodologies also help in higher productivity among delivery teams.

Of course, this is not to say that Agile is the best model to approach – it has got its own pros and cons. One has to depend on the methodology based on the project needs and then decide. But, the use of RUP in projects have definitely reduced.


%d bloggers like this: