BT internship report

1. EXECUTIVE SUMMARY

2. TELECOMMUNICATION INDUSTRY

2.1. Global Telecommunication market 2.1.1 A more open telecoms market 2.2. Porter’s 5 Forces Analysis 2.1.2 Threat of New Entrants 2.1.3 Power of Suppliers 2.1.4 Power of Buyers

2.1.5 Availability of Substitutes 2.1.6 Competitive Rivalry

3. HISTORY OF THE HOST COMPANY

3.1. The post office

3.2. British Telecom created 3.3. British Telecom privatized

3.4. BT - a new name and identity for British Telecom 3.5. BT's identity and values refreshed 3.6. BT - a global company 3.7.

Openreach created

4. AGILE METHODOLOGY

4.1. Agile software development 4.2. History

4.3. Principles behind agile methods 4.4. Comparison with other methods 4.5. Suitability of agile methods 4.6. Agile data

4.7. Agile methods and method tailoring 4.8. Agile methods and project management 4.9. Agile methods

4.10. Agile beyond software development 4.11.

Measuring agility

3 4

4 6 6 7 7 8 8 8

8

8 9 10 10 11 12 12

12

13 13 13 14 16 18 18 19 19 20 20

4.12. Criticism 4.13. Post-Agilism 4.14.

Experience reports

5. AGILE METHODOLOGY IN MANAGEMENT

5.1. What is BT Agile? 5.2. The competitive challenge

5.3. Agile Delivery Principles (derived from Agile Manifesto) 5.4. What are the benefits?

5.5.

How does BT Agile Delivery work?

ROUND TABLE

5.6. Business Problem Definition 5.7. Hothouse

5.8. Delivery Iterations 5.9. Common Capabilities 5.10. Product Master Files

5.11.

Service Assembly Environment

6. PROJECTS FOR THE INTERNSHIP

6.1. Outsourcing skill sets market in China 6.2. ODC site location selection in Beijing 6.3.

CFIN project

7. CONCLUSION 8. REFERENCES

20 21 21

22

22 22 22 24 24

25

25 25 25 25 26 26

26

26 26 26

26 26

1. Executive summary

BT, an abbreviation for British Telecommunications plc, which is the host company offer internship for my Manager Exchange Training program, sponsored by EU and China government. As a Chinese manager from a domestic software company, this is good opportunity for me to explore a Europe telecom company for it’s cooperate culture, its operation, its policy and its way of doing business… etc.

Although, it is only a two month of internship and several small projects, I do learn a lot not only from the theoretic training through different business schools in Manchester University, ESCP-EAP and Université Libre de Bruxelles, and the internship as well.

2. Telecommunication industry

2.1. Global Telecommunication market

Think of telecommunications as the world's biggest machine. Strung-together by complex networks, telephones, mobile phones and Internet-linked PCs, the global system touches nearly all of us. It allows us to speak, share thoughts and do business with nearly any one, regardless of where in the world they might be. Telecom operating companies make all this happen.

Not long ago the telecommunications industry was comprised of a club of big national and regional operators. Over the past decade the industry has been swept up in rapid de-regulation and innovation. In many countries around the world, government monopolies are now privatized and they face a plethora of new competitors. Traditional markets have been turned upside down, as growth in mobile services outpaces the fixed line and the Internet starts to replace voice as the staple business.

Plain old telephone calls continue to be the industry's biggest revenue generator, but thanks to advances in network technology this is changing. Telecom is less about voice and increasingly about text and images. High-speed Internet access, which delivers computer-based, data applications such as broadband information services and interactive entertainment—is rapidly making its way into homes and businesses around the world. The main broadband telecom technology—Digital Subscriber Line (DSL)—ushers in the new era. The fastest growth comes from services delivered over mobile networks. Analysts believe that mobile will account for at least half of all voice. But mobile operators may be victims of their own success: the number of mobile handset owners is way up, but so is the cost of acquiring them.

Of all the customer markets, residential and small business markets are arguably the toughest. With literally hundreds of players in the market, competitors rely heavily on price to slog it out for household's monthly cheques; success rests largely on brand name strength and heavy investment in efficient billing systems. The corporate market, on the other hand, remains the industry's favourite. Big corporate customers -

concerned foremost about the quality and reliability of their telephone calls and data delivery - are less price-sensitive than residential customers. Large multi-nationals, for instance, spend heavily on telecom infrastructure to support far-flung operations. They are also happy to pay for premium services like high-security private networks and videoconferencing.

Telecom operators also make money by providing network connectivity to other telecom companies that need it, and by wholesaling circuits to heavy network users like Internet service providers and large corporations. Interconnect and wholesale markets favour those players with far-reaching networks.

EBITDA (Earnings Before Interest, Taxes, Deprecation and Amortization) An indicator of a company’s financial performance calculated as: Revenue less express (excluding tax, interest, depreciation and amortization)

Churn Rate

Churn Rate is a rate at which customers leave for a competitor. Largely due to fierce competition, the telecom industry boasts - or, rather, suffers - the highest customer

churn rate of any industry. Strong brand name marketing and service quality tends to mitigate churn.

ARPU (Average Revenue Per User)

Used most in the context of a telecom operator's subscriber base, ARPU sometimes offers a useful measure of growth performance. ARPU levels get tougher to sustain competition and increased churn exert a downward pressure. ARPU for data services have been slowly increasing.

Broadband

The latest in high-speed Internet access technology, delivering access at speeds

hundreds of times faster than a familiar Dial-up modem can provide. Right now, wam max The industry promises that broadband services, delivered over traditional and wireless networks, will create exciting new growth applications, like video-on-demand and online learning.

It is hard to avoid the conclusion that size matters in telecom. It is an expensive business; contenders need to be large enough and produce sufficient cash flow to absorb the costs of expanding networks and services that become obsolete seemingly overnight. Transmission systems need to be replaced as frequently as every two years. Big companies that own extensive networks - especially local networks that stretch directly into customers' homes and businesses - are less reliant on interconnecting with other companies to get calls and data to their final destinations. By contrast, smaller players must pay for interconnect more often to finish the job. For little operators hoping to grow big some day, the financial challenges of keeping up with rapid technological change and depreciation can be monumental.

Earnings can be a tricky issue when analyzing telecom companies. Many companies have little or no earnings to speak of. Analysts, as a result, are often forced to turn to measures besides P/E to gauge valuation.

Price/Sales ratio is the probably simplest of the valuation approaches: take the market capitalization of a company and divide it by sales over the past 12 months. No estimates are involved. The lower the ratio, the better. A reasonably effective

alternative when evaluating telecom companies that have no earnings, it is also useful in evaluating mature companies.

Another popular performance yardstick is EBITDA. Earning Before Interest, Tax, Depreciation and Amortization – or \"EBITDA\" for short - provides a way for

investors to gauge the profit performance and operating results of telecom companies with large capital expenses. Companies that have spent heavily on infrastructure will generally report large losses in their earnings statements. EBITDA helps determine whether that new multi-million dollar fibre optic network, for instance, is making money each month, or losing even more. By stripping away interest, taxes and capital expenses, it allows investors to analyze whether the baseline business is profitable on a regular basis.

Investors should be mindful of cash flow. EBITDA gives an indication of profitability, whereas cash flow measures how much money is actually flowing through the

telecom operator at any given period of time. Is the company making enough to repay its loans and cover working capital? A telecom company can be recording rising profits year-by-year while its cash flow is ebbing away. Cash flow is the sum of new borrowings plus money from any share issues, plus trading profit, plus any

depreciation.

Keep an eye on the balance sheet and borrowing. Telecom operators frequently have to ring up substantial debt to finance capital expenditure. Net Debt/EBITDA provides a useful comparative measure. Again, the lower the ratio, the more comfortably the operator can handle its debt obligations. Credit rating agencies like Moody's and S&P take this ratio very seriously when evaluating operators' borrowing risk.

2.1.1 A more open telecoms market

If we consider the progress of global market for an international company, such as BT, the next major development for British Telecom is to move towards a more open market in telecommunications since 1991. On 5 March, the Government's White

Paper, Competition and Choice: Telecommunications Policy for the 1990s, was issued. In effect, it ended the duopoly which had been shared by British Telecom and Mercury Communications in the UK since November 1983 and the build up to privatisation. The new, more open and fairer policy, enabled customers to acquire telecommunications services from competing providers using a variety of technologies. Independent 'retail' companies were permitted to bulk-buy

telecommunications capacity and sell it in packages to business and domestic users. The White Paper was endorsed by British Telecom, the new policy enabling the

company to compete freely and more effectively by offering flexible pricing packages to meet the needs of different types of customer.

2.2. Porter’s 5 Forces Analysis

In ESCP-EAP European School of Management Turin campus, a practice strategy management course was given to the METP (manager exchange training program), which introduce the main theories of strategy management principles and case study for a real company. Porter’s 5 forces is the key analysis tool employed by analyzers in the consultant industry for their daily work. In the real world, we can make a basic analysis for an industry after we collection information from the market research agency or second hand data from different data sources like government statistic data published over different countries, which is normal available for free to retrieve.

Figure 1 Porter’s Five Forces

2.1.2 Threat of New Entrants

No surprise, in the capital-intensive telecom industry the biggest barrier-to-entry is access to finance. To cover high fixed costs, serious contenders typically require a lot of cash. When capital markets are generous, the threat of competitive entrants

escalates. When financing opportunities are less readily available, the pace of entry slows. Meanwhile, ownership of a telecom license can represent a huge barrier to entry. In the US, for instance, fledgling telecom operators must still apply to the Federal Communications Commission to receive regulatory approval and licensing. There is also a finite amount of \"good\" radio spectrum that lends itself to mobile voice and data applications. In addition, it is important to remember that solid

operating skills and management experience is fairly scarce, making entry even more difficult.

2.1.3 Power of Suppliers

At first glance, it might look like telecom equipment suppliers have considerable bargaining power over telecom operators. Indeed, without high-tech broadband switching equipment, fibre-optic cables, mobile handsets and billing software,

telecom operators would not be able to do the job of transmitting voice and data from place to place. But there are actually a large number of large equipment makers

around. Nortel, Lucent, Cisco, Nokia, Alcatel, Ericsson, Tellabs are just a few of the supplier names. There are enough vendors, arguably, to dilute bargaining power. The limited pool of talented managers and engineers, especially those well versed in the latest technologies, places companies in a weak position in terms of hiring and salaries.

2.1.4 Power of Buyers

With increased choice of telecom products and services, the bargaining power of buyers is rising. Let's face it; telephone and data services do not much vary regardless of which companies are selling them. For the most part, basic services are treated as a commodity. This translates into customers seeking low prices from companies that offer reliable service. At the same time, buyer power can vary somewhat among

market segments. Customers can be as small as individual residential users like you or me, or be as big as an ISP like America Online or a large university. While switching costs are relatively low for residential telecom customers, they can get higher for

larger business customers, especially those that rely more on customized products and services.

2.1.5 Availability of Substitutes

Products and services from non-traditional telecom industries pose serious

substitution threats. Cable TV and satellite operators now compete for buyers. The cable guys, with their own direct lines into homes, offer broadband Internet services, and satellite links can substitute for high-speed business networking needs. Railways and energy utility companies are laying miles of high-capacity telecom network alongside their own track and pipeline assets. Just as worrying for telecom operators is the Internet: it is becoming a viable vehicle for cut-rate voice calls. Delivered by ISPs - not telecom operators - \"Internet telephony\" could take a big bite out of telecom companies' core voice revenues.

2.1.6 Competitive Rivalry

Competition is \"cut throat\". The wave of industry de-regulation together with the receptive capital markets of the late 1990s paved the way for a rush of new entrants. New technology is prompting a raft of substitute services. Nearly everybody already pays for phone services, so all competitors now must lure customers with lower prices and more exciting services. This tends to drive industry profitability down. In addition to low profits, the telecom industry suffers from high exit barriers, mainly due to its specialized equipment. Networks and billing systems cannot really be used for much else, and their swift obsolescence makes liquidation pretty difficult.

3. History of the host company

BT is the world's oldest telecommunications company. Its origins date back to the establishment of the first telecommunications companies in the United Kingdom. Among them was the first commercial telegraph service, the Electric Telegraph

Company, introduced in 1846. As these companies amalgamated and were taken over or collapsed, the survivors were eventually transferred to state control under the Post Office. They later became a privatised company, British Telecommunications plc - the forerunner of today's global communications company, BT Group plc, which serves customers in 170 countries.

3.1. The post office

The United Kingdom telephone service in its early period from 1878 was provided by private sector companies such as the National Telephone Company (NTC), with the General Post Office (GPO) soon in competition. In 16, the GPO took over the NTC trunk telephone service. In 1912, it became the monopoly supplier of the telephone service when the GPO took over the whole private sector telephone service in the UK, except for a few local authority services. These municipal services all folded within a few years of set up, the sole exception being the city of Kingston-upon-Hull where the city telephone department became present day Kingston Communications. The idea of converting the Post Office into a nationalised industry rather than a

government department was first raised as early as 1932 in a book published by Lord Wolmer called Post Office Reform. Also in 1932, the Bridgeman Committee was formed, 'to enquire and report as to whether any changes to the constitution, status or system of organisation of the Post Office would be in the public interest'. The

Committee's report was rejected. Further attention was given to the subject in 1961, but, as before, the proposals were ignored. The Post Office remained a department of central government, with the Postmaster General sitting in Cabinet as a secretary of state.

In March 1965, the Postmaster General of the time, Anthony Wedgewood-Benn, wrote to the Prime Minister proposing that studies be undertaken aimed at converting the Post Office into a nationalised industry. A working party was established to look into the advantages of such a change and to consider the problems which might arise. The findings were favourable enough for the Government to establish a Steering

Group on the Organisation of the Post Office. After some initial deliberations that the business should be divided into five divisions - Post, Telecommunications, Savings, Giro and National Data Processing Services - it was eventually decided that there should be one corporation split into two divisions: Post and Telecommunications. These events finally resulted in the introduction of the Post Office Act, 1969. Under the Act, the Post Office ceased to be a government department and, on 1 October 1969, it became established as a public corporation. The Act gave the Post Office the exclusive privilege of running telecommunications systems with listed powers to authorise others to run such systems. Effectively, the new Post Office Corporation retained its telecommunications monopoly.

3.2. British Telecom created

In 1977, the Carter Committee Report recommended a further separation of the two main services and for their relocation under two individual corporations. The findings contained in the report led to the renaming of Post Office Telecommunications as British Telecom in 1980, although it remained part of the Post Office.

The British Telecommunications Act, 1981 transferred the responsibility for

telecommunications services from the Post Office, creating two separate corporations. At this time the first steps were taken to introduce competition into the UK

telecommunications industry. In particular, the Act empowered the Secretary of State for Trade and Industry, as well as British Telecom, to license other operators to run telecommunications systems. Additionally, a framework was established which enabled the Secretary of State to set standards with the British Standards Institution (BSI) for apparatus supplied to the public by third parties, and had the effect of requiring British Telecom to connect approved apparatus to its systems.

The Secretary of State made use of these new powers and began the process of opening up to competition both the public switched telephone network and the

apparatus supply market, where a phased programme of liberalisation was started in 1981. In 1982, a licence was granted to Cable & Wireless to run a public

telecommunications network through its subsidiary, Mercury Communications.

3.3. British Telecom privatized

On 19 July 1982, the Government formally announced its intention to privatise British Telecom with the sale of up to 51 per cent of the company's shares to private investors. This intention was confirmed by the passing of the Telecommunications Act, 1984, which received Royal Assent on 12 April that year. The transfer to British

Telecommunications plc of the business of British Telecom, the statutory corporation, took place on 6 August 1984 and, in November 1984, more than 50 per cent of British Telecom shares were sold to the public.

The new legislation had to enable British Telecom to become more responsive to competition in the UK and to expand its operations globally. Commercial freedom granted to British Telecom allowed it to enter into new joint ventures and, if it so decided, to engage in the manufacture of its own apparatus.

The company's transfer into the private sector continued in December 1991 when the Government sold around half its remaining holding of 47.6 per cent of shares,

reducing its stake to 21.8 per cent. Substantially all the government's remaining shares were sold in a third flotation in July 1993, raising £5 billion for the Treasury and introducing 750,000 new shareholders to the company.

The 1984 Act also abolished British Telecom's exclusive privilege of running

telecommunications systems and established a framework to safeguard the workings of competition. This meant that British Telecom finally lost its monopoly in running telecommunications systems, which it had technically retained under the 1981 Act despite the Secretary of State's licensing powers. It now required a licence in the same way as any other telecommunications operator. The principle licence granted to British Telecom laid down strict and extensive conditions affecting the range of its activities, including those of manufacture and supply of apparatus.

3.4. BT - a new name and identity for British Telecom

On 2 April 1991, the company unveiled a new trading name, BT, a new corporate identity and a new organisational structure. This structure focused on specific market sectors, reflecting the needs of different customers - the individual, the small business or the multinational corporation. The reorganisation was named Project Sovereign to reflect the company's commitment to meetings customers' needs - 'the customer is King'. Together with a succession of strategic alliances with telecommunications companies worldwide, these changes gave BT the means to expand into overseas markets.

In June 1994, BT and MCI Communication Corporation, the second largest carrier of long distance telecommunications services in the US, launched Concert

Communications Services, a $1 billion joint venture company. This alliance gave BT and MCI a global network for providing end-to-end connectivity for advanced

business services. Concert was the first company to provide a single source, broad portfolio of global communications services for multinational customers. On 3

November 1996, BT and MCI announced they had entered into a merger agreement to create a global telecommunications company called Concert plc, to be incorporated in the UK, with headquarters in both London and Washington DC. As part of the alliance BT acquired a 20 per cent holding in MCI. Nevertheless, following US carrier WorldCom's rival bid for MCI on 1 October 1997, BT ultimately decided in November, to sell its stake in MCI to WorldCom for $7 billion. The deal with

WorldCom resulted in a profit of more than $2 billion on BT's original investment in MCI, with an additional $465 million severance fee for the break up of the proposed merger.

In July 1998, BT announced another global venture with the formation of a 50:50 business with AT&T. The new company, Concert, was launched in November 1999 to serve the needs of multinational companies and the international calling needs of individuals and businesses. In October 2001, following a downturn in the global telecommunications market, it was announced that BT and AT&T were to unwind Concert, returning its businesses, customer accounts and networks to the two parent companies (this was completed in April 2002).

In December 2000, following modifications to BT's licence in April 2000, BT offered local loop unbundling (LLU) to other telecommunications operators, enabling them to use BT's copper local loops (the connection between the customer's premises and the exchange) to connect directly with their customers. By the end of August 2005, 105,055 lines had been unbundled.

In May 2001, as part of a restructuring and debt reduction programme, BT announced a three for ten rights issue to raise £5.9 billion - still the UK's largest ever rights issue - and the sale of Yell, the international directories and associated e-commerce business for £2.14 billion. Both activities were completed in June 2001.

In November 2001, BT Wireless - BT's mobile business, re-branded as mmO2 - was demerged from BT on a one for one share basis. The last day of trading in BT shares was 16 November 2001 and from 19 November, mmO2 plc and the new BT Group plc shares were traded separately.

3.5. BT's identity and values refreshed

In April 2003, BT unveiled its current corporate identity and brand values. Reflecting the aspirations of a technologically innovative future, the connected world symbol is bright, strong and clear and embodies BT's five corporate values. The values of Trustworthy and Helpful are long-standing BT service values and are supported by forward-looking values of Inspiring, Straightforward and Heart.

The Communications Act, 2003 which came into force on 25 July 2003 introduced a new industry regulator, the Office of Communications (Ofcom), to replace the Office of Telecommunications (Oftel). It also introduced a new regulatory framework. The licensing regime was replaced by a general authorisation for companies to provide telecommunications services subject to general conditions of entitlement and, in some instances, specific conditions. Under a specific condition BT retained its universal service obligation (USO) for the UK, excluding the Hull area. The USO included connecting consumers to the fixed telephone network, schemes for consumers with special social needs, and the provision of call box services.

In the summer of 2004, BT launched Consult 21, an industry consultation for BT's 21st century network (21CN) programme. 21CN is the world's most ambitious and radical next generation network transformation and will transform the communication infrastructure of the UK by 2010. Using internet protocol technology, 21CN will replace the existing networks and enable converged multimedia communications - that is communications from any device such as mobile phone, PC, PDA or home phone, to any other device.

3.6. BT - a global company

In 2005, BT's position as a leading provider of communications solutions across the globe was enhanced by a number of important acquisitions. These included Infonet - now BT Infonet - one of the world's leading providers of global managed voice and data network services for corporate customers.

It also acquired the second largest telecoms operator in the Italian business market, Albacom. The acquisition of Infonet and Albacom form part of BT's increased capability to supply networked IT services to multi-site organisations all over the world.

And it acquired the leading financial services extranet provider Radianz from Reuters, which it intends to develop to deliver additional value added services to the financial market.

3.7. Openreach created

Following the Telecommunications Strategic Review (TSR), in September 2005 BT signed legally-binding Undertakings with Ofcom to help create a better regulatory framework for BT and the UK telecoms industry generally. Openreach opened for business in January 2006 and reports directly into the BT chief executive. It is

responsible for managing the UK access network on behalf of the telecommunications industry.

Openreach manages the UK's telecommunications infrastructure, treating the rest of BT on an equal basis as other operators. It is one of four businesses which make up BT Group. The other three are BT Retail, BT Wholesale and BT Global Services, which all focus on their own markets and customers.

Today, the company is structured so that British Telecommunications plc (BT) is a wholly owned subsidiary which encompasses the four separately managed businesses and virtually all other assets of the BT Group. BT Group plc is listed on the stock exchanges in London and New York.

BT is transforming from a traditional telecoms company to a leading provider of converged networked services and its aim is to help customers get the most out of communications technology by providing tailored solutions that are easy to use.

4. Agile methodology

4.1. Agile software development

Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.

There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is

referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.

Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their \"customers\" (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.

4.2. History

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. A case can be made that agile and iterative development methods are a return to development practice seen early in the history of software development.[1] Initially, agile methods were called \"lightweight methods.\" In 2001, prominent members of the community met at Snowbird, Utah, and adopted the name \"agile methods.\" Later, some of these people formed The Agile Alliance[1], a non-profit organization that promotes agile development.

Methodologies similar to Agile created prior to 2000—include Scrum (1986), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and DSDM (1995).

Extreme Programming (usually abbreviated as \"XP\") was created by Kent Beck in 1996 as a way to rescue the struggling Chrysler Comprehensive Compensation (C3) project. While that project was eventually canceled, the methodology was refined by Ron Jeffries' full-time XP coaching, public discussion on Ward Cunningham's Portland Pattern Repository wiki and further work by Beck, including a book in 1999.[2] Elements of Extreme Programming appear to be based on Scrum and Ward Cunningham's Episodes pattern language. XP actually emphasized a lot of best

practices but in implementation many projects saw it as a way to throw away design and modeling phases of a project and do cowboy coding, the thinking being that the peer-programming model would eliminate and catch problems. This was not always successful with complex problems. In actuality XP did stress use of modeling and documentation as required similar to Agile principles today.

4.3. Principles behind agile methods

Agile methods are a family of development processes, not a single approach to software development. In 2001, 17 prominent figures [3] in the field of agile development (then called \"light-weight methodologies\") came together at the

Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They created the Agile Manifesto, widely regarded as the canonical definition of agile development, and accompanying agile principles. Some of the principles behind the Agile Manifesto[4] are:

          

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

The publishing of the manifesto spawned a movement in the software industry known as agile software development.

In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people — management experts, this time — and wrote an addendum, known as the PM Declaration of Interdependence.

4.4. Comparison with other methods

Agile methods are sometimes characterized as being at the opposite end of the spectrum from \"plan-driven\" or \"disciplined\" methodologies. This distinction is misleading, as it implies that agile methods are \"unplanned\" or \"undisciplined\". A more accurate distinction is to say that methods exist on a continuum from \"adaptive\" to \"predictive\".[5] Agile methods exist on the \"adaptive\" side of this continuum. Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have

difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from

now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.

Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will

often institute a change control board to ensure that only the most valuable changes are considered.

Agile methods have much in common with the \"Rapid Application Development\" techniques from the 1980's as espoused by James Martin and others (see RAD). Contrasted with other iterative development methods

Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models as in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner, and most agile methods also differ by treating their time period as a strict timebox. Contrasted with the waterfall model

Agile development does not have much in common with the waterfall model. As of 2004, the waterfall model is still in common use.[6] The waterfall model is the most predictive of the methodologies, stepping through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts—requirement specifications, design documents, test plans, code reviews and the like.

The main problem of the waterfall model is the inflexible nature of the division of a project into separate stages, so that commitments are made early on, and it is difficult to react to changes in requirements. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change radically in the course of the project.[7]

Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks or months. The emphasis is on

obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it/adding further functionality throughout the life of the project.

Some agile teams use the waterfall model on a small scale, repeating the entire

waterfall cycle in every iteration.[8] Other teams, most notably Extreme Programming teams, work on activities simultaneously. Contrasted with \"cowboy coding\"

Cowboy coding is the absence of a defined method: team members do whatever they feel is right. Agile development's frequent re-evaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documents sometimes causes people to confuse it with cowboy coding. Agile teams, however, do follow defined (and often very disciplined and rigorous) processes.

As with all methodologies, the skill and experience of the users define the degree of success and/or abuse of such activity. The more rigid controls systematically

embedded within a process offer stronger levels of accountability of the users. The

degradation of well-intended procedures can lead to activities often categorized as cowboy coding.

4.5. Suitability of agile methods

Although agile methods differ in their practices, they share a number of common characteristics, including iterative development, and a focus on interaction,

communication, and the reduction of resource-intensive intermediate artifacts. The suitability of agile methods in general can be examined from multiple perspectives. From a product perspective, agile methods are more suitable when requirements are emergent and rapidly changing; they are less suitable for systems that have high criticality, reliability and safety requirements, though there is no complete consensus on this point. From an organizational perspective, the suitability can be assessed by examining three key dimensions of an organization: culture, people, and

communication. In relation to these areas a number of key success factors have been identified (Cohen et al., 2004)[9]:

    

The culture of the organization must be supportive of negotiation People must be trusted

Fewer but more competent people

Organizations must live with the decisions developers make Organizations need to have an environment that facilitates rapid communication between team members

The most important factor is probably project size. As size grows, face-to-face communication becomes more difficult. Therefore, most agile methods are more suitable for projects with small teams, with fewer than 20 to 40 people. Large scale agile software development remains an active research area.[10][11]

Another serious problem is that initial assumptions or overly rapid requirements

gathering up front may result in a large drift from an optimal solution, especially if the client defining the target product has poorly formed ideas of their needs. Similarly, given the nature of human behaviour, it's easy for a single \"dominant\" developer to influence or even pull the design of the target in a direction not necessarily

appropriate for the project. Historically, the developers can, and often do, impose solutions on a client then convince the client of the appropriateness of the solution, only to find at the end that the solution is actually unworkable. In theory, the rapidly iterative nature should limit this, but it assumes that there's a negative feedback, or even appropriate feedback. If not, the error could be magnified rapidly.

This can be alleviated by separating the requirements gathering into a separate phase (a common element of Agile systems), thus insulating it from the developer's

influence, or by keeping the client in the loop during development by having them continuously trying each release. The problem there is that in the real world, most clients are unwilling to invest this much time. It also makes QAing a product difficult since there are no clear test goals that don't change from release to release. In order to determine the suitability of agile methods individually, a more

sophisticated analysis is required. The DSDM approach, for example, provides a so-called ‘suitability-filter’ for this purpose. Also, the Crystal family of methods

provides criteria on how to select the method for a given project. The selection is based on project size, criticality and priority.

The DSDM and Feature Driven Development (FDD) methods, are claimed to be suitable for any agile software development project, regardless of situational characteristics.[12]

A comparison of agile methods will reveal that they support different phases of a software development life-cycle to varying degrees. This individual characteristic of agile methods can be used as a selection criterion for selecting candidate agile

methods. In general a sense of project speed, complexity, and challenges will guide you to the best agile methods to implement and how completely to adopt them. Agile development has been widely documented (see Experience Reports, below, as well as Beck[2] pg. 157, and Boehm and Turner[13] pg. 55-57) as working well for small (<10 developers) co-located teams. Agile development is expected to be

particularly suitable for teams facing unpredictable or rapidly changing requirements. Agile development's applicability to the following scenarios is open to question: Large scale development efforts (>20 developers), though scaling strategies[14] and evidence to the contrary[15] have been described.

 Distributed development efforts (non-co-located teams). Strategies have been

described in Bridging the Distance[16]and Using an Agile Software Process with Offshore Development[17]  Mission- and life-critical efforts

 Command-and-control company cultures



It is worth noting that several large scale project successes have been documented by organisations such as BT which have had several hundred developers situated in the UK, Ireland and India, working collaboratively on projects and using Agile

methodologies. While questions undoubtedly still arise about the suitability of some Agile methods to certain project types, it would appear that scale or geography, by themselves, are not necessarily barriers to success.

Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive (\"agile\") and predictive (\"plan-driven\") methods.[13] The authors suggest that each side of the continuum has its own home ground: Agile home ground:

    

Low criticality Senior developers

Requirements change very often Small number of developers Culture that thrives on chaos

Plan-driven home ground:



High criticality

   

Junior developers

Requirements don't change too often Large number of developers Culture that demands order

4.6. Agile data

One of the most challenging parts of an agile project is being agile with data.

Typically this is where projects hit legacy systems and legacy requirements. Many times working with data systems requires lengthy requests to teams of specialists who are not used to the speed of an agile project and insist on exact and complete

specifications. Typically the database world will be at odds with agile development. The agile framework seeks as much as possible to remove these bottlenecks with techniques such as generative data models making change fast. Models for data serve another person, often a change of one table column can be a critical issue requiring months to rebuild all the dependent applications. An agile approach would try to encapsulate data dependencies to go fast and allow change. But ultimately relational data issues will be important for agile projects and are a common blockage point. As such agile projects are best suited where projects don't contain big legacy databases. It still isn't the end of the world because if you can build your data dependencies to be agile regardless of legacy systems you will start to prove the merit of the approach as all other systems go through tedious changes to catch up with data changes while in the protected agile data system the change would be trivial.

4.7. Agile methods and method tailoring

In the literature, different terms refer to the notion of method adaptation, including ‘method tailoring’, ‘method fragment adaptation’ and ‘situational method engineering’. Method tailoring is defined as:

A process or capability in which human agents through responsive changes in, and dynamic interplays between contexts, intentions , and method fragments determine a system development approach for a specific project situation.[18]

Potentially, almost all agile methods are suitable for method tailoring. Even the

DSDM method is being used for this purpose and has been successfully tailored in a CMM context.[12] Situation-appropriateness can be considered as a distinguishing characteristic between agile methods and traditional software development methods, with the latter being relatively much more rigid and prescriptive. The practical implication is that agile methods allow project teams to adapt working practices according to the needs of individual projects. Practices are concrete activities and products which are part of a method framework. At a more extreme level, the

philosophy behind the method, consisting of a number of principles, could be adapted (Aydin, 2004).[18]

In the case of XP the need for method adaptation is made explicit. One of the

fundamental ideas of XP is that there is no process that fits every project as such, but rather practices should be tailored to the needs of individual projects. There are also no experience reports in which all the XP practices have been adopted. Instead, a

partial adoption of XP practices, as suggested by Beck, has been reported on several occasions.[19]

A distinction can be made between static method adaptation and dynamic method adaptation.[20] The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. The result is a static definition of the project context. Given such a definition, route maps can be used in order to determine which structured method fragments should be used for that particular project, based on predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projects are situated in an emergent context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable. This also means that a project context is not fixed, but changing during project execution. In such a case prescriptive route maps are not appropriate. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments, during the execution of a project (Aydin et al, 2005).[20]

4.8. Agile methods and project management

Agile methods differ to a large degree in the way they cover project management. Some methods are supplemented with guidelines on project management, but there is generally no comprehensive support.[12]

PRINCE2 has been suggested as a suitable, complementary project management system.[21]

4.9. Agile methods

Some of the well-known agile software development methods:

          

Agile Modeling

Agile Unified Process (AUP) Agile Data

Daily kickoff and review of goals short release cycles

Responsive Development

Generalism - Use of generic skill sets which are common across the team not reliance on specific skill sets which are scarce Test Driven Development (TDD) Feature Driven Development (FDD) Behavior Driven Development (BDD) Essential Unified Process (EssUP)

Other approaches:

  

Software Development Rhythms Agile Documentation ICONIX Process

  

Microsoft Solutions Framework (MSF) Agile Data Method Database refactoring

4.10. Agile beyond software development

Agile software development depends on some special characteristics possessed only by software, such as object technologies and the ability to automate testing. However, related techniques have been created for developing non-software products, such as semiconductors, motor vehicles, or chemicals. For more on them, see Flexible product development.

4.11. Measuring agility

While agility is seen by many as a means to an end, a number of approaches have been proposed to quantify agility. Agility Index Measurements (AIM)[2] score projects against a number of agility factors to achieve a total. The similarly-named Agility Measurement Index [3], scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals [4]. Another study using fuzzy mathematics[22] has suggested that project velocity can be used as a metric of agility.

While such approaches have been proposed to measure agility, the practical application of such metrics has yet to be seen.

4.12. Criticism

Agile development is sometimes criticized as cowboy coding. Extreme

Programming's initial buzz and controversial tenets, such as pair programming and continuous design, have attracted particular criticism, such as McBreen[23] and Boehm and Turner.[13] Many of the criticisms, however, are believed by Agile practitioners to be misunderstandings of agile development.[24]

In particular, Extreme Programming is reviewed and critiqued by Matt Stephens's and Doug Rosenberg's Extreme Programming Refactored.[25] Criticisms include:

    

lack of structure and necessary documentation only works with senior-level developers incorporates insufficient software design requires too much cultural change to adopt

can lead to more difficult contractual negotiations

The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method which can easily be tailored into agile processes such as XP.

Agile software development has been criticized because it will not bring about the claimed benefits when programmers of average ability use this methodology, and most development teams are indeed likely to be made up of people with average (or below) skills. [26]

4.13. Post-Agilism

In software engineering, post-Agilism is an informal movement of former \"Agilistas\" (Agile Software Development evangelists) who have chosen to draw from a much wider range of methods and schools of thought on software development, preferring to avoid being constrained by what they consider to be \"Agile Dogma\". The term Fragilism is sometimes used to mean the same thing.

Much of the debate around Post-Agilism centres on the meaning of the word Agile - with a capital 'a' - vs. \"agile\" (the dictionary definition of the word). In late 2005, Jason Gorman argued that the meaning of Agile was ambiguous and was being

inappropriately applied to a very wide range of approaches like Six Sigma and CMMi. He also argued that \"Agile\Lean software development) did not mean the same thing in practice, even though they are all lumped under the banner of \"Agile\" - possibly for marketing purposes. Gorman argued that process-oriented methods, especially methods that incrementally reduce waste and process variation like Six Sigma, have a tendency to limit an organisation's adaptive capacity (their \"slack\"), making them less able to respond to discontinuous change - i.e., less agile. He also argues in later posts that \"agile\

\"evolutionary\" are strategies that need to be properly understood and appropriately applied to any specific context. That is, there is a time to be \"agile\\"lean\" and a time to be \"evolutionary\".

The debate continued on various discussion groups, and transferred into the

blogosphere in December 2005. In June 2006 the debate widened and the term Post-Agilism was coined by Jonathan Kohl to describe the growing - but still very loose - association of people extolling \"post-Agile\" sentiments in their work.

Much of the post-Agile thinking centers around Nonlinear Management, a superset of management techniques that include many Agile practices.

4.14. Experience reports

Agile development has been the subject of several conferences. Some of these

conferences have had academic backing and included peer-reviewed papers, including a peer-reviewed experience report track. The experience reports share industry experiences with agile software development.

As of 2006, experience reports have been or will be presented at the following conferences:

  

XP (2000, 2001, 2002, 2003, 2004, 2005, 2006) XP Universe (2001)

XP/Agile Universe (2002, 2003, 2004)

Agile Development Conference (2003, 2004) (peer-reviewed; proceedings published by IEEE?)

 Agile (2005, 2006) (peer-reviewed; proceedings published by IEEE)



5. Agile methodology in management

Agile is widely used in the software development and it is very popular now in the software industries.

5.1. What is BT Agile?

BT Agile is a new way of developing products, services and enhancing customer experience. It completely changes the product development process – from the identification and evaluation of new opportunities to the development and delivery of those that provide the greatest business benefit and with the best chance of success.

It changes the way we work, a cultural change that puts the emphasis on customer led delivery, working together, being adaptive and flexible to changing business needs. The following pages explain why it‟s being introduced and what‟s involved.

5.2. The competitive challenge

Today‟s market is global. Competition is intense, so innovation is essential. No company can afford to stand still.

To succeed, you have to be good at spotting winning opportunities, shaping solutions that match customer needs and then swiftly getting those solutions to market.

The market is changing in favour of those who can respond in a smarter and collaborative manner. BT must be at the forefront of this change and an agile way of working is fundamental to our success.

The Agile Manifesto

We are uncovering better ways of developing software1 by doing it and helping others do it.

Through this work we have come to value:

    Interactions and individuals over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

1

“Within BT the Agile Manifesto has been changed to reflect the end to end

approach that a delivery requires. In BT we value Working deliverables over comprehensive documentation\"

5.3. Agile Delivery Principles (derived from Agile Manifesto)

“Do the right things and then do the right things right” Roger Leaton Agile Advocate

Interactions and individuals over processes and Customer collaboration over contract tools negotiation



Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done



Our highest priority is to satisfy the customer through early and continuous delivery



Business people and developers must work together daily throughout the project



The most efficient and effective method of conveying information to and within a team is face-to-face conversation



Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a

constant pace indefinitely



The best architectures, requirements, and designs emerge from self-organising teams

Working deliverables over comprehensive documentation Responding to change over following a plan



Deliver working deliverables frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale



Welcome changing requirements, even late in delivery. Agile processes harness change for the customer's competitive advantage

 

Working deliverables are the primary measure of progress

Continuous attention to technical excellence and good design enhances agility



Simplicity, the art of maximising the amount of work not done, is essential



At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

The Agile solution

BT Agile is fundamentally a new way of working with core principles of collaboration, iterative working and flexibility. These principles are being applied to the product development process to:

    

involve the customer from concept to delivery

focus attention on the best business led rather than technology led opportunities

decide if and how BT should respond

shape the product or service to match customer needs get it to market as quickly as possible

It does this by bringing people together from across the company to share their expertise and insight. Customers must be involved as well to be sure their needs are met.

Everyone works together to get the product or service to market.

5.4. What are the benefits?

For the customer:

For BT:

     

innovative products and services functionality that‟s „just what I‟m looking for‟

a chance to get involved

a rapid response to changing needs a better customer experience greater satisfaction with BT

     

reduced time to market

solutions with real business value business driven prioritisation flexible products and services that can respond quickly to change more satisfied customers greater success

For the individual:

     

puts you in the driving seat making the job more productive less bureaucracy and improved ability to respond to customer needs collaborative working

seeing tangible results sooner

working in a positive environment

5.5. How does BT Agile Delivery work?

BT Agile Delivery is supported by 7 key components, which have been developed, in partnership by Products, Networks and BT Design and Operate.

The key is that everyone, including the customer, works together. By focusing the breadth of BT‟s expertise on the business solution, the customer has a better customer experience, a better result is achieved and it‟s achieved much more quickly.

Click on the boxes below to find out more about BT Agile’s key techniques/activities.

Round Table

The Round Table enables innovative product ideas to be rapidly evaluated by a cross-section of key stakeholders.

In an agile development a Round Table replaces the Rapid Impact Assessment (RIA).

What‟s the product? Can it be done? How many customers will want it? What are the benefits? How much income will it generate? What will it cost to develop and support? The round table looks at the idea from every angle before reaching its recommendation - stop, park or go.

BT can‟t do everything, so only the best will be taken forward.

5.6. Business Problem Definition

A cross-section of key stakeholders come together to build on the output from the Round Table by exploring the product in detail, testing assumptions about benefits, revenues, costs and timescales.

Their task is to create a more detailed view of the product by use of detailed business scenarios - business level user stories – that will enable development iterations to commence.

In an agile development the business problem definition workshop(s) will replace the feasibility study. The business problem definition will recommend whether the innovation has sufficient business benefit to proceed. A stop, park or go recommendation will be made.

5.7. Hothouse

Hothousing is an Agile development technique that has been introduced into the BT. It forms part of the overall 90 day delivery cycle. As part of that process the expectation is that each programme should hold a Hothouse event at the beginning of the cycle.

That is not to say that the Hothousing technique could not be used effectively at other times, but the general principle is that the cycle is \"kick-started\" by a Hothouse.

5.8. Delivery Iterations

The old way was to specify a product or service in detail, then wait until everything was designed, developed and ready to sell.

BT Agile is different. Now the goal is to deliver real business value every 90 days.

And to ensure work stays on target, activities are planned in iterations that last between 10 and 30 days – whatever the team thinks is best.

Each iteration builds on the last, extending the functionality that‟s available. The important thing is that each iteration will work. It won‟t do everything but it will give confidence that the 90-day target is achievable.

5.9. Common Capabilities

Common Capabilities refers to a set of common re-usable components designed to underpin our product set. An example of a Common Capability would be 'Authentication' which is used for validation of customers.

The capability is stored, together with other capabilities, in a central catalogue. When a new product is assessed, solution designers will determine which capabilities are appropriate for that

product and pick them from the catalogue; the actual physical assembly occurs in the Service Assembly Environment.

From a business perspective, common capabilities will reduce time to market, cost and product complexity while increasing efficiency and consistency of customer interfaces.

5.10. Product Master Files

Product Masterfiles is the source system for product and price data. As new products are launched, they will be \"data built\" on Product Masterfiles, which, in turn, will drive Operational Support Systems (Siebel, Geneva, bt.com etc) across the business. This replaces the need to data build products onto individual OSS component systems and not only keeps product data in step across the domain, but makes it far easier to maintain.

5.11. Service Assembly Environment

As suggested in the title, the SAE is the place where strands of product development are pulled together. Using Agile processes, the SAE enables common capabilities and re-usable services to be combined to form exciting new products and services. As part of the process, products go through rapid modelling, prototyping, trialling and implementation (delivering in 90 day cycles) - it is quick, cost effective and responsive to the demands of the market.

6. Projects for the internship

6.1. Outsourcing skill sets market in China 6.2. ODC site location selection in Beijing 6.3. CFIN project

7. Conclusion

8. References

1. ^ Gerald M. Weinberg: We were doing incremental development as early as

1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, indistinguishable from XP. [. . .] All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development. quoted in Larman, Craig; Victor R. Basili (June 2003). \"Iterative and Incremental Development: A Brief History\" (pdf). Computer 36 (No. 6):

pp 47-56. doi:10.1109/MC.2003.1204375. Retrieved on 2007-02-22. (Permission note)

2. ^ a b Beck, K. (1999). Extreme Programming Explained: Embrace Change.

Boston, MA: Addison-Wesley. ISBN 0-321-27865-8.

3. ^ Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward

Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 4. ^ Agile Manifesto principles

5. ^ Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for

the Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5. Appendix A, pages 165-194

6. ^ Laplante, P.A.; C.J. Neill (February 2004). \"\"The Demise of the Waterfall

Model Is Imminent\" and Other Urban Myths\". ACM Queue 1 (10). Retrieved on 2006-05-13.

7. ^ Sommerville, Ian [1982] (2007). \"4.1.1. The waterfall model\Software

engineering, 8th edition, Harlow: Addison Wesley, pp 66f. 8. ^ As reported by HeavyLogic

9. ^ Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile

methods. In Advances in Computers (pp. 1-66). New York: Elsevier Science. 10. ^ Agile Processes Workshop II Managing Multiple Concurrent Agile Projects.

Washington: OOPSLA 2002

11. ^ \"Supersize Me\" in Dr. Dobb's Journal, February 15, 2006.

12. ^ a b c Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003).

New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-2

13. ^ a b c Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide

for the Perplexed. Boston, MA: Addison-Wesley. ISBN 0-321-18612-5. 14. ^ Supersize Me

15. ^ Schaaf, R.J. (2007). \"Agility XL\Systems and Software Technology

Conference 2007, Tampa, FL 16. ^ Bridging the Distance

17. ^ Using an Agile Software Process with Offshore Development

18. ^ a b Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An

Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138

19. ^ Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile

Software Development Methods: Review and Analysis. VTT Publications 478 20. ^ a b Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On

the Adaptation of An Agile Information Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24

21. ^ Agile Alliance at http://agilealliance.org/system/article/file/904/file.pdf :

PRINCE2 (Projects in Controlled Environments) . . . is a project management method that was specifically designed to be generic and independent of any particular project type or development method. As with DSDM,its use is dramatically on the increase in both the public and private sectors. As a development method and a project management method, the two should be complementary. Some have perceived the dynamic emphasis of DSDM and the

control emphasis of PRINCE2 to be in conflict. However, this is not the case. When DSDM was being developed, those involved had PRINCE firmly in mind. This is reflected in a number of the DSDM principles and techniques – for example, product-based planning, the involved partnership of users and developers, and the strong emphasis on the underlying business case. 22. ^ Kurian, Tisni (2006). \"Agility Metrics: A Quantitative Fuzzy Based

Approach for Measuring Agility of a Software Process\" ISAM-Proceedings of International Conference on Agile Manufacturing'06(ICAM-2006), Norfolk, U.S.

23. ^ McBreen, P. (2003). Questioning Extreme Programming. Boston, MA:

Addison-Wesley. ISBN 0-201-84457-5. 24. ^ sdmagazine

25. ^ Extreme Programming Refactored 26. ^ The Great Pyramid of Agile

 

    

Fowler, Martin. Is Design Dead?. Appeared in Extreme Programming

Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001. Riehle, Dirk. A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn From Each Other. Appeared in Extreme Programming Explained, G. Succi and M. Marchesi, ed., Addison-Wesley, Boston. 2001. Tomek, Ivan. What I Learned Teaching XP

M. Stephens, D. Rosenberg. Extreme Programming Refactored: The Case Against XP. Apress L.P., Berkeley, California. 2003. (ISBN 1-59059-096-1) D. Rosenberg, M. Stephens. Agile Development with ICONIX Process. Apress L.P., Berkeley, California. 2005. (ISBN 1-59059-4-9) Beck, et al., Manifesto for Agile Software Development

Larman, Craig and Basili, Victor R. Iterative and Incremental Development:A Brief History IEEE Computer, June 2003

Abrahamsson, P., Warsta, J., Siponen, M.T., & Ronkainen, J. (2003). New Directions on Agile Methods: A Comparative Analysis. Proceedings of ICSE'03, 244-2.

Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods: Review and Analysis. VTT Publications 478.

Aydin, M.N., Harmsen, F., Slooten, K. v., & Stagwee, R. A. (2004). An Agile Information Systems Development Method in use. Turk J Elec Engin, 12(2), 127-138

Aydin, M.N., Harmsen, F., Slooten van K., & Stegwee, R.A. (2005). On the Adaptation of An Agile Information Systems Development Method. Journal of Database Management Special issue on Agile Analysis, Design, and Implementation, 16(4), 20-24

Cohen, D., Lindvall, M., & Costa, P. (2004). An introduction to agile methods. In Advances in Computers (pp. 1-66). New York: Elsevier Science.

Karlstrom, D., & Runeson P. (2005). Combining agile methods with stage-gate project management. IEEE Software, 22(3), 43-49

Highsmith, J. Agile Software Development Ecosystems. Addison-Wesley Professional, 2002 (ISBN 0-20176-043-6)



 



  

 Waldner, JB. Nanocomputers and Swarm Intelligence. ISTE, 2008, (ISBN 9781847040022) External links

  

Manifesto for Agile Software Development The Agile Alliance

Post-Agilism: Process Skepticism by Jonathan Kohl (This is where the term \"post-Agilism\" first appeared in the blogosphere.)

Interview on Lean for Software Methods

Agile Methods and Other Fairy Tales - One of the few Anti-Agile Papers (this is a link to a company)

Why Agile Software Development Techniques Work: Improved Feedback Risk based selection for agile iterative lifecycle methods

\"The Demise of the Waterfall Model Is Imminent\" and Other Urban Myths Agile, Multidisciplinary Teamwork by Gautam Gosh Agile Requirements by Rachel Davies

Two Ways to Build a Pyramid by John Mayo-Smith

Levent Gurses. \"10 Mistakes in Transitioning to Agile: Slow down the transition in order to go fast\2006-11-01.

Breaking the Major Release Habit - Why are long iterations a hard habit to break?

Agile Toolkit Podcast - Conversations and Interviews related to Agile Software Development

Video - Why does Agile Software Development pay? - by OutSystems Agile Modeling: Effective Practices for XP and RUP by S.W. Ambler. TechBookReport An archive of book reviews devoted to a range of software methodologies, particularly Agile (including Scrum, XP and other agile processes).

Agile at the Open Directory Project

Agile Methodology Overview - OutSystems Agile Methodology Overview What's Wrong With Agile Methods by Tom Gilb

         



  

  