I changed the title because the requirements changed…. Really.

I woke up this morning and grabbed that first cup of java, it was really good as usual.   My wife makes great coffee, she does it every day without fail.   We don’t even need to meet about it.   On that note, I grabbed the paper and read and article tied to meetings adversely impacting IQ( http://news.menshealth.com/how-meetings-make-you-stupid/2012/02/13/ ).

Still reading? Good because I will get to my point.   Agile is good BUT agile is good if there is balance as with everything else.  Let’s take apart the next piece of the Agile Principles.  Remember that my focus and context is related to the DoD.  Where you may have the ability to execute YOUR way 100% my opinions may not apply.

Principles behind the Agile Manifesto

We follow these principles:Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Number 1 priority is customer satisfaction.  GREAT! Early delivery of software does not compute.  How about “on time” software delivery?  How about “highest quality” software delivery?  In the DoD, they don’t need early and often.  They need on time and stable.   Think not?  Continuous delivery of software means continuous software updates.   See http://diacap.org/ if you are interested in the implementation process for DoD Information Systems for certification and accreditation (C&A).   The most common answer I get from people who practice agile is… “oh that.. that has to change”  

Welcome changing requirements, even late in development.

Agile processes harness change for

the customer’s competitive advantage.

Competitive advantage has to do with beating someone in a commercial market position.   War is long, war is cold and war for the DoD is not a business.  I didn’t say war is not a business, I said for the DoD it isn’t a business.  Not in the same sense that you would talk about Apple or Microsoft, Google or Facebook.   Sure, there are places in the DoD that need this kind of aggressive process where you can change late in the game (dynamically) but for the most part, building software and systems in and for the DoD is a long process with reason.   When I was on board the USS Mount Whitney, they would push back ships movement for electronic updates and changes.   The reason is that software right out of the gate hardly ever does what it needs to do, it takes time and planning.  Even then there are great challenges, the problem here is that we need to be an agile defense force and that means we shouldn’t be held back because some developer forgot a line of code and needs to just do a quick update.   Remember early and often in the DoD results in confusion and delay.   Imagine for a minute that you plan a trip and that you are going to fly to your destination.  While aboard the plane the pilot informs you that you will be arriving early due to some great tail winds.    Even without any other changes, how many passengers were just adversely impacted?  Getting somewhere early isn’t always the right answer.   Changing up software or altering requirements late in the game need significant considerations when dealing with defense systems. 

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

I addressed this earlier with the DIACAP but what I can say is that this process can be made to work if we aren’t delivering software on that same schedule.  In other words, if the developers are way ahead in a development cycle, this can provide testers an opportunity to really put the software through very comprehensive and stringent testing.   That would work, as long as the production cycle was consistent. 

Business people and developers must work
together daily throughout the project.

Yes and no, see my earlier comment on meetings.  I have been involved with agile project management in the DoD one way or another for a few years now, I haven’t seen a 10-15 minute meeting situation that is consistent.   Anyone that tells you otherwise, get me his or her number, we need to learn from them.  Also, who are business people?  Are developers just a bunch of hipsters hanging out smoking doobs and drinking energy drinks?  Are they spending 20 minutes coding and then heading to the gym for hours?  Developers ( a lot of them) are business people.    I think it is fair to say that   agile can learn a little from SOA concepts where they are more specific about who is working together on what and for what purpose. 

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

I LOVE this principle and it should be number 1!  TRUST is key.  

Trust is the foundation of every aspect of business any business end to end.  There is no other single more important factor.   Of course there are other things that are needed but without trust work cannot and will not succeed.   

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

That is so 2001.  Quote me. 

The most efficient and effective method of conveying information to and within a development team is to develop, facilitate, nurture, maintain trusted relationships.  Provide the methods and tools required to access your trusted agents, and have faith in them.  Be available to them and provide them with clear “COMMANDERS INTENT”!

The paradox of war in the Information Age is one of managing massive amounts of information and resisting the temptation to overcontrol it. The competitive advantage is nullified when you try to run decisions up and down the chain of command. All platoons and tank crews have real-time information on what is going on around them, the location of the enemy, and the nature and targeting of the enemy’s weapons system. Once the commander’s intent is understood, decisions must be devolved to the lowest possible level to allow these front line soldiers to exploit the opportunities that develop. —General Gordon Sullivan, quoted in ‘Delivering Results’ by David Ulrich

You might say ….. WAIT A SECOND HOWIE!!!! What are you saying?  First you talk about all this DoD requirement mumbo jumbo then you say “Commanders Intent”!!!  Isn’t that an oxymoron?

Nope.  Commanders intent gives us the overall mission, vision, scope, objective and timelines.   It gives product owners, developers, management, leaders the ability to execute at their level.   Commanders intent isn’t a free for all but what it does is provide enough information to give groups leeway to make decisions as they need to in order to accomplish the greater goal with less frequent communication.  I can provide examples if needed but just off the hip look at Boeing manufacturing the 787.

Working software is the primary measure of progress.

Successful implementation and usage is the primary measure of progress. 

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

While running a marathon or any other race for that matter is it usual that some fall back and cluster in groups and some pull ahead.   The thought process that everyone can keep up with everyone is mind-boggling.   I can barely keep up with my children! 

Continuous attention to technical excellence
and good design enhances agility.

Love it.. 

Simplicity–the art of maximizing the amount
of work not done–is essential.

Yeah I like maximizing stuff I haven’t done.  Called the “honey do list”  for some reason it continues to grow no matter what I do to attack it.  Wonder why? 

The best architectures, requirements, and designs
emerge from self-organizing teams.

What happens when the team is forced to do something because a dumb ass is working in it?  Everyone works around Billy dee dumb ass? Not realistic.   The best architectures, requirements and designs emerge from good leadership, good listening, clear direction, good followership  and people working together to fight “the dumb”! 

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

At the beach! So.. I meet on Monday-Friday with you and both of us haven’t changed our behavior through any of those meetings but on some other regular interval we are going to come together and adjust?  How about constant feedback?  How about open honest dialogue?  How about trust?  

I am arguing that agile must be tempered by context.   I am arguing that it isn’t a panacea but a practice.  You know your doctor “practices medicine” and we still have the common cold.  

Software development and systems engineering include systems integration and goal oriented objectives.   Oh yeah, it is about PEOPLE !

Be agile and be realistic.