Success with Agile Project Management in General Dynamics

With regards as to why General Dynamics opted to employ the Dynamics Software Development Methodology (DSDM) as the agile framework for their project, one can speculate they did so to help relieve their respective stakeholders of common software development issues such as being too costly, overly rigid or producing an unreliable solution of questionable quality. By using the DSDM framework, General Dynamics was able to quickly develop a solution that seemed to have met or exceeded stakeholders’ expectations but were also able to do so within budget and delivered on time.

The philosophy of this method is that true solution or business value can emerge when projects are aligned to clear business goals. In order to accomplish this and to deliver, the team must first be motivated and feel empowered.

The framework provides the blueprint for Project Teams to follow that will allow them to understand the business’ need, by better understanding and establishing the high-level business goals. Combining this with the constant feedback of the stakeholder of business needs as they adjust, the team is better able to deploy a quality application into live operational use.

The clear definition of roles and responsibilities along with communication techniques used to collaborate further underlines the ability of the project team to deliver consistently and efficiently. Again with constant communication to the stakeholders, help further prioritize the work of the team and help ensure that what the team delivers is within budget, what the client wants and is delivered on time.

The DSDM model essentially provides a fixed time and cost to the client and allows for flexibility of features. This allows the team to essentially trade out requirements that are not completely necessary and focus on providing solution musts in the solution and adding the bells and whistles as they can within time and budget. This further helps ensure that the team is able to produce an application/product to the end user that will be acceptable, applicable and deployable upon delivery.

The flexibility of the features comes from the project requirements being categories using the MoSCoW Prioritization approach (Must or Should/Could or Would like to have). By categorizing items in this manner, the team is able to ensure that all the Must haves of the solution are developed tested thoroughly and completely meets the requirements of the stakeholder from Day 1 through the end of the project. Without the must haves, the solution would have no value to the stakeholder whatsoever. This helps ensure the Musts receive higher priority over other items until successful completion. The project will have various iterations or sprints in which the deliverables are categorized using this method. If for example a sprint is 6 days, then the team will prioritize items alongside the stakeholders on the Musts, Should/Could and Would like to haves accordingly and work toward that goal.

In the event there are issues along the way, items can be adjusted on the next iteration or sprint to ensure the items needed are completed and anything unnecessary that can take away from that is tabled. For stakeholders, this allows them to ensure that the cost is kept where they would like it to be as well as ensure that the solution can be delivered promptly.

With regards organization and governance of the project, it is important to ensure that all roles are clearly defined and there is a general consensus and support of the project from outset. In the case study, CIdS TDP employed what they referred to as the “Space Alien”. This organizational structure allowed them to ensure that (1) there was the appropriate governance within the project by scheduling reviews with General Dynamics UK during the respective iterations/phases of the project and (2) the correct team members would be selected as they would need to be able to collaborate effectively with their respective teams and accept that there will be a fair amount of uncertainty for many reasons.

Having reviewed the above, one would consider the value of the Agile Coach role. The Agile coach is essentially responsible for coordinating between the respective teams, moderating any issues that may arise and hopefully be able to communicate and decipher any technical issues/jargon to the parties that need the translation. Agile coaches greatly help manage items within endeavors such as these that the Project Manager may be remiss to or otherwise unable to handle. They are valuable, as this particular study has shown.

Once the organization and governance of the project had been established, it was necessary for the communication channels to be established. The benefit of this particular method is that communication should be open and unfiltered. By unfiltered, consider an open, honest forum where frustrations will naturally develop; however, can be effectively addressed to continue working toward the benefit of all. This environment was fostered a several communication methods (email, shared work environments, telephone/video conference, etc.)

By effectively deploying a team structure and clearly defining and simplifying communication by eliminating barriers, the team is able to do what most traditional project methodologies are not able to do. Mainly because with those traditional methods, information is generally kept until that particular phase is completed, then it is disseminated, by which point, the turn around time can be quite significant and adjustments that should have and could have been made can no longer.

Given the end result, one would be remiss not to see how beneficial the DSDM truly is. General Dynamics’ team masterfully employed the approach. It seemed to clearly produce a much better solution for the military than was initially conceived, especially when one considers how often a military project’s scope can bloat exponentially and rapidly. The ability to clearly define items that were absolutely necessary within the solution helped the team become laser focused on the end goal. And because the team was in constant communication with the stakeholder, they were better able to understand the overall mission of the organization. One side effect of that was that it helped to motivate the team to complete the project as they were constantly getting feedback from the stakeholder while also empowering them to provide feedback to the stakeholder immediately. Safe to say that when motivated and empowered individuals collaborate, great things can happen.

The DSDM clearly provided more business benefits than the traditional response. For any stakeholder, the ability to receive a quality solution, within budget and on time is a roll of the dice at best. By employing the DSDM method the end result was a final product that was what the fog of war has been dispelled. Constant stakeholder involvement throughout coupled with project team feedback helped ensure that all the final deliverables were spot on and everything that was needed was there along with any additional items that could have been added. One would call that a “win-win” scenario.

References

Michelle Johnston Sollicito. (2001, February 9). To DSDM or Not to DSDM? | To DSDM or Not to DSDM? | InformIT. Retrieved May 12, 2017, from http://www.informit.com/articles/article.aspx?p=20696

Agile Business Consortium. (n.d.). Introduction | Agile Business Consortium. Retrieved May 13, 2017, from https://www.agilebusiness.org/content/introduction-0

Matthew Caine, M.C. Partners & Associates. (n.d.). Introduction to DSDM Atern. Retrieved May 14, 2017, from http://www.methodsandtools.com/archive/dsdmatern.php