A few posting back I challenged the Agile community to bring to light their process and methods. My blog is posted on Twitter, LinkedIn and a few other places, at the very least a few thousand people get notified of an update. A few folks in the community responded but I would like to repost Dave Lamp’s comments here because he has a deep understanding of people, process, methods and use of tools from a military leadership perspective, a government contractor perspective, and a government civilian perspective. Change has to come from a cultural normalization with practice. A faster more effective and efficient approach to development requires TRUST. If we were to analyse my blog, the word that would be used most across every post would be TRUST. It is central to all that we do and it is critical that we work to gain and manage our trust relationships carefully. Here is Dave’s comment :
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 “trailblazer” 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!