…Due to the United State’s Army’s strategy to meet its targeted critical requirements, there was a call for higher agility in its software development process. This blog is going to outline how Extreme Programming can work into government departments which traditionally ulitlised more traditional software. This blog will focus on XP’s development of an innovative capability for the United States Strategic Command’s main knowledge system, which is called SKIWeb. Many lessons were learned which will aid future workings of XT programming
A decentraliziation of information was called for in within the US Army, due to ever-changing requirements, as heads of both the military itself and the government, demanded more swift and easier ways of getting essential information.
Net centric service orientated architecture (SOS) had been used as a key pat of their strategy to localize the infrastructure. However, the high level document requirements combined with the linear nature did not suit the military’s software ambitions for decentralization. In-vain efforts to develop Spiral (which broke the Waterfall approach into smaller iterations) attempted to develop the ideal solution, but failed!
Offutt Air Force, Nebraska is where the United States Strategic Command (USSTRATCOM) is based. Within the US military, this base covers responsibilities for missile defense, control functions and global commands. Their purpose? To share information of both world events and military operations to the intelligence and the military’s strategic command. Strategic Knowledge Integration Web (SKIWeb) is a tracking tool used in USSTRATCOM. All personnel from the top down can communicate and use this software.
SKIWeb, it was decided would adopt the XP method of Agile software. The twelve fundamental principles of simple design, test-first development, pair programming, integration, on site customer, unified coding, incremental planning, small release, refactoring, collectively owned, system metaphor and sustainable pace were hugely attractive to the needs at the Nebraska headquarters.
XP phase 1’s aim was to test an XP process, to fit around the SKIWeb’s existing capacity. When this pilot finished, a review was initiated by the project developer and furthermore a debriefing session was undertaken by the researchers to the relevant military personnel based in Nebraska. Numerous evaluation surveys were complied. Phase 1 lasted from August 2007 through to the end of October that year. Four iterations of innovative capabilities were concluded. These iterations were initially intended to occur bi weekly, however due to holidays, vacations and other problems; these iterations sometimes took place every three weeks.
During the implementation of phase 1, the researchers observed that the government functional manager and the developers (collectively knows as ‘user collaborator’) had conflicting assignments in work thus inhibiting the work flow. They further found that they had insufficient expertise to implement the aforementioned user collaborators type of search capability, which they sought. There were several communication issues discovered during the tenure of phase 1.
Conclusions from Phase 1 of Introducing XP
To find out how phase 1 went within the Extreme Programming project, the stakeholders were asked to complete a survey. The use of open questioning in relation to the communication (or lack there-of) within the group and numerous other questions, which focused on the 12 agile practices. From the statistical data provided, it was reported that Small Releases, Sustainable Pace and On Site Customer were the most used of the XP practices. Neither Pair Programming nor Test-Driven Programming was used at all. Low standard deviations and high average scores referred to by most of the project group for Small Releases, On-Site Customer, Incremental Planning and Continuous Integration confirmed that these were a huge success. Pair Programming scored low in both importance and usage, this, the only XP practice given such a score.
To summarise, it would be fair to say that numerous lessons could be learned from this example of introducing Agile software into a government department, such as the military. Communication issues were certainly prevalent. It would be wise for me to say, that one cannot draw conclusive findings from just one case study, several more should be conducted and analyzed in order to gain a more definitive insight into both trade-offs and risks which arise between agile software and more traditional approaches……
..in my final blog, I shall discuss the perceived future for Agile, in particular Extreme Programming…