The Government Impact
The last really big thing that you have to be prepared for before embarking on an agile lifestyle is the effect on the government team. Especially if you are transitioning from a waterfail-like development paradigm, pretty much everyone on the government side needs to get their shit together.
- The data center/network/infrastructure team needs to be able to spin up several development and test environments on day 1. These environments must be virtual, and they better be under strict configuration control. They have to patch and maintain the environments (if they set it and forget it, they will be shot). Finally they better have the production environment ready on time for the initial launch.
- The Information Security Office (ISO) is a stakeholder in the project just like the business owner and everyone else. Historically the security people have initiated their Certification and Accreditation (C&A) process, now the Assessment and Authorization (A&A) process very late in the waterfail life cycle. This has always been problematic for them because it always looks like it is the ISO that is throwing monkey wrenches at the last minute when the truth is that they weren’t invited at the beginning. In this paradigm they will be involved in Iteration 1 and they need to participate in each review period and they need to be active in getting their comments onto the change control log.
- Mission or business personnel will likely feel the most significant impact.
- Remember in waterfail they would invest some effort up front in requirements and high-level design and then the team would go away for a year or two and come back with a finished product. This process is different because they will need to be involved in a real and meaningful way in each iteration of the project. It was this experience that forced me to diverge from the book version of agile/scrum in which the team was making two-week sprints. The reason I had to change was because the government people couldn’t accommodate testing at that frequency. I found that we could get into a good rhythm by testing and prioritizing once per month, but not every two weeks.
- The other really important and big change for them is the fact that they are used to trying to get every single requirement into the next iteration. I found that starting out, they had a really hard time getting under the development level of effort ceiling. The reason for this is because they are coming from a waterfail perspective. When we initiated one of those waterfail projects we gathered the requirements and, by golly, your requirements better be in there because if they aren’t then you will likely have to wait for four or more years to get another chance. So I found that the mission people were working really hard to articulate future requirements that they might need to meet 2-3 years from now because there is legislation pending in Congress. And they are panicked that some of their requirements are deferred. Especially early on, these people cannot see those subsequent sprints and they don’t trust that they will get another bite at the apple in a month. After about three or four iterations they finally start to understand the process and work within it.
I think that the waterfail process is simply not sustainable. Too many of those project fail, and when they don’t fail from a technical delivery perspective, I strongly suspect that the estimates were padded, a lot. If you can subscribe to the principles of the agile manifesto and agree that what you are buying is a process that will lead to the application you need then you can transition to a better way. In order to make that leap you need to have an effective process for managing the requirements backlog, commoditize change and help people overcome the culture shock that will inevitably occur.
Baked In versus Bolted On Security
I already talked about how the security people are stakeholders to the project just like the business owners and the CIO. They need to be involved early in Iteration 1 so that their requirements are met early. But to fully appreciate this distinction, we need to dive in a little more.
Bolted On – In a typical waterfail project when do we inject security? Typically we initiate the security process all the way at the end, when there is something to test. This is the worst possible scenario. This forces security to only look like a bunch of A-holes. You went in and built an application and now you want to push it to the production environment and the security team is like, “Wait a minute; this has a bunch of vulnerabilities that you need to address.” As a result the project team goes to the sponsor and the business people and tells them that they are ready to deploy but these nervous Nillies (that is the actual term to be used) in security want us to make a whole bunch of changes.
Let’s think about this for about a millionth of a second. You want us to make changes to an application that works, that the customer already likes? Changes, especially changes that happen very late in the process, are very costly. What typically happens is that there is no money left to make any changes and we must either go begging for additional funds and time or we are forced to release an application that has unacceptable levels of risk. This happens because we are trying to bolt on the security capabilities after the application has been built. DUMB
Baked In – I’m sure you probably glazed over this clause in my work statement.
Hmmm, wtf does that mean? At my agency we had a policy that said that all development teams were required to use source code scanning software called “Ounce.” The name was really cute because, as Ben Franklin said, “An ounce of prevention is worth a pound of cure.” Well what this policy meant was that the development teams had to run their code through this software, Ounce, before it comes to security for testing. It also said that they aren’t allowed to submit any applications that contain any “Very High” or “High” vulnerabilities. But it didn’t say that you can only run the code through the scanner once or at the end. In fact, I told my dev teams to run their code through the tool daily.
This is really important. People develop bad habits not because they are trying to do dumb shit. They develop bad habits because they don’t know what good work looks like. So if your developers are writing code in which they don’t close out their variables or they are trying to pass variables through the browser, source code scanning software will help them to see these issues early in the process. The goal is for them to get into good habits in the beginning so that we don’t need to perform re-work.
When I wrote this little paragraph, I was building on the Section 508 notion that we don’t pay for capabilities that aren’t 508 compliant. Here I’m saying that we don’t pay for functionality that has high and very high vulnerabilities. Please notice that I didn’t try to describe the vulnerabilities. They evolve and change over time. But if you keep your Ounce software (now known as App Scan since IBM bought it) signature up to date, the software will change what is very high and high over time for you.
This doesn’t excuse the security team from getting their needs into the requirements backlog and from testing iterations. But this does address most of the things that are easily correctable. That is a benefit to the security team because they are spending their time and energy on more complex tasks.
In This Series:
1 “Waterfall model” by Peter Kemp / Paul Smith – Adapted from Paul Smith’s work at wikipedia. Licensed under CC BY 3.0 via Commons – https://commons.wikimedia.org/wiki/File:Waterfall_model.svg#/media/File:Waterfall_model.svg
2 http://agilemanifesto.org/
3 Rapid Development: Taming Wild Software Schedules. Redmond, Wa.: Microsoft Press, 1996. 660 pages. ISBN: 1-55615-900-5.
4 Cone of Uncertainty graphic from http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/
5 Ryan Nelson and Karen Jansen, MIS Quarterly Executive Vol. 8 No. 3 / Sep 2009, http://www2.commerce.virginia.edu/cmit/activities/MISQE%209-09.pdf
6 https://www.fbo.gov/index?s=opportunity&mode=form&id=5ec4b7885c32588bc858a47087bb08a3&tab=core&tabmode=list&=
7 Black Vault data – http://documents.theblackvault.com/documents/health/r_CombinedCGIDocs.pdf
8 http://oig.hhs.gov/oei/reports/oei-06-14-00350.pdf
