Experts.. I am inclined to believe that Agile in its pure form “as defined” by itself without modification cannot work in the Department of Defense as it is written today. I don’t think the DoD is prepared to implement agile in the way of policy, standards or effective and practical guidance. I don’t believe that agile project management as defined aligns with DoD IT acquisition. Tell me why I am wrong. Show me examples and show me where DoD enterprise policy, standards and guidance align outside of HR 2467 which to me doesn’t say much. I am asking because my research is telling me that agile is great for small teams and great for well controlled environments and great for developers but not great for the Department of Defense. I have a strong desire to learn where I am wrong here and if you can educate me on this I will republish and use this information for my projects and beyond.
Short history:
A few years back I was working on a project as the System Integrator for a fairly sizable enterprise wide SOA project. My career path was different from most in technology as I started by processing silicone wafers. I was a production operator for an IBM holding called MiCrus. After some time and interest in computers from years of playing with them as a hobby I started assembling them professionally. I worked as a technician for a small BBS and later internet provider and so began my career. I always worked alongside developers but I never became one. I actually had no interest in programming other than determining when code was a problem. As most technicians I played around with anything I needed to in order to resolve problems. Over the years I moved from technical support on a local level to helpdesk and technical support on the enterprise level. Not long after, I started to learn and become proficient in enterprise system deployment and project management. Over the years I continued to work with developers and engineers.
Fast forward a few years… I have now configured and deployed large systems pulling together all of the components and people required to meet and exceed organizational goals and objectives. I became involved with SOA concepts and enterprise services. Thomas Erl pulled together a group of experts and they started working on the SOA Manifesto. The SOA Manifesto was created in the same spirit and idea as the Agile Manifesto. I haven’t been formally trained in Agile methods and I am actually signed up to take a class in a few weeks but right now from my point of view Agile sucks relative to working in the Department of Defense.
I want agile experts (SCRUM Masters and practitioners) to explain why agile methods are good, where they are effective in the Department of Defense. On my DoD project we took an agile like approach but it wasn’t “AGILE” as defined. When I have spoken to experts they told me that I did it wrong. Recently I have become more involved in understanding agile in the formal sense and so far I don’t like what I am seeing. I have written about this in a few posts starting here and I have asked questions to folks that are either part of an agile team or are working in a related environment and I haven’t heard or seen one success story yet. It seems to me that agile may work well with small teams in a commercial environment but the shoe doesn’t seem to fit all feet. I recently heard of a project that has 8 Scrum masters. I have spoken to people in the Army, the Navy, Coast Guard, Department of Homeland Security, Joint Staff, and others. One seemingly success story may come from an old colleague at Booz Allen http://joelsef.blogspot.com/but I am not sure that Joel is working in the DoD now or not.
The Cohenization Project 
I think it can work in government in some projects but not all. In fact we’re doing it on a gov project right now.
We’re doing a SharePoint development and migration and Agile/Scrum is a decent fit for our needs. One key fact: the team (gov client, PMO, our consulting team, etc.) is all on board with the fact that we’re doing Agile. That is important. I can’t imagine it working otherwise.
There are challenges and I will cover the ups and downs in my blog series on the subject of Scrum for SharePoint projects. Though we’re doing SharePoint, the concepts may translate to other types of projects. Not all, but at least certain kinds.
LikeLike
You’re not wrong in this assessment of agile, but probably are pointing out clearly the fact that most program managers are the sad and unwitting victims of the dreaded and highly contagious condition known as REIFICATION–the mental state where one believes that something is real when it is only an idea. So we continually talk about about agile acquisition, “rapid” fielding, crowd sourcing, social networking…ad nauseum…as a means of making ourselves believe that these words are making something happen by our use of them, rather than doing what they would logically demand–using Scrum techniques and shortening delivery schedules, for example!
The biggest danger of this linguistic condition is that a chronic malaise sets in usually accomplanied by a fetid and seemingly endless discharge of…PowerPoint slides! The person so infected will exhibit an emotional and tersely worded unwillingness to entertain their worsening infection, citing such things as Forge.mil or Govloop as illustrations of how the Defense Department is already even now moving into this rapid fielding of agile acquisition capability. The fact that their projects do not use these methods, that no process exists for sharing specifications for web service development does not prove their disease, since such outcomes are “not in their swim lane” or that their program was not funded to “boil the ocean” or “solve world hunger” which such actions would certainly illustrate.
So….how do deal with the worsening condition of governmental IT professionals? I believe that what someone must do is to create a simple, safe and secure method of creating web services, just as has been done with the Ozone Widget Framework for visualization services. If a web services development toolkit (WSDK) could be found on Forge.mil as an “app” for regular warfighters to build a “data-as-a-service” container that could be used by anyone for a particular function, you would catastrophically transform the Defense Department’s web service development process. We would begin to see a rapid migration to agile development by end users who would be able to take their spreadsheets, their Access databases and store them as a service for others to consume as a reliable and accountable source of specific information about a particular function, location, mission or task. As “controlled unclassified information” (CUI) data services proliferated, leaders would then demand for similar web services on other classification levels. It would be success without fighting, a way of winning recommended by none other than the ever-quoted Chiense general Sun Tzu!. After all, producers have no incentive to do this since they are all too often trapped by the “cost, schedule, performance” tyranny of the old-school program manager. So they have to console themselves that someone will eventually give them a contract to do things this way. However, all too often the old-school program manager has a doppelganger at the contractor’s management who see no value in a course of action that would lower billable hours, shorten the billable schedule and “undoubtedly” destroy overall IT development performance! NOT!
If I were able to do it myself, I’d build such a toolkit out of Google Apps that connected to JackBe’s mashups, OWF widgets and SharePoint portlets. However, I’d like to recommend it to you as one that could be done by the wise and capable readership of this blog! This could become a shared “trailblzer” project worth doing in Forge and could be a shining example of how this collaborative environment was designed to work–safely, securely and sanely in a sweetly agile way! Let’s do this!
LikeLike