Yet another Agile methodology

Based on my experience with projects, its teams and the customers and by doing a simple analysis of what are the most common pain points of these three entities, I have come to an approach that can be applied in the world of Offshore Contractual Software Development (OCSD). By OCSD, I mean all IT companies in the world that provide services such as software development, testing, or maintenance of existing systems to external customers that are not located in the same location (most commonly – in another country).

I came up with this approach by simply collating a list of all the problems that the customer and the vendor teams would want to do away with, thereby benefitting from its absence. I took the 6 most common problem statements (and presumably the most troublesome) from the list to derive this methodology.

The Six Most Common Pain Points (in no particular order):

1. Less or No Visibility / Lack of Effective Communication Mechanism: Customers often complain that they have no clue of what happens in the projects they are sponsor. Project teams work in silos and provide no or little information about the problems faced in the project or the execution status. The customers also would prefer some visibility of the product during the development cycle.

2. No Improvement in Processes: Project teams find it hard to change existing processes for the lack of empirical data. Imbibing of good practices and avoidance of impediments would help the project teams to plan and perform better; but existing methods to capture such information in the organization is a painstaking task with (sometimes) heavy and subjective templates to be filled.

3. Bloated Software: Most of the times both customers and vendors realize late in the stages of development, that the features that are developed add no or little business value to the users. At this point, customers (and sometime vendors) change requirements or chop features to make the application lean. This results in hefty re-work and decreases the stability of the system.

4. Poor Quality: If this list was ordered in ascending ranks of problem statements, this one would be on the top. While customers complain frequently on the poor quality of deliverables from project teams, the project teams in turn blame inadequate time lines and frequent change requests for this monster’s existence. Whatever the reason maybe, we might be able to salvage this problem.

5. Effort and Schedule Overruns: Incorrect estimations, re-work (due to any reason) and inconsistent planning are the usual culprits for effort and schedule overruns. Overruns such as these cost vendors and customers up to 300% of the actual contractual obligations, averaging at 60% most of the times.

6. Ever Changing Requirements: Customers are meant to be finicky, but their nature causes many projects to miss their quality, schedule or budgeted cost goals. If requirements can be frozen, approximately 80-85% of projects would not fail to deliver as promised.

My concoction to reduce most head-aches

Based on the list I presented above, I created a hybrid process using practices of three different agile methodologies. Here is the recipe of practices I recommend as “must have” with additional practices as optional condiments.

Must Have Practices (Set One) – Increasing Visibility

Deliver Frequently (Also known as ‘Small Releases’ in Extreme Programming and ‘Frequent Delivery of Products’ in DSDM).

This practices suggests that you have frequent releases of “potentially shippable software” that allows the customers to see gradual (and incremental) progress during the execution of the project. The frequency is suggested to be between 1 – 4 weeks in length and at the end of every such period some functional piece of software must be delivered or demonstrated to the customer.

This is possible with the adoption of iterative and incremental development approach.

The frequency at which release are made also depends on the volatility of requirements. Higher the rate of change requests, shorter should be the duration.

Optional Practice

Whole Team – Extreme Programming (Also known as ‘Active User Involvement’ in DSDM)

This practice involves not only the project team members, but also Customer teams and End Users in an active dialog to verify and validate the progress.

Must Have Practices (Set Two) – Improve Processes

Daily Scrums, Sprint Retrospectives – Scrum (Also known as ‘Continuous Improvement’ in Extreme Programming)

The purpose of this practices is to communicate – ‘What works’ and ‘What Could Work Better’.

Daily Scrums are internal team meetings where the team members inform each other on task updates and problems they faced. Sprint Retrospectives are done at the end of iterations to identify good practices and problems that can be avoided in future sprints. Thereby, fine tuning existing processes to work better.

Must Have Practice (Set Three) – Right Features for Best Business Value

Design Improvements & Simple Design – Extreme Programming, Fitness for Purpose (DSDM)

Constant design improvements during the life cycle of the project help identify unnecessary functionality and also prioritize features that would result in higher ROIs for the customer. Weeding out dead weight from the project will result also in higher productivity and better quality.

This can be done as a part of planning or retrospective meetings by the team involving the customers and end users. Demos at the end of iterations also help the customer/end users to realize what is important to them and what is not.

Must Have Practices (Set Four) – Increasing Quality

Code Standard – Extreme Programming, Continuous Testing – Extreme Programming (Also known as ‘Integrated Testing’ in DSDM)

Defining Coding Standards and Guidelines for project teams to follow will help in standardizing and maintaining the quality of code. Practices such as continuous testing allow project teams to identify defects early on during the development compared to the late detection of defects as in the Waterfall model.

Optional Practice

Pair Programming – Extreme Programming

Another method of organizing development teams is to pair programmers to work together on the same piece of work on one terminal that is shared between the two. One writes the code (called the driver), while the other one reviews it in parallel (called the navigator). The pair takes turns in playing each role. This pair is also rotated on other tasks. Two of the primary advantages of this practice are that two minds work on the same code resulting in better logic and the fact the code is reviewed as it is written, resulting in better code sooner.

Must Have Practices (Set Five) – Sticking to Planned Effort and Schedules

Planning Game – Extreme Programming (Also known as ‘Planning Poker’ in Scrum)

Sustainable Pace – Extreme Programming

As per agile practices, the estimation for effort and scheduling needs to be done by the project team and not managers or customers. The team will based on their experience suggest the amount of effort and time that it will take to carry out tasks. This leads to a stronger commitment from the team and increases their productivity since they now have full responsibility and accountability of sticking to their commitments.

Sustainable Pace suggests that the team work at a sustained pace through the project (for e.g. 40 hours/week) and avoid spikes in effort to meet deadlines. Planning that is carried out keeping in mind this practice is more effective and realistic.

Optional Practices

Self Organizing/Managing Teams – Scrum (Also known as ‘Empowered Teams’ in DSDM)

Giving the team the responsibility of planning and estimating may not be enough. It is advisable that the team is also empowered to meet their commitments. Hence, having a self managed team proves beneficial to the project.

Generating Burn-down Charts – Scrum

A burn-down chart reflects on the progress the team has made so far in the iteration. It is a graphical representation of the current velocity of execution of the team versus a steady pace. This allows the team to visualize the amount of work remaining and hence move things to a higher gear.

Must Have Practices (Set Six) – Stabilizing Requirements

Product Backlog – Scrum (Also known as ‘Base-lining Requirements at a High Level’ in DSDM)

Sprint Backlog – Scrum

A Product Backlog is a list of all functional and non-functional requirements of the project. It may also include tasks that need to be carried out to clear impediments or resolve dependencies. Having a product backlog allows the team to see a larger picture, though only the requirements that will go into immediate production need to be detailed.

A Sprint Backlog on the other hand is a sub-set of the Product Backlog and contains only those requirements/tasks that the team is undertaking for the current iteration.

While the iteration is in progress, the customer (Product Owner) is free to modify all product backlog items except those that have moved to the sprint backlog.

As mentioned above in practices set one, if the requirements volatility is high, then it is better to have shorter durations for iterations.

As you might have noticed, even though the practices are categorized as per the problem statement it immediately solves, it also would help reducing or eliminating other problem which might not figure in the List of Six.

Disclaimer

These practices have been borrowed from various agile methodologies, but each of these methodologies have more practices that it suggests implementation. And since, we do not in this concoction of practices implement all practices of a particular methodology, we should not claim to be practicing that methodology. However, by taking a dose of this mix, you can claim to be “agile”.

All credit for defining the above practices go to organizations of respective agile methodologies. But however, I take full credit for this tangy cocktail!

Two in the hand is better than one in the bush

Every couple of months or years, people from our industry, try to find better ways of creating products with better quality and faster turnaround. One such initiative is the Extreme Programming methodology or XP as it is more commonly called. XP lays down couple of best practices that are proven to enhance productivity of teams across the globe and one such best practice is one that addresses generating better code.

Pair programming is a practice that requires two developers working together on one workstation. Each member of this two people team is doing something that the other is not currently doing. For e.g., if one is writing a function, the other thinks about how the output of this function will affect the other pieces of code in the class.

The person who is typing is called a driver while the other, who is doing the analyzing, is called the navigator. At the end of a specific period, they switch roles and end of a longer period, partners (usually at the end of a module/task or end of day).

And like everything in the world that follows the yin-yang principle, pair programming has it’s pros and cons. The effect of it application in a project purely depends on the dynamics of the project and the mindsets of its team. I, however feel that the pros outweigh the cons and hence will be listing down the advantages of it.

Increase discipline – Having a pair of eyes look at everything you do tends to influence people to put their best foot forward. It makes people think better and work smarter. It also tends to cut down the breaks that a person takes, since the other’s work is dependent on what s/he does.
Though most people tout this benefit as a watchdog approach, it is not so. The navigator is not a silent spectator judging every move of the driver. This approach takes advantage of the psychological fact the people behave more responsibly in the presence of others.

Better code – Furthering the first benefit listed above, since the navigator is continuously applying his/her mind to think forward, s/he tends to review the code in a better fashion and hence increasing the quality of design and code.

Resilient Flow – Having another person around helps keeping the flow of the activity and maintaining its direction. It’s easier to get back on track if the flow is disrupted. Also, pairs are more resilient to interruptions. If there is an interruption, one can address it while the other continues working.

Multiple contributors to design – Due to the continual rotation of the pairs, everyone is involved in the development of the application. This brings in clarity of design and the opportunity to improve it.

Improved morale - Due to the fact that one is switching tasks with others, it increases competition amongst the team to produce better code. It even increases camaraderie in the team.

Collective Code Ownership – Since everyone has worked on the code, there is no single ownership. Everyone is responsible of every aspect of the code.

Improved understanding of the system – Pair and rotation results in everyone having an improved understanding of the entire system and not just specific modules that they would work on if they were not paired and rotated.

Mentoring – Technical mentoring is painlessly possible using paired programming techniques. This allows the junior members to gain more knowledge that the tradition knowledge transfer.

Lower hardware overheads – Fewer workstations are required since one is shared by two people.

As mentioned earlier, Paired programming does have its list of downfalls, but industry experts state that disadvantages such as increased cost, longer turnaround times, etc are usually short term. Once the practice is institutionalized, teams and organizations have realized that paired programming eventually does result in higher and better productivity, lower reworks and hence cost savings.

For further reading, follow the links below that I have referenced:
http://en.wikipedia.org/wiki/Pair_programming
http://c2.com/cgi/wiki?PairProgrammingPattern
http://www.methodsandtools.com/archive/archive.php?id=10
http://www.comp.polyu.edu.hk/people/doc/cskcchan/pairpaper.pdf http://theagileblog.net/2005/11/stop_demanding_pair_programmin_1.html

Reading between the lines

We come across this phrase almost every now and then in our daily lives, but what does it really mean?

Very simply put, "reading between the lines" means to read the text in question very carefully; to read everything and try to find glitches or catches within it that are not very obvious.

We fortunately advocate this practice very strongly in our industry and we call the activity - Review. We do all kinds of review for almost all of our deliverables, may it be a design document, code or test cases. We do it or preach that it should be done so that we actually read between the lines to ensure that nothing unwanted is passed on with the work product that we are delivering.

Review is a combination of two words – 'Re' which roughly means again, and 'View' that means 'to see'. So in essence, to review is to see again. And the primary most common reason to see anything again is to make sure that nothing went un-noticed.

Now that the fundamentals are clear, let's look at the various types of reviews that can be conducted.

Self/Peer Review
This is one of the most basic forms of review. It is generally informal and is done where the criticality of the product in question is not very high.
In this type of review, either the author of the work product or a colleague reviews the work product.

Advantages: Since this review is informal, the overheads are vastly reduced. This means that it can be conducted very easily without any prior preparation, can be done very quickly and hence yielding in faster results. Not too many resources, human or otherwise, are required to perform this type of review.

Disadvantages: However, the absence of formal procedures also tends to give rise to absence of discipline. At most times, reviewers are either not experienced in the science of review or are tight pressed for time. At other times, individual preferences or motives influence the fairness of the results. In either case, the resulting review may at times not be adequate and efficient and thus unreliable.

Walkthroughs
As the word suggests, in this type of review, the reviewers actually walk through the entire product in question including all the possible paths. This is most effective in scenarios where the quality of the product is very critical.
Walkthroughs are conducted collaboratively by a reviewer or a team of reviewers and the author of the product. They step through each line understanding its need and impact on the overall product. This is very similar to what the coders do while debugging their code.

Advantages: Since every line is looked into for justifying its need and evaluating its impact, it can be well assured that oversight is kept to the minimum and quality at maximum. It also eliminates postulation since the outcome can be seen at the very moment. Author buy-in in this type of review is also relatively higher.

Disadvantages: If timelines are tight, then this type of review may not be the right approach as the effort expended in this activity is high.

Formal Review
This is the most formal of all reviews and effectively with high overheads. But it can be assured that the effectiveness of this review will be high. This type of review is preferred where the product is of utmost importance and a glitch of the minutest proportion can prove to be expensive.
Roles like Reader, Facilitator, Recorder/Scribe and Reviewers form a part of this activity. While the first three roles can be played by the same person, a reviewer’s role is always independent of other roles.
All the reviewers are given ample time to review the product independently. All of them log their findings separately. Before the formal review takes place the facilitator collates these findings. During the review meeting, the reader reads one finding at a time, the reviewers discuss upon the validity and severity of the finding while the scribe records the items discussed and their outcomes.
At the end of the review meeting, final defect log is prepared and presented to the author for corrections.

Advantages: Since ample time is provided to the reviewers, rush-jobs are eliminated. Many minds work better than one and hence the likelihood of oversights is minimum. Wrong diagnosis is avoided since all the findings are questioned for validity. Author buy-in is higher.

Disadvantages: High overheads. Many resources pool in their individual efforts for review and then for formalizing the findings, this leads to higher cost of the activity.

What mode of review to follow is a call that a team lead or a project manager should take. If time is short and criticality low, then one can do a peer review. If timelines are not too short, but criticality is high, then a walkthrough would be a good idea. If there are no time constraints and the criticality is high, then the best approach would be to have a formal review conducted.

Whatever the mode, the intention is the same. Keep those defects at bay.

7 habits of an highly effective estimator...

Software Estimation, as most people believe, involves breaking down requirements into functional components, weighing them and then assigning numbers to each line item based on their complexity, hoping in mind that the numbers are correct and then presenting it to the customer. While it does involve technical know-how about the technology used, estimation methodologies adopted and (in) experiences of knowing the right amount to wager, it is also heavily dependent on the subtler habits of the estimator.

Today, I do not wish to speak to you about the science of estimation but the finer art of it. And unlike science, every art can be mastered if you practice enough and of course live long enough to master it.
Imbibing these habits, I believe, will make a good estimator a better one.

• Don’t do it for others – Don't waste your time estimating for projects, if your primary purpose is to please others. Most people indulge in the act of estimating (yes, it does sound shallow) simply because they are told to do so – either by their bosses/organizations or their customers and if they do not, they possibly might tick them off.

Remember, that estimating in software projects is more of a benefit to you than it is to your customers. Yes, it does help your customer to allocate their budgets or make a selection; but more importantly, it allows you (or your organization/team) to know if the endeavor that you are planning to undertake is a feasible one or not. It also allows you to plan your projects better, period!

• Do it for others – In almost all cases, the estimator is not the person who faces the brunt of bad estimation. Without offending anyone, these are usually people higher up in the food chain such as the managers. If the estimation does go wary, it is the lines-men who will have to pay dearly by working harder, faster and longer.

Do these guys a favor. Do the estimate in a way that these folks do not pay the price that your customer refused to pay for.

• Ask for time – "Easier said than done", is what is on your mind right now and it doesn't take a psychic to figure that out. Most of the times, we deliver under unrealistic time pressures just because we are afraid to say "No".

Understand this; it is the prerogative of the customer to demand haste. That is what all of us do when we are wearing the customer’s shoe; but we do realize that if we want quality service or product, waiting a little while longer can be fruitful. Americans or British (or for that matter, customers across the globe) are no different than you and I. If you can convince them that by giving you extra time (I’m not saying ask for a millennia to give them an estimate), you can provide them with a more realistic estimate and fruitful service, they are more often than not, willing to give it to you.

• Build Confidence – Well, this habit should chronologically come before the previous one, but I felt that our bigger problem was time-crunch rather than trust.

The first and foremost thing that a customer does with the estimate is to look at the bottom of the page. And depending on the number s/he sees there, one of these three impressions is formed:

“This guy has no clue of what needs to be done” – in the case where the estimated figure is much below expected
“This guy is a con!” – in the case where the estimate is way too high
“Maybe this guy just got lucky!” – in the case where the estimate is realistic and to his/her liking

In either case, you are damned from the word "go"! To explain to them why you put the numbers you put, will take time. Take time to do it right so that you can justify the numbers when they give you the time to explain.

• Stop and smell the roses – This phrase usually means seeing the finer (and beautiful) details (by taking out time). That is what you should do when you are in the process of estimating.

Take the extra time that you asked for to see finer details in the requirements. Ask questions instead of assuming. Listen to the answers given by the customers. Gather as much data as you can. And then, only then, start your analysis.

• Stand up straight – Don’t lean forward and do not bend backwards.

What I mean by this is that you will need to be assertive in your observations and reports. Don’t be aggressive; there-by forcing yourself down the customer’s throat. Don’t be submissive; there-by underestimating. If you have done it right, you will not feel the need to be offensive or defensive in the situations. Your work will speak for itself.

• Believe – in yourself, in the organization and in the team.

The first rule of selling is to believe in the product/service that you are selling. It might not make a difference when you have a quality since birth that enables you to sell spectacles to a blind man; but if you are average Joe – you must believe in what you are selling.

This confidence in the product comes when you believe that you have a team that will back you up on it. Belief in the team and their ability to achieve will help you make realistic actual estimates without the need to pad up your estimates.

All the habits that I have mentioned here are linked to each other. You cannot succeed at one without succeeding equally at others. And remember the golden rule of estimation – "Bad estimates will haunt others and you for a very long time to come". Okay, I made it up, but it’s still true, isn't it?

Adapting To Change

Understanding Change

Adapting to any change requires a change in the way one behaves or thinks. The change in question may be adapting to newer platforms, technologies or methodologies. Remember the year you shifted from programming in COBOL to C. After months and years of programming you were used to typing:

IDENTIFICATION DIVISION.

PROGRAM-ID. HELLOWORLD.

ENVIRONMENT DIVISION.

CONFIGURATION SECTION.
SOURCE-COMPUTER. RM-COBOL.
OBJECT-COMPUTER. RM-COBOL.

DATA DIVISION.

FILE SECTION.

PROCEDURE DIVISION.
MAIN-LOGIC SECTION.

BEGIN.
DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
DISPLAY "Hello world!" LINE 15 POSITION 10.
STOP RUN.
MAIN-LOGIC-EXIT.
EXIT.

And then one fine day (well, we all know that particular day wasn’t so fine), you were expected to type this:

#include

void main()
{
printf("\nHello World\n");
}


If the first draft of our code had undergone a QA process we would have definitely received a defect log longer than the code itself. But fortunately, our ability to learn and grasp came to the rescue and helped us prove our worth to the organization.

But we failed to realize that sub-consciously we not only learnt the newer language, but also simultaneously un-learnt all the habits that made us good COBOL programmers and learnt the habits that would make us good C programmers.

We somehow got the habit of typing a ‘;’ instead of a ‘.’ after every statement. We picked up the habit of indenting after a ‘{‘ or ‘}’; and many similar tit-bits.

If you can’t relate to switching between COBOL to C, try and picture yourself when you initially learnt driving. From the point where you made mistake unknowingly (like shifting to the wrong gear), to making conscious improvements, to the time you can drive on a freeway without looking once at your gear stick.

Paradigm shifts are always a little difficult to adjust to, especially; if you have to stop doing something that you have been tuned to do for many years. My mother initially had still has problems with mobile phones. She now faced additional buttons, instead of the traditional 13 (twelve on the keypad and one switch hook on which the handset rested) on a regular telephone instrument. Now there was a different button to pick a phone or dial and another to hang-up. There were also buttons that activated the phonebook, the menu, or the volume of the speaker. The additional functionality confused her even more. And this happens to every one of us as demonstrated by the example of code above.

Understanding the Life Cycle of Change

What we need to however understand the mechanism that defines the success or failure of this adaption. Understanding this basic principle will help us adapt to changes faster, especially if the change is as large as shifting from traditional software development to the agile way.

Every change that we encounter has its own life cycle. We start with making conscious effort to implement the changes. In the programming example above, when we migrated from COBOL to C, we sub-consciously type “IDENTIFICATION DIVISION.” at the start of every code file, since it had become a habit over the years. We at once might have realized our mistake and changed that to “#include ”; and there on consciously make an effort to not repeat the same mistake again.


This act of trying not to make the same mistakes and typing the right syntax slowly is imbibed by us and it becomes a part of our Conscious Habit. At this stage we are still consciously type the right syntax. As time goes by and you have over hundred code files under your belt, you would without realizing, type the right syntax and not bother checking it after every line you wrote. This is the last stage of change – The Sub-Conscious Habit.

Moving from Waterfall or traditional Iterative Development to the Agile way is no different. But now, since we have a better understanding of how our mind adapts to changes, the following process might seem logical to you.

Sub-Conscious Acts

• Start typing a detailed business requirements or design
• Start coding first and then worry about test cases
• Plan to deliver after a long gap
• Have lengthy meetings to discuss status
• Micro-managing your team
• Assign different tasks to specific individuals and make them work in silos
• Pay more attention to documenting rather than making the software work

Conscious Effort that turns into a Habit

• Stop detailing your requirements or design at the start; just have enough to get work started
• Write test cases first and write code to satisfy those test cases
• Have shorter frequency of deliverables
• Have short meetings and discuss only relevant points
• Allow the team to organize and manage themselves
• Have all the members of the team work together; occasionally rotating them within the team to enable them to learn newer skills
• Have working software first

Making the change

At the start of the adopting the agile methodologies we inadvertently would revert to our old ways. Programmers would start coding in silos while architects did their work in their own little shells. Project Managers would assign and follow up on tasks; People will skip meetings due to their bitter experiences of lengthy unfruitful meetings in the past or simply because they are not used to having daily stand-up meetings.

Whatever the sub-conscious act may be, one needs to start making that conscious effort to do things in a new way. With constant and vigilant practice, the conscious acts will soon become habits. And it is this level that we need to reach.

What else?

But just practicing over and again is not enough. There are three qualities that need to be learnt or adopted in order for the change to succeed. One is Patience and the other is Discipline and the last one is Belief.

You will need to understand that every change has its cycle as mentioned above and that this cycle will have its own duration of completion. If you try to cut the duration short or take shortcuts to achieve the target sooner, in all likely-hood you will fail. Conscientious Discipline enables you to pursue this change all the way to the end by following the principles of the change and not wavering from it in times of pressure.

And none of this will make sense or work if you do not believe in the change; whether it is a doubt on the benefits of the change, on your capabilities or the approach that you take. If you find yourself in a position where you do not believe, take an expert’s opinion or advice, discuss it with peers or seniors – do whatever is necessary to help you believe in it. Without this resolute belief do not attempt to make the change.

Of the monster called software requirements...

There was a joke I heard long back of which I vaguely remember only the end. Well, the joke wasn’t funny, but the ending caught my attention, and it goes like this:

'So, the software engineer goes to heaven and meets St. Peter. At the pearly gates, St. Peter asks the young fellow, "Since you sacrificed your life, you are granted one wish. What is it that you want to ask for?" The young man said in an instant, "Please help all customers in the world make up their minds…"'

While, I didn't laugh at the joke told to me by a banker friend of mine, it did get me thinking, "Are software requirements so much of a known problem that even bankers are cracking jokes on it?"

I did not get time to research to answer my own question until some time back.

Are software requirements really a problem? And why is requirements management in a software project considered to be problem?

The answer to my question does not really point only to software requirements. There are a lot of activities that can be attributed to failure of a software project and requirements are just one reason. Nonetheless, it is a key reason since that is what sets the direction of flow.

The effects of wrong or bad requirements cascade down all the way to the product which can lead to critical customer dissatisfaction. This is so well understood that there is no need to demonstrate it. But what is more important that asking the two questions above is asking, “Why requirements are poorly captured or developed?”

Let’s see why:

1. Poor communication: Even the advent of technology has not helped mankind to communicate effectively with each other. We have emails, telephones, video conferencing systems, faxes, text messages over mobile phones today to help us communicate, but with such technology comes its own baggage of pitfalls. We still have to consider tones, languages, cultural differences in words, accents, and gestures. We have a smart bunch of people in the world working 24/7 to come up with newer acronyms, terminologies and short texts which are not accepted as fast as they are developed. Not to disregard, that most times the technology itself fails and creates a huge break-down in the communication channel. This leads to a huge gap between people who are speaking and those who are trying their best to listen.
2. Individual intelligence and perceptions: The thing that separates us from our closest relatives is higher intelligence. And it is this natural wonder within us that sometimes causes us to fail. People usually feel compelled to think outside the boundaries of rationale thinking. While this is good when you are trying to prove the String Theory, it is absolutely not, when you are trying to understand customer requirements. People try to be poetic and refuse to call an apple an apple.
3. Inadequate documentation: People have a misunderstanding that processes require you to capture as much documentation as possible. The reason why this is a 'misunderstanding' is because a good process will not talk of absolute documentation, but adequate documentation. If one line was sufficient to write a world class application that meets all quality standards, business objectives of your organization, and client’s expectation, then one need not write the second line. If not, then one has write as much as is necessary to get the work done properly.
4. Variability Factor: I keep saying this over and over again and will take the liberty of doing so one more time. Customers have the right to be fickle minded. But Customers, understand this, the more you change your mind during the journey, the more likely it is that you will reach the wrong destination.
5. Bad Estimation: The blame for this cannot be singled out to one particular person or team. Collectively, it is the initial stakeholders of the project that are to blame. Some want to control budget, others time, someone else wants top quality, while the vendor teams want to save the contract(s). It is pretty obvious that one can’t please everyone; hence creating an estimate to do exactly the same would be foolish. The stakeholders need to come to a common understanding and a reasonable trading-off on requirements needs to be done before estimating and be committed to it once it is done.
6. Ineffective Change Management: Even with all the stability in requirements, we must understand that software development is an evolutionary process. Unlike other industries where requirements can be frozen at the start of the project, ours tend to be empirical in nature. While we should try and freeze most requirements, we should also concentrate on having a good system in place to manage these changes. But currently, in most projects this process is not as strong as it is supposed to be. This final problem encompasses all the problems listed above.

Determining the right approach can be tricky, but not so tricky, if you understand where the problems lie. The list above is just to get you thinking in that direction and find the right mix of people, process and technology to overcome this very common hurdle.

Of a start of a new journey...

Been thinking of setting up a blog for a very long time. A blog where I can write about the things that happen in office, my thoughts about and views on them. This is where I want to jot down events or thoughts, whether they are funny or frustrating; but will not contain names of people involved in the story in order to protect their reputation.
Will try and post as and when I can or when an event occurs that I just feel that I need to add to this memoir. Please do come back again, leave a post or just sign up for the feeds.