In the previous chapter, I already talked about my experience at ANOTHER DEPARTMENT. We had a big robust system in which we had already made a substantial investment. This system that we were growing was a Linux/Apache/MySQL/PHP or LAMP platform. We had a big application on that platform and we tiered the platform to host multiple applications on it. The same benefits that I found at my former agency when talking about the J2EE/Solaris/Oracle environment were found again when I could talk about all of our application being on the LAMP.
There are several benefits from being in this type of situation:
- Talk to industry in very concrete terms
- Industry is better able to take risk out of their proposals (risk = cost)
- Better able to compare proposals
- Buy hardware and software to scale
- Develop specialized assistance resources
When an organization starts thinking in platforms all of the other questions start to accrete. Data centers begin to grow and become more robust and thus more efficient. Virtualization increases because it is the only way to meet the increased demands for provisioning new environments. And that rapid provisioning of environments is the core capability that must be in place before engaging an agile development practice. If you can spin up three environments in an hour then I know you are prepared to develop with the agile ethos.
WaterFAIL
Before I go into how to establish an agile development environment in your agency, I think it is worthwhile to review why every agency should adopt this development life cycle. In order to do that, we need to get a DeLorean and go 88 mph to check in on first-, second-, and third-generation programming languages (1GL, 2GL 3GL). These languages are also known as machine code, assembler languages and higher level programming languages, respectively. Though the ’50s, ’60s, ’70s, ’80s, ’90s, and some of the 2000s government agencies were using these programming languages to automate processes. In most instances they were using a concept known as Structured Programming or Procedural Programming. Structured programming is based on logical operators that were sequenced to perform specific tasks. For example, do A, then do B, then do C…. In this scenario, where you can have a whole lot of activity steps, you want to map out what the universe looks like before you start writing code because before you know it, you will be on step Z and you will learn something new about step A and you will need to start over. As such, for 45, almost 50 years, the best course of action was to engage a very deliberate process to gather all the requirements, get approval for the design, write code and then test it all out. All the while, the applications that people are developing are increasing in complexity.
This development life cycle is known as Waterfall because each step must be complete before engaging the following step. As a result, you had a series of waterfalls that cascade into one another.
Remember for 45 to 50 years developers were using this process, and during that time, contracting officers were supporting this process with acquisition processes and standards. Their acquisition processes evolved to have checks and balances that integrated well with the waterfall life cycle. I’ll talk more about this in a future chapter, but these waterfall concepts are baked into the Federal Acquisition Certification Program and Project Management (FAC-P/PM) training and certification standards.
