Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function. While Agile values documentation, it values the effort to achieve working software more.

In the Federal Market, we are seeing trends in awarded contracts that join the collaborative efforts of the procurement, business management, and delivery teams. The Contract typically is a general skeleton or landscape of how Agile service or product delivery is worked out, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This this method to be successful, the customer must be involved in the process of development before development begins and after it is completed, but not during the process. Agile methods actively involve customers all along the way, engaging and collaborating throughout component development. This makes it far easier for development to meet their needs of the customer, and the customer has expectations as Software is being developed. Agile methods may include the customer at intervals for periodic demos, or end-users could be engaged in daily briefs as in integral part of the team meetings, continually ensuring the product meets the business needs of the customer.

The first tenant in Agile methods is “Collaboration Matters More Than Process and Tools.” Valuing collaborative effort more highly than processes or tools is easy to understand because it is this jointly focused effort of people responding to business needs that can drive a highly effective development process. If the process or the tools drive development, the team tends to be more responsive to meeting tools or process standards versus customer needs. Communication is an example of the difference between valuing individuals versus process. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.

Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.

Chameleon Technology Partners (CTP) assists businesses when presenting their capabilities to Federal and Corporate acquisition teams. Our team can help you design and develop the infrastructure or software to win your next bid. CTP has performed successful Enterprise Architecture and Systems Engineering in both the Federal and Corporate IT Sectors since 1993. Contact us today to discuss how we can help you design, develop, and win your next IT business opportunity.