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.

Why the Move to Agile?
Within this product development group, releases generally occur annually or even less frequently. Traditionally the last two to three months of a release were a "fire drill"; long hours by the entire team. The team was assigned tasks by roles in what I would

Figure 1: Building the "Right Product Right"

When thinking about successful product development and delivery, you should think in terms of building the "Right Product Right." The left-hand most ‘right' represents validation (the customer's perspective) and the right-hand most ‘right' representing verification (meeting all contractual specifications) of the product (see Figure 1).  Invariably, the team ended up meeting contractual specifications without meeting the customer needs; the product lacked validation (see Figure 2).

Figure 2: Meeting specifications but not meeting customer needs  

The Road to Agile
Approximately three years ago, pressure really started mounting to deliver the "Right Product Right" quicker while meeting target costs and we started looking into new ways to deliver product to our customer. We originally looked at the Evolutionary Spiral Process Model[i] and after consultation with Barry Boehm we were led down the path of Agile practices. After three months of research and additional conversations with Agile thought leaders, we learned that there was no ‘recipe' card with the answer for us. Experimentation with various Agile methods and practices was key and we settled on a Scrum framework with Agile best practices pulled from XP, Crystal, Lean, and others for the initial pilot phase of implementation. 

Why Was Agile Chosen From a Management Perspective?
Management understood the issues with the early releases and was intrigued by the prospects of Agile. Of the many areas in which they sought improvement, four were consistently part of the management mantra. These four areas were managing changing requirements, increasing productivity, ensuring quality standards were met, and developing and delivering a product increment more often (see Figure 3).

Figure 3: Management priorities  

Getting Started
Prior to the launch of the pilot, extensive coaching and training occurred within various groups of the development team. We chose two different coaches for particular areas of coaching and training. Mike Cohn[ii] was brought in for the Certified ScrumMaster course and the Agile Estimating and Planning course for roughly eighteen and forty-four people respectively. Both Ken Schwaber[iii] and Mike Cohn ran a Certified Product Owner course for twenty-two people.

In choosing coaches and trainers I would maintain that these trainers must have certain characteristics:

• They must have practical experience - too many trainers/coaches/consultants do not practice what they preach and skills decay when unused.

• They must be 2^nd tier at worst - the further from the originating source of the practices, the bigger the breakdown of original intent.

• Specific domain knowledge should be seen as a bonus.

A final note on coaches and trainers:  You should always try to use the same training source throughout the project, if not throughout the organization, and all phases of implementation to reduce the amount of disparate interpretation of practices, i.e., confusion.

The implementation approach broke the action plan into three different phases: Pilot, Department Launch and Enterprise Rollout. Subsequent phases build on each other and reach outward. I like to view this as ripples on a pond - after dropping a stone into calm water, each ripple gets bigger while surrounding and engulfing the inner ripple. 

Barriers to Implementation
Implementing change within any organization is difficult to say the least. In this context, change is a paradigm shift from one way of thinking to another in terms of product development and delivery. Change does not just happen; it is driven by agents of change. Figure 4 shows the most significant barriers to entry into the Agile development world as viewed by project personnel and business level managers, many of whom have been trained in Lean and Six Sigma principles. 

Each barrier was inspected and the adaptations that were found to work for us are described below.

Resistance to Change: Coaching, mentoring and ten percent attrition. Some team members simply cannot make the paradigm shift to Agile methods.

Personnel with Experience: Training and hiring - finding capable and disciplined staff can be a struggle.

Management Support: Consulting and training by third-party experts - this is important as it is human nature that people will buy-in more to outside experts saying the same thing as internal personnel. Management is accustomed to traditional methodologies and will need help guiding them into the understanding of Agile principles.

Customer Collaboration: Coaching, mentoring and TIME.

Contract Type: Management and customer mindset. 

Implementation By Phase  

Pilot Phase
As evidenced in Figure 5, the pilot phase was started two and one-half years ago. Agile methods were introduced to several small teams using coaches in a ‘just-in-time' manner. Likely cultural issues and organizational impediments were anticipated and dealt with up front as were both physical location and layout. The group involved, even in the pilot phase, included teams in three time zones and three locations. Throughout the implementation of the pilot phase and as a champion for Agile practices within Lockheed Martin, I made sure that Agile concepts and practices information were available to interested parties and senior management within the company.

Figure 5: Lockheed Martin timeline  

Importance for Tooling in a Distributed Environment
Although there are some within the Agile community who are still opposed to tools in general, the use of an Agile lifecycle management tool was imperative for success at Lockheed Martin. With project teams in multiple locations and time zones, we needed a tool that would ensure project visibility, tracking, and reporting across projects. The reporting aspect was of particular concern to us as we work in such a highly regulated industry. The web-based project planning and tracking allowed us to maintain the collaborative aspect of Agile development. From our pre-pilot Agile training and coaching we knew that the best case scenario would be to have the entire team collocated to increase interaction and face-to-face collaboration, but this was just not a reality. This would be amplified as we moved into our department and enterprise phases of our rollout. The use of a web-based tool was the next best thing to make sure that all stakeholders had visibility into the project. A key consideration was that this tool needed to be ‘enterprise-ready.'  We evaluated each tool not only from a pilot phase perspective but looked at using each tool from pilot through enterprise rollout.

After looking at all available options, we chose V1: Agile Enterprise from VersionOne. This tool takes care of our work item, release and iteration planning, and management. The extensive reporting features in this product allowed us to both monitor and communicate project status throughout our pilot phase. During our department rollout phase, VersionOne provided a web-service API allowing us to create custom reports that can be communicated throughout the organization in ways management is accustomed to seeing project information (see Figure 6). The key to this tool is that all stakeholders from the program have the ability to access the state and health of the project at any time; the information is just one click away.
 

Figure 6: Project status report

Pilot Results
For the pilot, we picked a project with a six-month development timeline using traditional estimating procedures. The entire project was completed within four months with team members working an average of 43 hours per week (see Figure 7). 

Figure 7: Actual Agile project versus traditional estimate  

Department Launch
After a successful pilot phase, other projects within the business area were introduced to Agile methods. With multiple projects working in the new paradigm, barriers needed to be re-addressed. In order to maximize the likelihood of success and to negate the common barriers, we needed to: 

• Codify the organization's understanding of Agile.

• Formally establish a coaching model.

• Establish an office layout/collocation policy.

• Establish Agile Forums within the Organization.

• Have senior management promote Agile product development.

A significant majority of those polled within the business area stated they saw a greater than ten percent improvement in productivity, product quality, our ability to produce a product quickly with customer satisfaction (Right Product Right) and overall reduction in cost of development (see Figure 8). An important element to understand is the scale at which we are discussing these improvements. In projects that are the size and value of those at Lockheed Martin, even the smallest improvement in any of these areas is a major victory.

Enterprise Rollout
Our plan for rolling out Agile methods across the enterprise is directed toward the organizational changes needed to support an Agile work environment rather than focusing on Agile practices. As we continue to bring teams and projects onboard, the functional areas and human resources need to change to support the every-growing employee base working with Agile methods. Some of these changes include the need to:

• Establish parameters around distributed projects with Agile.

• Review and align personnel with Agile teams.

• Review HR hiring policies.

• Establish promotion policies.

• Establish training model for coaches and Agile teams.
  
  
• Establish Agile peer groups.

As with any change or metamorphosis, we must emphasize the positives and look at the negatives as opportunities. We feel very confident that Agile methods are allowing teams to focus on the most important tasks yielding small but significant victories. These victories were made possible because of early risk identification and mitigation, frequent and constant feedback from customers, larger capabilities broken down into bite-size chunks allowing focus on smaller increments of the product, increased product quality as the team's pace leveled out, and team retrospectives that enabled rapid change to the processes and team behavior. 

Future of Agile within the Organization
We are currently in the final six months of our Department rollout. We are using this time to solidify our best practices and will soon be conducting our Enterprise rollout. We will continue our ongoing training efforts and will evolve as a project, program and organization through inspection and adaptation.

For Those Just Getting Started
When asked for advice by other looking to implement Agile practices within their organizations, I usually touch on a few key things. They include:

1. Contract with a consultant to educate your entire exo-team. This is where outside expertise will be able to convey the benefits, requirements and realistic expectations to your management team.
   
   
2. Hire an Agile partner to train and coach the various members of your team - sending one team member to a Certified ScrumMaster course or having the team read a book will not be sufficient for organizations or teams of any complexity.
   
   
3. Report outside the Agile project in terms that your organization is used to - don't make it difficult for anybody to understand the status of your project.
   
   
4. Under Pressure? Don't abandon the practices!

Whether your project, program, or organization starts the transition to Agile methods from the top-down, the bottom-up, or from both ends simultaneously, someone has to be the champion of the transformation... Why not you?

About the Author
Michael Zwicker is an Agile Product Development Analyst at Lockheed Martin within the Simulation, Training and Support group. He has 10 years of Agile product development and 27 years of System and Software engineering experience. Mr. Zwicker is a Lean Six Sigma Black Belt, Certified Product Owner, Certified ScrumMaster Practitioner and a member of both the Agile and Scrum Alliances.

[i] Boehm, B.W. (1988), "A Spiral Model of Software Development and Enhancement," Computer, May, v. 21 no. 5, pp. 61-72.

[ii] Cohn, M., President Mountain Goat Software. http://mountaingoatsoftware.com/index.

[iii] Schwaber, K., Agile thought-leader and Founder of Scrum. http://www.scrum-master.com/

Comments (11)

Nazeer: ... Hi Mike, A Nice case study. I need few templates that had been used in the project. Please suggest. Thanks Nazeer Email : This email address is being protected from spam bots, you need Javascript enabled to view it 1 June 23, 2008 raj - on agile based solutions and enterprise rollout: ... hi mike, just came across this article of yours. its very neatly put and brings out the real aspects pretty well. appreciate your effort and publishing of the experience. am working on a similar track right now - trying to incubate the 'product implementation' culture using agile techniques in an organization... would like to know how your work on Enterprise rollout is going about...may be we could collaborate over chat sometime ... -raj 2 January 27, 2008 Alan S Koch: ... In Figure 8 (your poll), the respondents cited Increased Productivity, Reduced Software Defects, Accelerated Time-To-Market and Reduced Cost. These are the kinds of things we would all like to see numbers on. Have you gone beyond merely *polling* people and studied the data? If so, what are the chances that you can publish some of it? 3 July 14, 2007 Hi,: ... Sincerely appreciate your point of view. There is far to little documentation on successful agile projects. Can you say anything regarding the system of contract? I understand how complex and confidential they are but, in general, what were some of the specifications you included and how did you incorporate agile into the contracts? Thank you, Kate 4 July 11, 2007 Mike Zwicker: ... Adam, Would be glad to chat. You can reach me at This email address is being protected from spam bots, you need Javascript enabled to view it Mike 5 April 29, 2007 Jyothi Talaparthy: ... Good case study! This will help some of the beginners into some insights for successful adoption of Agile. 6 April 20, 2007 adamkalb: ... Good article. We are embarking on the same journey in our company. Would you be open to chat more in depth some time? Thanks, Adam 7 April 19, 2007 Sarat Maharana: ... It's a fantastic article. 8 April 19, 2007 Yogesh Puranik: ... Hi Mike, Really a nice case study. Neatly written, really very impresive. I am a new learner in the Agile methodolies. If you have any details regarding the same, request you to please mail me those details on following email id: This email address is being protected from spam bots, you need Javascript enabled to view it 9 April 18, 2007 Mike Zwicker: ... Thank you for your positive feedback. This has been a long journey to date but very rewarding. I'm looking forward to the 'Enterprise' rollout and the challenges that will bring. Mike 10 April 18, 2007 buiswhiz: ... Hi, Thanks for presenting a precise case study which is really thought provoking. Cheers, D.Karthikeyan. 11 April 17, 2007

Write comment

Name

Comment

Write the displayed characters

Add Comment

Tags:

Click to add your tags...,

or Close