http://musingsof.raviwarrier.com

Visit me here! I am no longer writing stuff about work, but generally about things that come to my mind!

More than one can take...

This blog was supposed to be where I can vent out of frustrations about work and simultaneously give solutions or reasonings about the problems faced here; but I just can't take the crap anymore.
What is this world coming to? So much hatred and violence, where do these people get there fuel from?
I recently read about a nun being gang-raped in Orissa and then was made to parade around naked, while the facist saffronites yelled - "Bharat Mata Ki Jai". That last line really got me think on how perverted these people's sense of religion and patriotism. How can one even think of praising the "mother" when one is forcing himself upon a woman and shredding the bits all the dignity and respect that she carried with her. How can this glorify the motherland and womanhood?
The Bajrang Dal, that as far I can understand, follow Hanuman as their deity. When did they ever think that Hanuman would even think of raping women, humiliating them and killing innocents? 
My question is that don't these people even stop to think about what they are doing? Has the world gone so sour that all that remains of people's mind is curdled filth? Who gave them the idea that terrorizing, murdering, raping and ransacking houses of others is what the Hindu relgion is all about and that it OK for them to wear the saffron colored clothes and conduct such heineous crimes against humanity?
And if the entire country is questioning the morality of muslim extremists, why aren't we questioning the morality of hinduism and the so called saffron brigade? What makes these actions bad for one and acceptable for others?
Personally, I still believe that people in general are just a huge group of monkeys. It is the leaders, both spiritual and political, that have the responsibility of making these monkeys into humans. I know that not much can be expected from the class of politicians that we have, but I have thoroughly disappointed with the so-called "swamis", "sadhus", clerics and priests. What kind of understanding of the religion do they have and what are they imparting to these monkeys?
Today, I read the news that the Singh government is moving to ban the Bajrang Dal. My stand is that these guys should be caned first and then taught the meaning of Hindutva.

A Quality Partner's Role in a Senior Management Review

Yesterday, my boss and I had another difference of opinion. He had attended one of the delivery reviews (that's what sr. mgmt reviews are called where I currently work) and was shocked by the quality of the review. He was disappointed at the fact the senior manager did not ask questions pertaining to metrics, did not ask questions on how the plans were created, how effective was the tracking ,etc. He was even more so disappointed at me for not asking the questions myself.
Later after the review he called for a meeting to tell us what our role in the delivery review is supposed to be. He spoke about how the consultants (here we are called Quality Partners) should take charge of the review if the sr. management is not effectively conducting it and gave some wild anologies as usual.
I defended myself by saying that a delivery review is to be conducted by the delivery head and I ask questions that spin off from his where his questions are not rightly answered, or if he does not go deep into the topic. Most of the times, I list out the questions or concerns that I'd like him to look into and hand it over to him before the review to kind of point him in the right direction; and moreover, some senior guys don't like it if you butt into his review, no matter how good a job you do!
Also went on to tell him that all the questions that I have to ask of the project manager, I ask during "my" process reviews. He was not convinced. He said we had to be proactive and bring them on line.
If we are to do the delivery head's job today because he is incompetant, next we'd have to take on the engagement managers' work and then the project managers'. I asked him where do we stop. Instead of eradicting the root problem, we are just fueling it to get worse, because now we are slowly relying lesser and lesser on those seniors' ability to review the health of the project.
Since, he didn't have much to say on that (at least I think so), he said that I am still at fault here because I don't assist the delivery heads by sending them the fortnightly report which is a part of my job. I agreed that I don't send the report, but I do give them a heads up by listing out my concerns for them to address. But that, as per my boss, is not official and formal. So I had to agree again.
Now let's see, my boss, not only wants me to "proactively" do someone else's job, but continue doing what I do at my level. I think to myself, fine let's give this idea a try.
The boss has a talk with the delivery head in the morning today as he was going to conduct a review for another project. He tells the guy that it is my job to ask questions and that at times I will ask questions on his behalf and that he should not take if personally or offensively if I ever supersede him in directing the show.
What the delivery head hears is that it is my responsibility to ask questions in the review and that he can jump in whenever he wants to. He said to me that this is what my boss told him. I know!
Readers, the quality partner, process consultant, quality analyst, whatever he may be called is supposed to be the trusted advisor to the delivery. He is not the person you see standing in front in the meetings. He is the person standing behind the chair and giving information and advice to the person who is actually conducting the meeting. One thing my boss said is right - you must provide the delivery head with data. I completely agree. I also agree, if you live in the world of fear and need to cover your backs, then the communique between the two of you, needs to be official and formal; but nevertheless, whether formal or not, this information needs to reach him before he reviews.
To summarize, the role of the consultant in the senior management review is:

• Give information/status of the project before hand. You may supplement this with risks/issues that you foresee.
• Ask questions if the questions are not deep enough or if the answers are not satisfactory, basically assist in asking questions
  
• Correct him or the audience if their perception on some things is incorrect
• Make notes

But to take over the meeting is a no no! You are setting the wrong precedence and example. You are creating wrong perceptions as to who is in charge and who is affected by the problems of the project. Moreover, don't we always talk of management commitment; well if you are the one talking and questioning, how does one know that the senior management wants to get things done!
Think about it!

Using the Task Usage effectively

My organization recently adopted an Integrated Project Management (IPM) enterprise system. And more recently, underwent an upgrade where the scheduling (using Microsoft Project Schedule) and time entry modules were rolled out.

Naturally, due to the new change that enforced stricter rules for scheduling, the project managers were confounded with the way they were supposed to enter, schedule and allocate tasks in the project plan.

Two days back, a project manager tells me about his problem regarding the issue. His project, which he claimed is different than others (only if I got pennies everytime I heard that) gets a list of defects from the customer on a daily basis. His team is supposed to analyze, fix, verify, validate and deploy the fix for every defect they get. His problem is that the customer is "finicky" about this list and changes the priority of the defects midway, causing his team to drop the current task and take up a new one. His statement was that Microsoft Project was not helping him plan and track his team's activities efficiently and that he'd rather get back to the Excel based tracker that they used earlier.

I have rarely found a situation at work, when we can use the adage "Ignorance is bliss!" and in this project manager's case, the adage definitely did not fit.

Here're the premise of the scheduling he performed and different solutions I gave him:

Premise: Each defect is a single task item or a summary task depending on its complexity. Smaller/simpler defects are entered as a single task, while the more complex defects have sub-tasks such as "Analyze", "Fix", "Review", "Test" and "Check-in" as a milestone task.

If needed, various resources could be allocated to the individual sub-tasks or it could be the same resource. Individual task or sub-tasks are allocated planned effort (work) and the resources are leveled (over-allocations are resolved).

The customer wakes up in the middle of the day and asks that one particular defect be put on hold (defer it) or should be dropped (reject it) and work on any other defect.

Solution 1 - Scenario 1:

If the developer has worked on the defect and/or logged partial time for the amount he's worked for, then while entering time for that defect, he must mark the task as "done". Our IPM system updates the task as complete and logs the actual time against the task in the schedule. For the readers, who update the schedule manually, the process is the same - mark the task as complete and enter the effort (if you record "actual work" in the schedule) put in the task.

If the new defect is in the schedule, well, nothing needs to be done, otherwise, add the defect in the schedule and assign it to the developer (of course keeping the resource leveled).

Solution 1 - Scenario 2:

If work on the defect has not yet started, then simply one can either delete that task (not such a good idea as there would be no simple way of tracking of such a change later) or reduce the "work" for the task to 0hrs and mark the task as complete. That way it does not affect the overall project, except for its dependencies.

Solution 2:

This solution is a little tricky and will require good working knowledge of the Microsoft Project. If you are not confident about making changes to your master plan, make a copy and carry out the steps.

Project allows (as do many other scheduling softwares) the project manager to contour the task. Contour as the word suggests is the shape of the outline/surface of the object, in this case the object is a histogram of the work spent on the task each day. See the image below (not created in MS Project).

 

The top border (or the surface) of the histogram defines its contour, but I'm sure you figured it out already.

So, MS Project allows the following contours for each task:

1. Flat - Effort equally distributed
2. Back Loaded - Amount of effort gradually increases as the days go by
3. Front Loaded - Amount of effort gradually decreases as the days go by
4. Double Peak - The effort peaks twice during the life of the task
5. Early Peak - More effort is expended early on and then the amount stabilizes as the days go by
6. Late Peak - The effort is stable early on and then peaks towards the end of the task
7. Bell - This, if it is not wrong for me to call it so, can be termed as "Middle Peak"
8. Turtle - This is similar to the 'Bell' contour with the difference being that increase (during the early days) and decrease (during the later days) in effort is gradual and does not show peaks. Very similar to a turtle's back.

Selecting one of these contours will distribute the effort of the task as required in a ratio that Project calculates for you.

This can be done in the 'Task Usage' view (click on 'View' in the menu and then click on 'Task Usage'). Identify the task that you wish to work on, expand it (by clicking on the '+' sign next to it) to reveal the resource(s) assigned that task. Select and right-click on the resource(s) and select 'Assignment Information' option to see a dialog such as the one below.

 

It is on this dialog you will see the drop-down for Work Contour. Select one and proceed.

If you don't like the distribution the Project has set for the task, you are free to change the effort planned for each day in the pane on the right. In which case the indicator next to the resources will show icons like the following, indicating a custom contour.

 

So, if the task is put on hold for a definite duration, change the contour or task usage to reduce the effort spent on that task for those days to a minimum or zero.

This way, you don't lose track of the tasks nor do the resources have to enter time against (or work) on those tasks for the period of lull.

Should we SCRUM?

It is that time in the life of this industry when something new has passed the horizon and is approaching us at top speeds. Later in the last century, it was CMM, followed by CMMi in the early years of this one. This era of evolution sees the dawn of Agile practices.

Agile practices have been around for over a decade now. The industry just took it’s time shifting gears around it, slowly and steadily now advancing towards top gear.

We are all aware of what Agile practices in software development means, perhaps in its entirety as the authors of these practices intended it to be, or in some corrupt deviant phenomenon. We, as the flock of IT industry, believe this is the silver bullet that will release us from the clutches of software development hell. We also believe this one to be more silvery than its predecessors.

But remember this; this is exactly what the creators of this so-called weapon say it is not. There is not one piece of literature that states that Agile practices (in whatever form) are silver bullets that can magically kill all evils and make your life better.

SCRUM is one methodology that is based on the Agile philosophy. SCRUM, as I see it, is an excellent framework to improve overall project’s performance and provides good practices for Agile Project Management. It talks of well defined roles, limited number of artifacts (for project management and not as a part of the technical package of the project), and clear and concise rules on how each iteration needs to be executed.

It is not difficult to understand SCRUM. It would take less than hour to give a novice enough insight on SCRUM, to enable him/her to understand all its concepts. The difficult part, as with anything else in the world, is implementing it. And moreover, implementing it in services based IT companies.

While I evangelize SCRUM from the deepest corners of my heart, I have to but point out the fallacies of force-fitting SCRUM in places where it is not welcome.

Before we continue, let me lay down in front of you the scenario that I am considering while presenting the counter arguments of the implementing SCRUM in IT services industry.

“An organization, ABC Limited, is dedicated to providing IT solutions to its customers. The organization has many clients across the globe and is making/or has made its presence in the world of highly competitive market of providing services. It is a vision of this company to increase its size by another couple of thousand by then end of Financial Year 2009. It also aims to increase its revenues by 15% year over year for the next five years. The space that it operates in is also occupied by the top IT giants of India and hence has everyone fighting for the same piece of the pie.

“As with CMM and CMMi of yesteryears, the company now faces the demand from the western world to deliver their services in a SCRUM fashion. CxOs of client companies all across the globe have attended at least one conference in the past three years that showcased successful products that were developed in an SCRUM environment. Over the next couple of months, the CxO asks his/her executives to research and provide him/her with details of SCRUM framework and its benefits. The executives attended more seminars that evangelized SCRUM and came to a conclusive report that the organization must ask its vendor ABC Limited to adopt SCRUM.

“As with any wild eco-system, where “survival of the fittest” and “evolution by natural selection” are the ground rules to survival, IT companies, specifically, ABC Limited, changes it processes to incorporate SCRUM’s practices.

“Taking a more optimistic picture, the company ABC Limited, spends valuable resources, to dig deep and clean and modify its processes from the roots, rather than just batch renaming their processes to “agile”-processes. Come launch day, a brand new project (of a customer that demanded SCRUM) is asked to pilot it.

“The project team is trained in the specific workings of SCRUM. They are told:

1. Thou shalt not change thy commitment during the Sprint
2. Thou shalt have Daily Scrums for the team members to update each other on progress and impediments
3. Thou shalt have a ScrumMaster, who shall not manage, but facilitate
4. Thy Product Owner will not interfere on a daily basis (micro-management)
5. Thee and only thee is responsible for estimating and taking ownership of tasks and deliverables
   

“When the project starts the worker ants get busy. All motivated by and enthusiastic of this new framework, they are confident that they will be able to achieve all their targets. All is well until, the customer calls to change a specification and the team is asked to accommodate the urgent request in the Sprint. Next week comes, and the customer has more changes. Slowly, by the last sprint, changes are common, re-work is high and the team’s confidence on SCRUM is low.

“In the meantime, the project manager in his new avatar as the ScrumMaster has been trying to manage and control the team throughout the execution of the project. He ends up estimating and assigning tasks to the team. The Product Owner starts demanding daily status reports on the progress of the team which now becomes the main agenda of the Daily Scrums.

“In time the project fails to meet its desired state and the customer blames the team, who in turn blame SCRUM.”

This is not an out-of-the-blue case study. It is pretty much the fact across all organizations that claim to be Agile but in all practical sense, are not.

Adopting agile practices, in this case SCRUM’s practices, is not about adopting only what is felt beneficial, but all the practices as a whole. It is a package deal. It is not about just renaming processes to hoodwink customers into believing otherwise.

Neither customers nor the teams working on projects are at a liberty to discard or adopt practices as they feel fit.

Adopting SCRUM has a lot of advantages – both for the team as well as the customer. But for it to be successful, it needs to be understood completely by both parties.

Both parties need to understand their respective responsibilities in this game called SCRUM. Customers need to understand that micro-managing, asking for daily status updates and changing requirements on the fly is NOT allowed. Project teams need to understand the severity of their commitments to Sprints. And it is a Catch-22 situation.

Customers do not have confidence in commitments of project teams to go blind for the length of the Sprint and hence feel the need to micro-manage. Since, the project team no longer self-manages itself and the Sprint, the commitment they make is no longer strong.

So, this brings up the most obvious question in our minds. Where can true SCRUM practices be implemented? My most unintelligent guess would be – the Product companies. The teams (including all the way to the VP of the product) in such companies have more control over the features, technology and the execution process than typical service companies. While they still have market pressures, the buck still stops within the organization and that makes all the difference.

To support my argument, I have not come across any presentation or article that has a list of service companies in the list of top users of SCRUM. It may however list a part of the service company that is considered to be, not a vendor or a partner, but an extended arm of the customer’s development team itself. In that case, there is not too much of a difference between the customer and the offshore development center of a vendor that it controls.

Bottom line

For the apparent business reason, it is very difficult for a service company to say ‘No’ to its customers. It is even a bigger challenge to ask them to hold on to the change requests till the end of the sprint. And unless the customers are themselves geared up to speed, this golden rule of SCRUM will inadvertently be broken.

And this is the real reason why SCRUM cannot be implemented in IT services companies; at least not without making real changes in processes of both the vendor and the customer. And until someone comes up with a model that suits this kind of multi-location contract based development, I’d recommend not forcing SCRUM down our own throats and make it another CMMi-like fad.

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.