When you think of a highly regulated, very large company like Lockheed Martin, you would not tend to think of Agile development projects. Lockheed Martin is a Fortune 500 company that consists of four business areas, has 140,000 employees, is located in 45 states in 457 cities, and has 939 facilities in the United States alone. Internationally, Lockheed Martin is present in 56 nations and territories. The implementation of Agile practices at Lockheed Martin was not a case of finding Agile and seeing how it could fit, but looking for a better way to develop software-centric products and finding Agile. {sidebar id=1}

Delivering working software against all odds by using tools, metrics, and guerilla XP tactics

The project that StarSoft Labs implemented for a large multinational telecom company in Europe has been one of the most challenging, unconventional, and rewarding XP exercises for us so far. All development and testing was done 100% offshore in St. Petersburg, Russia, for the remote customer. We built an Intranet resource and project management application. Now, 30 months later, the system has 1500 users across four countries. The offshore XP team has grown from three to 17 and has delivered 18 versions of the system into production. One of the major achievements was bringing the defect rate down while keeping good velocity and implementing changes rapidly.

State of Ohio Automated Child Welfare Information System (SACWIS)

Agile development continues to gain traction in enterprise IT organizations, but myths and misconceptions slow the pace of acceptance and preclude the use of Agile methods in situations where they could otherwise add significant value. Part of the issue is the simplicity of its philosophy as stated in the Agile Manifesto, which leaves plenty of room for (mis)interpretation and leads to myths such as Agile is anti-documentation. Other myths arise from misunderstandings of common Agile practices. Executives, managers and practitioners familiar with traditional waterfall and RAD approaches are shocked to discover that cherished metrics and practices don't apply on Agile projects, leading to mistaken assumptions about the lack or inadequacy of project management, requirement management, quality assurance and other key project controls. Agile purists complete the picture through dogmatic pronouncements of what is and isn't truly Agile. This article uses experiences from a highly successful large development project to debunk four common myths: Agile projects don't control scope, Agile projects are difficult to manage, Agile approaches don't scale, and Agile methods are just for programmers.