The Twelve Principles are the guiding principles for Agile methodologies. They describe a culture in which change is welcome, and the customer is the focus of the work. These principles bring development into better alignment with business needs.

The twelve principles of agile development include:

1. Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress.
2. Attention to technical detail and design enhances agility – The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.
3. Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned.
4. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams.
5. Enables face-to-face interaction – Communication is more successful when development teams are co-located.
6. Customer satisfaction through early and continual software delivery – Customers are happier when they receive working software at predictable intervals, rather than waiting extended periods of time between releases when nothing tangible is delivered.
7. Self-organizing teams encourage great architectures, requirements, and designs – We allow the best resources to set the agenda to best deliver on milestones; allowing those skilled leaders to motivate other team members, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.
8. Built in Self-assessments deliver more effective efforts, faster – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.
9. Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes.
10. Regular, incremental delivery of working software – We use Scrum to perform software sprints or iterations able to repeatedly deliver working software.
11. Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable speed at which to deliver work products.
12. Simplicity – steady, focused development always ranked at highest priority.

The intention of Agile is to more quickly and tactically align applications development to business need; to find wins quickly and prioritize those of most value before those with long development reach. Agile projects are customer focused and encourage customer guidance and participation. As a result, Agile has grown to be an overarching view of software development throughout the software industry and an industry all by itself.

Perhaps nothing better illustrates Agile’ s value when development requires on-the-fly programming changes through method tailoring. Agile methodologies allow the Agile team to modify processes make them fit the objectives versus the other way around. In Agile, the development approach processes can be adjusted to address the dynamic interplay between contexts, participants, and method fragments. Agile is built to address those changes in priorities in real world flux.

Many clients want a clear budget and a deadline, and, in some cases, they don’t want to be involved; they just want systems to work by the end of the Contract.

Once applications development is awarded on waterfall, Clients assume that months of waterfall delivery design development are required with little client collaboration; providing little tangible evidence to proper completion (i.e., nothing to see or touch other than high level documentation that is conceptual and has no real tangible connection to the business need). The result is that waterfall development teams’ delivery can be behind or off course due to lack of detailed requirements confirmed by the customer. But of course, under an already awarded federal contract there is no ability to change development methods or approach due to the strict nature of the federal contract.

A great example is the 2014 ACA Healthcare registration website. The scalability and testing requirements were flawed from the start and required updating prior to full production. Agile testing would have discovered this well in advance of the Go Live launch date.

Sell Agile methods to better address overall project and deployment risk. So, SW Dev companies are left to solicit Agile to our Federal customers prior to RFP release. At this stage we also have a hard time getting them to adopt Agile methods. We find that in many cases it is hard to sell a client on an agile project when our competitors do come up with waterfall-based fixed deadlines and fixed prices. We know their fixed numbers are bad, but the client doesn't know that because there’s nothing for them to confirm reasonable at incremental stages. So, our Agile comparative bids end up looking bad to the client because we can't fix the price or a deadline to the client’s pre-conceived waterfall approaches as there is perceived undo risk associated with any change in approach like Agile.

Try Selling a Services support contract. Basically, when you first sell the client on Agile, you sell them based of your expertise, and you do it waterfall. That means a contract that sets the scope and a firm deadline. This is what the client wants. And in this case, it gives the client a level of comfort when the tendency is to be nervous because he has never worked with you before. That’s Ok, Agile is not always better then waterfall.

So, you have a fixed price contract for X scope. Then you tell the client “Look, you are going to want to make changes, and you are going to need us to support you post production, let’s set aside 20% of your budget for these things to be used on an as need basis by means of a support contract.”

Should a change come up during the project, simply defer it to be handled under the support contact. (Assuming this change would cause a serious disruption to the project).

The terms of the support contact are as follows “Work to be done on a per hour basis, as requested by the client, can be used for change requests or general system support and maintenance.” And there you have it, you can then operate in an Agile method or approach.

You can then continue to extend the support contact, and simply use the support contact as the means to run new projects. Additionally, if these hours are purchased and paid for upfront, we usually give the client a discount and/or incentives. It's Win-Win.

Agile doesn't preclude deadlines and budgets. If I was a client and I went to a developer and they told me that they couldn't give me a deadline or an estimated cost, I'd question their sanity. And telling them that they just don't understand isn't going to work they need to be able to budget and plan.

Often Engineers Underestimate Complexity.

But more often this is due to the way contracts are awarded. Price is the over-riding factor with ability to do the job only a minor subset of considerations. Again, in the case of the ACA website, those companies who understood the complexity and could really do the job, because they've built similar systems before, were knocked out of the bidding process early on because their costs were too high. Thus, the contract goes to the incompetent low-cost company and Agilists then try to blame waterfall. Competent companies and people will deliver no matter what methodology. The main hurdle in achieving the benefits of Agile-Scrum outside software development is integrating it with existing control mechanisms. These control mechanisms are stipulated due to various organizational prerequisites and are normally actualized by using the Linear Waterfall approach and methodology.

In the past couple years, pockets of the federal government have tried to promote agile software development, a process in which customers and coders work closely on small chunks of larger tech projects, rapidly spinning out and testing prototypes.

Government transition to agile is bumpy, and adoption uneven to-date. To fully embrace it, agencies have to make some nontechnical changes, including adjusting how their inspectors general evaluate technology projects.

In 2018, about 90 percent of industry projects involved experimentation, speed and quality characteristics of the agile methodology, but government lags behind. Government has been slow to embrace change and to acknowledge that software development projects face unknowns, including user requirements, design, schedule and cost.

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.