Editor’s Note: The following story is taken from a book-length work authored by a senior Federal IT official currently working in government. This is one part of an extensive, firsthand account of how IT decisions are made, the obstacles standing in the way of real change in government technology management, and what one career Federal IT employee really thinks about the way government does IT.
Because the author is a current government employee and is concerned about the impact this may have on their career, we’ve agreed to publish this series of weekly excerpts under the author’s chosen pseudonym—Demosthenes.
MeriTalk has agreed not to make substantive changes to any of the chapters.
— Dan Verton, Executive Editor
The discussion from the previous chapter about platforms is critically important for developing an agile practice. In fact, I would go so far to say that it is a prerequisite. I’m not going to go into all the theoretical details of agile development. In fact, I probably won’t be talking about a methodology for agile development that meshes with any of the million or so books on agile development. The process for agile delivery that I will describe is, like everything else in this book, based on my own experience of what works and what doesn’t. So, get your salt shakers out, what works for me may not work for you. My goal is to share my experiences and give you ideas to think about for implementing in your own agency.
Here’s the scenario, you have a new requirement to do something. It could be a new law, a replacement of the current capabilities, whatever. The point is that you are going to be developing something new. In an agile development paradigm, you are supposed to be testing something new every two weeks. If we give a grace period for sprint zero for two weeks, that still means that you should be testing something within a month. Is it possible to order a rack of servers, get it delivered, get it installed and configured and build a capability that can be tested within a month?
The answer is “no.” There is no agency that can go and get new hardware and get it set up so quickly that developers can build a “hello world” screen in it within a month. Thus, a platform is a prerequisite for an agile development paradigm. I have worked at two organizations that have achieved, at least partially, a platform that encourages rapid development.
My first experience that I will reference was at AN AGENCY. It was a great place to work because the mission people running the programs are so knowledgeable about their programs and they care about getting them implemented. Whether it was a whole bunch of bleeding heart stuff, people at this agency care. The problem has always been in effectively funding the machinery to support the programs. Since the people who run the programs care so much, they want every dollar to go into the program. That means that their nature is to push the least amount of money into IT and other administrative expenses. Also, Congress has not been kind to the agency in approving their budget. These two issues forced the department to be as lean as possible and sometimes that drive to efficiency was manifest in innovative ways for doing things.
This was the case when the agency awarded a big managed services contract. Company A got a portion and Company B got a portion of the work. Company B got the part dealing with systems and applications and worked hard to implement a strict Technical Reference Model (TRM). Their thinking, and I still believe in this idea today, was that if we can get the entire agency onto homogeneous development, test and production environments, we can do it cheaply, or at least cheaper than it would be to maintain a variety of different platforms. As such, the department adopted a J2EE/Solaris/Oracle development platform. Every single system and application was required to move to this platform within two years.
Regardless of how you feel about J2EE/Solaris/Oracle today, this policy was one of the smartest things the agency, or any agency, has ever done. The department started buying hardware and software to support it in an industrial manner. It also allowed the department to grow specialized resources that could go deep into these areas. They created a team called the Systems Engineering Support Group (SESG) that would dispense advice and arbitrate any of the nuances in interpretation among competing teams. From my vantage point as a project manager in one of the offices, I didn’t have to waste time trying to figure out which database, which application server or which programming languages we should use for my projects. They took care of the operating system and below, and that freed me up to focus on the application layer and up. When it came time to compete for contracts, the vendor community was precluded from proposing tools outside of the tool set and that allowed me to better compare their prices.
In all honesty, the way this part was managed was perfect. People may complain that it was too rigid, too iron fist, too much like Jeff Bezos. Waa waa
go in the corner and cry about it. There was too much good that came from doing it this way and getting serious about standardizing. I’ll talk a lot more about managed services contracts like this one in Chapter 5, and overall, I think they are a terrible idea. But for this one part, it really worked well, and would still be working today. The value of being able to go out to industry and say, this is my environment, J2EE/Solaris/Oracle, cannot be understated. If you want to propose something that isn’t J2EE/Solaris/Oracle, don’t bother. For you companies who are good at developing in a J2EE/Solaris/Oracle environment, keep and retain your good people because you will be able to leverage them across all of the contracts you have with the department. But alas, someone got in there and screwed it all up. Today the agency has just about every technology under the sun and there is no unifying development platform.
