Agile Case Study: Waterfall vs. Agile - SM&A

402kB Size 5 Downloads 64 Views

Agile Case Study: Waterfall vs. Agile 2 29 October 2015, V1 © 2015 SM&A. All Rights Reserved. building a system of systems, and these guys are talking about
Agile Case Study: Waterfall vs. Agile

Jacque Keats EVP Sales & Operations 29 October 2015, V1 © 2015 SM&A. All Rights Reserved.

Agile Case Study: Waterfall vs. Agile

1

A large aerospace and defense contractor comprised of over 29 operating companies providing maritime automation/control, navigation, communications, dynamic positioning, and power distribution/ conditioning systems, realized a significant reduction in their engineering productivity and a corresponding increase in rework. The firm recognized that addressing these challenge requires it become more agile. The firm also recognized that deeply engrained adherence to the tradition of existing engineering process makes change difficult. To assess the applicability of agile methodologies in their engineering environment, the firm’s management selected two projects that were very similar in scope and for the same customer. The firm assigned the same project team to each project and executed them linearly. The first project used a waterfall methodology and had the same challenges experienced on other recent projects including missed deadlines, failure to meet requirements, and significant rework in hardware and software. The second project used an agile methodology, and while there were initial problems with the

29 October 2015, V1

learning curve, the project was a resounding success.

Using waterfall yields unsatisfactory results

The situation

Consistent with recent projects, the first project experienced changes in requirements resulting in many deficiencies. There was a long lag time between expected delivery and actual delivery. The effort had several hardware failures and substantial anomalies in the software. There was a lot of churn throughout the project with disappointing results. Both the firm and their customer were frustrated.

Management selected a senior program manager; with a proven record of accomplishment, to manage the two power system projects for similar weapon system platforms delivered to the same customer. Both projects were very similar in scope. The program manager used the same team for both projects. Both projects had fixed price contracts. The first project executed using a traditional waterfall approach. The second project completed using the same development team (a team that was new to Agile) using agile methodologies. The waterfall approach dictates that requirements are complete before design begins. Typically, once the requirements phase completes, the stakeholders do not get involved again until the test and acceptance phase of the project. With an Agile approach, the stakeholders remain involved throughout the lifecycle, with regular reviews and updates to the requirements.

© 2015 SM&A. All Rights Reserved.

Initial transition to Agile The team knew they needed to do something differently, they decided to try an agile approach for the second project. As part of their startup efforts, they read several books on agile and attended Agile training. They also enlisted the services of an Agile coach to help them through the transition. Although not entirely unexpected, there was a lot of initial cultural resistance to change. The engineers did not like it, thinking the methodology was too “touchy-feely.” There were several heated meetings where one or more engineers stated, “Uncertainty is the enemy! Without all of the requirements defined in advance we will fail.” “We are

Agile Case Study: Waterfall vs. Agile

2

building a system of systems, and these guys are talking about commitment.” Several people asked to be reassigned. The project suffered through many problems. The hardware had several issues during brass board mockups, and the software test cases did not match the logic, which was convoluted and confusing. After three iterations, a look at velocity and burn-down charts showed that progress was getting worse rather than better. The team made a tough decision: Stop and regroup.

The turnaround The team decided to use the fourth iteration to re-examine the requirements. This review resulted in a recommendation to have engineering stop the effort for three weeks to work directly with the customer who had defined the requirements. At the end of that period, it was clear that the original requirements required rework. The team took the original 800 requirements and distilled them into a clear, concise, and complete definition of the system. The team was able to rework the information to under 300 organized and logical requirements. This redesign of the requirements was the turning point of the project. It also 29 October 2015, V1

enabled the team to leverage recent innovation in the design the reduced cost of the system.

more system coverage. System performance was high and the customer applauded the operator interface.

This change in direction was only possible because of the agile nature of the project. The program manager stated, “The cost to change the system this far downstream would have been too high [using our traditional model]. And in a firm fixed price (FFP) contract environment, we would have experienced significant overruns and lost customer confidence. The ability to change requirements midstream was a major key to success.”

The bottom line: the Agile project delivered early, under budget, and the customer is pleased.

The results With the reworked requirements, the team was set to start practicing Agile as intended. Velocity increased as the backlog decreased. Even with the three-week delay to regroup, the project finished early and under budget. In all respects, the project was a success. Comparing the execution of the two projects, the Agile project scored higher in every category. Quality was better and the test/system validation was much smoother. The project had fewer test cases, but

© 2015 SM&A. All Rights Reserved.

Keys to success The firm attributes success to two important factors: Agile training and the regroup effort. “We made the right decision hiring SM&A to assist with the implementation of Agile, grounding the team in Agile methodology.” Going it alone would have been difficult. The project team had limited experience and exposure to Agile before starting this project. Implementation support, training, and coaching were key. The project team had a major disconnect in their understanding of customer requirements halfway through the project, but in midstream were able adjust course quickly implement a design to meet the customer requirements. Agile provided the flexibility enabling the team to regroup. This inherent flexibility is a primary success factor.

Comments