There are several development tactics introduced by Agile. Most tactics focus attempt to minimize and/or expose risk in developing software in short amount of time. Iteration is the development of software in one unit of time, and this may last from one to four weeks. It includes planning, requirements analysis, design, coding, and testing. Software developed during iteration need not be functional enough to be released as a product in the market, but the objective is to have working software, without bugs, at the end of each iteration. The team re-evaluates the project priorities at the end of each iteration.

Traditional outsource challenges are amplified and new challenges are created when software development is taken offshore. These new challenges are mainly in cultural differences, combined with the communication difficulty due to the difference in time and language comprehension. Most importantly, the biggest challenges remain in communicating, transfer of business logic understanding, demand in co-operation in poorly defined projects, unknown and imprecise requirements and lack of customer involvement, differences between customer and vendor, geographical distance, and many more. To be successful with offshore software development, these hurdles need to be overcome by both the onshore and offshore teams.

In plan-driven and Agile as well, face to face communication is stressed to improve communication and understanding of the project. This type of face to face time takes place during each iteration, where plan-driven project is concerned and this took place essentially at the beginning of the project. When face to face time is not possible with the offshore provider, it is beneficial to have each developer answer 3 daily questions: what you did yesterday? what you plan to do today? describe any roadblocks or obstacles in completing the iteration stories? Each developer should answer these question and not simply the offshore project manager. Perhaps the offshore project manager can help in translating the answers to these questions.

In case of Agile, face to face meetings are held at all time, usually in the form of daily Scrums, pair programming, iteration retrospectives and iteration planning. In distributed development teams, many times the onshore managers travel offshore to hold meetings with the offshore team, or in other circumstances, managers from offshore travel onshore for meetings. One important influence depends on the offshore person visiting the onshore team to absorb the project details and develop/foster relationships. He should take this know-how from the onsite team in a way that he is knowledgeable enough to answer many questions raised by his offshore team. In addition, he should be also capable of relating to his team members about the decisions that were taken in his meetings with the onsite team. Depending upon the complexity of the project, a member of the onsite team, with good knowledge in business logic is often sent to work offshore.

In implementing Agile projects, a series of processes are utilized. The development process is not just a single approach. In implementing software offshore development, there are some principles that are followed, which have been termed as Agile Manifesto. These are as follows -

➢ Customer satisfaction is achieved by rapid and continuous delivery of useful software.
➢ Quick delivery of working software within weeks rather than months.
➢ The principle measure of development progress is derived from the working software.
➢ Any changes in the software may be incorporated later.
➢ Necessity in having face to face communication for better understanding.
➢ Maintain close relationships between the business people and the developers.
➢ Motivation and trust on the individuals make the project implementation successful.
➢ Apply continuous attention to the project design, and try to attain technical excellence.
➢ Adapt fast to changing circumstances.

It was found that the iterative framework brought benefits to Agile software development vendors. By this approach, the customers could make payments after each iteration. By paying this way, the customer does not lose or be in a risk to pay the for the whole lot after the completion of the project. This brought in commitment from the customer to provide the vendor with better business and motivates the vendor to consider each iteration important. The method of continuous feedback and communication helps in the offshore development process, but the approach of short iterations has proved to be especially successful.
Another aspect of Agile development is the importance of testing in each iteration. Each iteration should produce automated tests that can be used during each iteration and future iterations as well. The benefits of automated testing is better covered in different articles. However, in the context of this article, it is important for your offshore vendors to deliver automated tests with each iteration. When considering new vendors, ask about their testing strategies. It is better to go with a vendor who believes in automated testing, rather than trying to convince a vendor the benefits of automated testing.
So, in sum, when implementing Agile in distributed development teams, there are opportunities to address three aspects of the project: communication, payment/deliverables and automated testing.

Related posts:

1. How to Implement Agile Offshore Development
2. What is Agile Software Development?
3. What Every Manager Ought To Know About Agile Development

It is part II in examples of original article outsourcing:

————————

Daily scrums in offshore software development

The concept of Agile software development has given another dimension to software engineering, and this has helped the process of development to promote irritations through-out the life-cycle of a project.

Editor’s note: You won’t catch me claiming to be the world’s greatest Agile coach, but I believe the word should be “iterations” not “irritations”

Most of the methods in Agile development looks for minimizing the time required for the software to be developed and implemented. To achieve the success in any software development process, daily scrum has become an essential part of the entire system, providing a simple rule in achieving success in the different aspects of project development, such as, planning, requirements analysis, design, coding, testing, and documentation.

In an Agile software development, there are processes designed to add energy focus, clarity, and transparency to the development process of the project. This process is termed as scrum. It is a set of simple rules that organizes the software team to increase the speed of software development, organize the objectives of project development, create a performance driven culture, uphold the values of the stakeholders, maintain stable and consistent communication at all levels, and enhance the development process of each individual, there-by improving the quality of life.

Daily scrum governs the very characteristic of a software development process. It is a “skeleton process” that defines a set of rules which are practiced by the software team, in which each has a predefined role to play. Within the scrum, there is one scrum master, who plays a role similar to that of a project manager. The scrum master is responsible to maintain the processes. The product manager owns the project, and looks after stakeholder values and represents the software development team.

The product backlog consists of a set of highly prioritized set of requirements of work to be done. A sprint is a period, of may be of 20 to 30 days as decided by the scrum team, and during each sprint the team makes ready an increment of shippable software. It is from this product backlog that the set of features go into sprint, and the features to include are decided by the sprint team during the sprint planning meeting. The scrum leader at this meeting puts forward his suggestions regarding which features he wants to be included in the sprint, and the team determines how much of these features they can commit to be included in the next sprint.

During the sprint, meetings are held each day and this is known as the daily scrum. The daily scrum has specific guidelines to follow. These include -

• The meeting should start precisely at pre-determined time, and there are punishments for tardiness.
• Meetings are all limited to 15 minutes without any regard to the team size.
• All the members attending the meeting should stand.
• The meetings should be held at the same place and at the same time everyday.

During the meeting, there are three questions that each team member should answer, and these are:

• What have you done since yesterday?
• What are you planning to do by tomorrow?
• Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)

A brief sprint retrospective is held after each sprint meeting. In this meeting the team members are required to reflect on their activities about the last sprint. This ensures the very purpose of this retrospective meeting in keeping the continuous improvement process alive. This meeting is time-boxed for 4 hours.

Daily scrum enables a self-motivated team to be organized. This encourages the co-location of all team members, improves communication amongst the team members, and places a disciplined software development process into action. Principally the scrum understands that the customers can change their thoughts on what they want and need, and that the changes cannot be successfully implemented in a traditional predictive manner. In this matter the scrum takes an emperical [sic] approach to this problem. In accepting that the problem cannot be well understood and properly defined, the scrum team focuses on the ability to deliver quickly, and respond to the upcoming requirements.

—

huh?

Related posts:

1. How to Implement Agile Offshore Development
2. Three Ideas to Consider When Implementing Agile with Distributed Development Teams
3. What is Agile Software Development?

Agile methodologies such as XP, Scrum and DSDM have been adapted by the extended teams of successful global organizations, thus improving their customer needs and time to market. In the process, the organizations gain faster experience of transfer, training, transition planning, goal setting, governance, including the method of reviews which are necessary to achieve results. Deployment of Agile development methodologies in multi offshore environment can be challenging, and research has shown that with the required modifications, the adaptation of the development process in multi-locations and time zones, offshore engineering has been able to deliver quality and productivity compared to the established Agile teams in the US, and that too in just three months. This achievement includes reduced calendar time in incorporating new features, feedback from the early stage of development, along with the ability to make critical course corrections.

Agile methodologies are a new process adapted in today’s software development processes and practices, which introduce the changes in requirements by delivering the software in small releases. This has kept high the customers’ confidence, who can now relate their business requirement changes much faster. Agile methodologies have introduced a new set of software development processes and practices, which provide requirements change through delivery of the software in multiple modular releases. This increases the confidence of the client and enables them to relate any of their requirements of business changes much faster. The global economic situation has changed software development strategies, and the larger IT organizations are changing over to offshore development at a much faster rate.

In an offshore development process it is not necessary for the offshore and onshore developers to be in constant touch and communicate regarding the progress of the development of the project, and its specific feature or function. To give you an example, it is a waste of time for the onshore and offshore developers to check the same codes in the same section of the code repository, and eventually affect the work by checking each other’s code. With the offshore team having competent self-sufficient business analysts, programmers, QA staff, and technical writers the work can be conducted indecently by them without the necessity of much communication between the offshore on onshore developers.

The important thing in any team work is the interpersonal relationships within that team. With the Scrum teams distributed throughout the US, and the offshore locations, there are few interpersonal working understandings between the teams with few or none live contacts between them. This can invariably affect the software development progress in the quality of its production, and there could be questionable deliverables. To solve this situation, basic team building exercises need to be taken up. In doing this, the offshore Scrum team could be sent to the US for few weeks, where they can observe the dynamics and other typical working characteristics of the US teams situated at different places, and this could help in building the much wanted working relationship between the Scrum teams. In practice, it is found that a US based engineer visiting India every two months, and inter-acting with the offshore team in India. There-after, a tram of Indian engineers is lead to visit the US every six months to interact with the team members in the US. This brings about an understanding between the two teams, in working relationship and from a cultural and morale-building perspective as well.

Related posts:

1. What is Agile Software Development?
2. Using an Agile Software Process with Offshore Development
3. Three Ideas to Consider When Implementing Agile with Distributed Development Teams

Editor’s Note Lean Manufacturing Management process has been adopted for software development. Lean software development will be covered in future articles.

Finally, speed of processing and delivery are emphasized. At the same time, central feature of lean manufacturing remains on the supplier structure that significantly reduces the number of companies a manufacturer deals with directly. Consequently, lean manufacturing is characterized by close relationships as well as frequent interactions with suppliers. Thus, in 1970th there was a process of reorganization of the supply chain in United States. In Japan auto assembly and production parts are located in several core industrial regions such Tokyo and Yokohama. At the same time, concentration of suppliers in United States is not as intensive as in Japan.

Thus, implementation of the new management technique is closely related to size of the country. In United States, there are two types of suppliers – captive and independent. When lean manufacturing management was implemented in the United States by the Big Three automobile manufacturing companies, captive suppliers were concentrated in the Midwest. Even today, as a consequence of implementation of the new technique, geographical representation of suppliers remains similar to the one that was introduced in 1970th. While Ford historically operated with a centralized model of production in Detroit and Dearborn, now company’s parts are clustered in Michigan and Ohio.

On the other hand, General Motors used to have multiple centres in Michigan, but soon after implementation of the new management technique, the company moved the operation process to the Midwest by purchasing independent supplier companies. Thus, before World War II, captive suppliers of automobile manufacturers have been largely clustered in the Great Lakes Region. However, after the new strategy was implemented, unskilled production process was moved to the south.

Related posts:

1. Outsourcing A Source To Create Competitive Advantage
2. Quality Certifications and What they Mean in Software Development
3. Six Sigma In The Software Industry

Planning in Large Scale Agile Projects

In Agile methods, loading a team with work is done through iteration planning. Due to the shortness of the iteration (typically one to six weeks) a plan reduces in importance and planning gains in importance. For small projects, it may be sufficient to plan only a single iteration at a time. The experienced disadvantage of iteration planning when applied to projects that run for more then a few iterations or with multiple teams is that the view of the longer term implications of iteration activities can be lost. In other words: the view of “the whole” is lost. A solution is to add planning levels to incorporate the current view of “the whole”.

In plan-driven and waterfall methodologies, this problem is overcome through a large upfront design, aiming to predict accurately how much work is involved in each project task. This leads to a large investment early in the project, when it is by no means certain that the designed functionality is actually the functionality desired by the product owner. An approach with multiple levels of planning has to avoid the reintroduction of the big design up front.

Planning activities for large-scale development efforts should rely on five levels:

• Product Vision
• Product Roadmap
• Release Plan
• Sprint Plan
• Daily Commitment

The certainty of undertaking activities addressed in each of the five levels increases, and therefore the amount of detail addressed (money invested), the number of people involved and the frequency can increase without running the risk of spending money on features that may not be built or may be built differently. Each of the five levels of planning addresses the fundamental planning principles: priorities, estimates and commitments.

Product Visioning – Level 1 The broadest picture that one can paint of the future is a vision of a product owner. In this vision she explains how an organization or product should look. She indicates what parts of the system need to change (priority) and what efforts can be used to achieve this goal (estimates and commitments).

Product Visioning – How To Possible structures for a visioning exercise are to create an elevator statement or a product vision box . The principle of both exercises is to create a statement that describes the future in terms of desired product features, target customers and key differentiators from previous or competitive products.

Geoffrey Moore uses the following structure in his elevator statement: “For (target customer) who (statement of the need) the (product name) is a (product category) that (product key benefit, compelling reason to buy). Unlike (primary competitive alternative), our product (final statement of primary differentiation).” The product vision describes a desired state that is 12 months or more in the future. Further planning (design) activities will detail the vision, and may divert from the vision because the future will bring us a changed perspective on the market, the product and the required efforts to make the vision reality.

Product Roadmap – Level 2 The era of large-scale projects that deliver results in years is behind us. Customers demand more frequent changes and typical time-to-market timeframes are measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps, into thinking of a road towards the final product. Just like a journey is planned upfront and shared with the fellow travelers, a product roadmap is created and communicated to fellow delivery people.

The goals for doing so are for the product owner to:
• Communicate the whole
• Determine and communicate when releases are needed
• Determine what functionality is sufficient for each release
• Focus on business value derived from the releases

The delivery team on the other hand will:
• See the whole
• Learn about the steps to realize the vision
• Learn the business priorities
• Provide technical input to the roadmap
• Provide estimates for the projected features

Product Roadmap – How To The creation of the roadmap is largely driven by the product owner (or product owner team). This stage of the program has limited influence of technology constraints. In a meeting or series of meetings, the roadmap will be drawn by the product owner. This can be quite literally, through a graphical representation of the releases, or more formally in a written document outlining the dates, contents and objectives of the foreseen releases.

Product Backlogs In anticipation of the next planning stage (release planning) a list of desired features needs to be built – the product backlog. In its simplest form, such a backlog is a table (spreadsheet) of product requirements, briefly described so a delivery team can provide estimates for the realization of each feature. Most importantly, the list has to be prioritized. The success of an Agile development project depends on the early delivery of the highest priority features. Since the success of a project is measured in business terms, the prioritization of the feature list is the responsibility of the business, i.e. the product owner. Interaction with the delivery teams is required. Without a discussion of the features it will be hard for the delivery team to produce estimates that have an acceptable inaccuracy. Characteristics of a product backlog include:

• One product backlog for all teams (see the whole)
• Large to very large features (up to 20 ‘person days’ to deliver a feature)
• Feature priority based on business priorities (discovered through market research)
• Technology features (sometimes called non-functional features, work required to make the product work in a desired way, e.g. the implementation of a certain DBMS in order to warrant a certain system performance) are limited to those that have a direct impact on the success of the product in the market.

Related posts:

1. Three Ideas to Consider When Implementing Agile with Distributed Development Teams
2. What Every Manager Ought To Know About Agile Development
3. Six Sigma and Agile Software Development

The modern definition of agile software development evolved in the mid 1990s as part of a reaction against “heavyweight” methods, as typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software engineers actually perform effective work.

The objective when implementing an agile methodology is to minimize risks in software development. Within all agile software development methodologies, there are common principles. The Agile Alliance lists the following principles in the Agile Manifesto:

* Customer satisfaction by rapid, continuous delivery of useful software
* Working software is delivered frequently (weeks rather than months)
* Working software is the principal measure of progress
* Even late changes in requirements are welcomed
* Close, daily, cooperation between business people and developers
* Face-to-face conversation is the best form of communication
* Projects are built around motivated individuals, who should be trusted
* Continuous attention to technical excellence and good design
* Simplicity
* Self-organizing teams
* Regular adaptation to changing circumstances

There are many disciplines that fall within the agile software development umbrella. Some well known agile software development methodologies include Scrum, Crystal Clear, Lean, Extreme Programming (XP), Adaptive Software Development, Feature Driven Development, and DSDM.

Agile Software Development Status
Agile Software Development is often contrasted to the most prevalent software development model: Waterfall. According to a study from ACM:

“It is both surprising and disappointing, then, that in a survey of almost 200 practitioners, accounting for several thousands of projects over the past five years, the dominant process model reported was the Waterfall, with more than a third claiming its use.5 This result raises a question: Do practicing professionals know the Waterfall when they see it? Perhaps they are confusing it with other process models. This seems unlikely, but so does its dominance. It’s more likely that in many circumstances, doing the wrong thing is easier than doing the right thing—and this is not a recipe for success”

Where to Learn More

AgileAlliance
Using Agile in Offshore Development
Agile Software Development Articles

Recommended Books

Agile Software Development (Wikipedia)

Related posts:

1. Using an Agile Software Process with Offshore Development
2. Three Ideas to Consider When Implementing Agile with Distributed Development Teams
3. Six Sigma and Agile Software Development

To the project team itself agile methods might look great, but convincing management and people that talk business sense it is a good thing is often a much harder process. I find this interesting because one of the main focuses of agile is to place the quality of software over everything else. As a primary metric, agile and agile meta models (SCRUM for example), focus on making maximum business sense or providing maximum business value at the end of every iteration.

Ok, so agile makes it a standing point to deliver on what the customer wants at the end of each iteration, but what are the other motivating factors behind pushing agile as a model for delivering real business value.

An improved feedback and control loop

Agile provides its clients with frequent opportunities to provide feedback at the end of an iteration. With this, they can further direct the project in an incremental fashion, driving the next iteration with their business sense, asking questions like “What is of most business value to me right now?” This iterative feedback from both the client and project team lead to advantages that would otherwise not be available, jumping on new and upcoming technologies and developments to spearhead the next iteration.

These changes and developments have the effect of spearheading the project towards success and an overall better product. In some cases, it can provide improved return on investment by allowing the product to be deployed much earlier. Remember, an iteration focuses on delivering the most business value it can. If there is enough of that value there, enough to make this business sense just that, it is worth deploying early to start recouping on costs before the product has even reached the end of its development life cycle. By the time the project has come to completion, you may well have recouped half of your initial investment.

Avoid catastrophes

It’s common for a project to be tracking well and suddenly fall behind at a late stage in development. Why? Traditional software development life cycle models find it much harder to judge the correctness and completeness of up front analysis and design. This lack of information sometimes leads to overly optimistic views which don’t manifest until much later in the project when it is too late to do anything about it. Do you cut your losses and get out? Or take the risk? Well, another way to look at it would be to avoid this risk altogether. And by avoid, we really mean circumvent. As an iterative model, agile performs short bursts of analysis, design and implementation often. This gives rise to much more tracking data before entering the next iteration to re-evaluate where the project is at and if it is still on track.

The only four variables we really have control over in software development are: time, scope, cost and quality. Having the advantage of a model closely tied to these variables often and right throughout the projects life cycle is a big risk mitigator.

A focus on quality

This is a major area of agile models and comes back to core concepts known as the agile manifesto. It is basically saying; focus on quality software that translates into real business value for the customer each step of the way. Deliver this value at the end of each iteration, even if it means less formal practices and documentation is kept. Use customer collaboration as an improvement mechanism and embrace any change that might be coming.

Like extreme programming agile also adopts the practice of pair programming. No discussion on “What makes good business value?” or “What brings good return on investment?” would be complete without talking about it. It’s often hard convincing management that using two people on one task is beneficial. The productivity of having two people on one task is slightly lower than each working individually (I’m not going to make up any fancy statistics here:)). So this would raise the argument that pair programming actually costs more! What you cannot as easily measure however is the increase in quality pair programming brings.

Agile promotes information sharing

All information is shared amongst team members, often with the activities being shared to: analysis, design and implementation (pair programming during development for example). This information loop routinely filters through to the customer too. After all, that’s why they are there, to provide input going into the next iteration.

Agile development however is not necessarily well suited to all types of projects. Sometimes no matter how hard you try you just cannot come up with a good enough business reason to justify the model. That’s fine, agile does not suit every type of project small and large. Just recognize when you might be able to gain the flexibility and momentum it offers.

Related posts:

1. Three Ideas to Consider When Implementing Agile with Distributed Development Teams
2. Six Sigma and Agile Software Development
3. What is Agile Software Development?

Evolution of the Field
Since around 1975, various people have tried valiantly to impose discipline on the chaotic, egocentric, idiosyncratic practice of programming. And just at the turn of the century some professional institutions have started to establish the core competencies that would let a programmer call herself a software engineer.

Vision of the Future
Will we see the transformation complete: will programmers be licensed and regulated like other engineers? Personally, I think it’s too early to bet one way or the other – programmers are remarkably individualistic and there will be be very strong resistance to regulating what they regard as their craft. On the other hand, offshore development and the rise of software-based lawsuits are changing the landscape much as barbed wire changed the American west of the 19th century. If you’d like my prediction, ask me again in a decade.

Today’s Situation
But if you are going to work in the world of the programmer, you’ll have to understand some of the standard ways in which complex software is constructed. If you want to sound erudite, you can refer to them as “software development methodologies” or “development models,” but if you’re talking to a programmer you’re better off asking, “So, how do you folks build software around here?”

Related posts:

1. Surprise, surprise – software engineers hit by offshore job outsourcing
2. Recent Software Programming Contest Provides Example of Flattening World
3. The Future of Software Outsourcing

The concept of pair programming first became popular thanks to “extreme programming” or XP—a set of practices that supposedly allows companies to develop software in a more efficient, more “agile” manner. Proponents of XP claim that it allows programmers to respond to changing or ambiguous software requirements without sacrificing quality. Skeptics disagree, arguing that these alleged benefits are either illusory or exaggerated.

XP proponents argue that two programming heads are better than one—that two software developers working together will tend to produce better, more reliable and more maintainable than a single programmer working alone. This practice is known as pair programming, and at first glance, it sounds like a great idea. Personally though, I think that it smacks of a “one size fits all” mentality. That is, it assumes that two programmers working in concert will indeed be more efficient and that they will produce better results. I think there is good reason to believe otherwise.

The much vaunted Williams study

XP fans typically point to an infamous study headed by Prof. Laurie Williams at the University of Utah. In this study, Williams concluded that pair programming takes 15% more time than solo development, but results in software that is 15% better. They argue that this modest increase in development time is a small price to pay, since better code quality means that less time and effort will be required later down the road – during testing and maintenance, for example.

I think that there are numerous problems with this study, though. How did the researchers gauge software quality, for example? The used the length of code as the quality metric; that is, the shorter the source code, the better they deemed it to be. The reported, “[The paired teams] consistently implemented the same functionality as the individuals in fewer lines of code. We believe this is an indication that the pairs had better designs.” I think this is a hasty leap of logic, to say the least!

Does shorter source code exhibit greater quality? Sometimes, perhaps. However, one could just as easily speculate that the longer code contains more bug fixes and safeguards. In addition, adding more code lines – to implement a design pattern, for example – can make the software more efficient or easier to maintain. I think that the presumed correlation between code length and lack of quality is poorly justified at best.

The study also exhibited a severe case of participant bias. The students in a class were asked if they preferred to work in groups or alone. 35 of the respondents said that they preferred collaborative working; of these students, 28 of them were selected to constitute the pair programming experimental group. The remaining seven were placed in the solo programming group, i.e. the experimental controls. This created a strong experimental bias; all of the pair programmers were willing volunteers, whereas some members of the control group were there reluctantly.

What’s more, 13 out of the 14 pairs were self-selecting; that is, students were allowed to pick their partners willingly. Once again, this biases the results, since participants are likely to select partners with whom they are particularly compatible.

(Interestingly enough, these biases could have been easily avoided by assigning pairs randomly. I don’t wish to cast aspersions; however, I can’t help but wonder if Prof. Williams and company might have unconsciously biased their experiment to demonstrate the superiority of pair programming.)

Short-circuiting the creative process

In short, the supposed evidence for increased productivity under pair programming is questionable at best. In addition, we should ask if there’s any reason to believe that pair programming can be counter-productive or otherwise harmful.

I believe that it can be. Pair programming can certainly help people catch or prevent bugs; as the story goes, two pairs of eyes are better than one. When faced with a thorny problem though, one often needs to let the problem percolate in one’s brain for a while before arriving at a proper solution. Often, that’s how creative minds operate; they need to let their minds sift a problem first before attempting to fix it.

With pair programming though, this process is short-circuited. Instead of letting one’s mind digest the problem in due time, pair programming puts pressure on people to arrive at a solution more quickly. Sometimes, this may produce better results; however, it can also have the opposite effect. I suspect that for the most creative minds, this kind of pressure can stifle creativity rather than hinder it.

But wait! Isn’t there power in numbers? Aren’t there times when the best results are produced by having people brainstorm and confer? Certainly… but these “meetings of minds” don’t have to occur during the programming process. They can occur during planning sessions, during design reviews, or when sitting around a lunch table. We shouldn’t dispense with group troubleshooting and design; we simply shouldn’t force this to occur at the coding stage. That can do more damage than good.

What’s more, the most creative minds often need a measure of playtime – an opportunity to play around with the code, tentatively exploring various options and letting one’s mind roam free. This can be difficult to do when another programmer is looking over your shoulder. After all, what should we do – explain and discuss every tentative step? For a creative mind, this can be stifling indeed.

Conclusion

In short, I think that the evidence for pair programming effectiveness is questionable and overblown. I also think that there’s good reason to believe that pair programming can stifle the creative process, instead of helping it. Can pair programming be helpful? Certainly… However, when forced upon people, it becomes a “one size fits all” strategy—and unfortunately, a single size can’t possibly fit everybody, no matter what the salespeople say.

Related posts:

1. Recent Software Programming Contest Provides Example of Flattening World
2. What Every Manager Ought To Know About Agile Development
3. Three Ideas to Consider When Implementing Agile with Distributed Development Teams

An excerpt

For the last four years ThoughtWorks has operated a lab in Bangalore India to support our software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but we are very firmly in the agile camp. Here I discuss our experiences and lessons learned in doing offshore agile development. So far we’ve discovered that we can make it work, although the benefits are still open to debate.

Agile Software Process with Offshore Development

Related posts:

1. What is Agile Software Development?
2. Agile Software Development Ecosystem
3. How to Implement Agile Offshore Development