Programmer at War (in Iraq)

Most of those who read my blog are probably unaware that I am in Iraq. Normally, I am a Software Engineer/Chief Systems Architect for an Oklahoma based company. One weekend a month I am an Officer in the U.S. Army Reserves. Last summer I was deployed to Iraq.

I am a Platoon Leader in a Medium Truck Company. It's quite interesting how different my civilian and Army jobs are. In my civilian job we are always going forward with new developments. In my Army job, each mission tends to be organized similarly and entail doing the same task over and over again. Although, sometimes, the enemy has a say in that.

In some ways though, my jobs are very similar. There is a great deal to be learned from my experience in the Army. Being an "agilisto", I really value communication and people. In the Army, the most successful leaders learn to communicate very well and place the needs of their soldiers before all else.

On an agile project we plan and deliver value incrementally. This allows teams to embrace change. In the Army, it is understood that your enemy, the weather and the terain have the final say-so in all plans. Unfortunately, just as in the software engineering world, not everyone understands this concept and are unable to embrace change.

I dealt with this recently. We were planning for a mission. Our higher echelon wanted us to push out on a certain day. I felt we could do it. The Platoon Sergeants had a "feeling" that we could not push out until 2 days later. Usually , in the agile world, the nod would go to the Platoon Sergeants (the team).

99% of the time I would agree. Although, sometimes, we are presented with time sensitive requirements. I attended a workshop several years ago at AgileXP, that talked about Advanced Estimation. They suggested that, in some cases, you have to push the envelope to get requirements met on time. I felt this was a time to push the envelope.

Well, since I am the acting XO, I argued my point. Eventually, I was able to convince the Platoon Sergeants that we could "try" to meet the requested date. I suggested, we would keep our higher echelon (the customer) informed by passing up incremental updates and letting them know the risks upfront. As the date approaches, and things aren't looking good, we give them the option of changing the operational scope. If the scope is what they value most then we suggest they push the date to the right.

Ideally, we want to stay pragmatic and plan our time accordingly, but in a few cases we have no choice but to work out some solution. A common argument from the Platoon Sergeants was that our higher echelon would consider this a solid commitment and our hands would be tied if something went wrong. Surprisingly (not really) our higher echelon was very understanding and, like everyone in Army, was prepared for a contingency in which we were unable to meet the mission.