Agility +8XP

I remember as a kid, agility, was a super important attribute to claim while playing with my older brother and his friends, who of course had a fearsome ninja gang that rode rollerblades around the neighborhood in between slaming down streetwise games of POGS. Why did these kids respect agility so much? It’s because they were kind of nerdy and agility was a means for overcoming any lack of XP in strength, speed, or dextirity. With Agility, one could jump over & dance circles around enemies that focused on glamour traits. Agility in that right represented a kind of old-soul wisdom. It represented knowing that the ability to adapt to change will always be more valuable over time than any attribute gained in conformation to the more attractive, popular, and shiny traits a ninja may have. Agility is a timeless skillset.

Software Industry Experts Eventually Caught up to my Brother’s Gang

So at some point in the not so distant past (c. 2001) after noticing an overabundance of process inflation… by which I mean beaurocratic nonsense infecting the getting shtuff done factor of software teams, aka: rigamarole, a group of Software Ninjas, decided that the best thing they could do to manage this overgrowing hinderance, was to create a guiding ideal that established agility as the ultimate goal of software teams and their development efforts…

The Manifesto

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

Without having worked any substantial amount (cough imposter cough)on a professional software team, I still find truth in this manifesto. My favorite part, or at least the part I find most agreeable is the line, ‘Responding to change over following a plan…’ It makes me think back to the Marine Corps infantry where I saw incredibly descript plans fall apart in the field, and I witnessed leaders, myself included, rise and degrade in the face of such change. As a matter of fact, in every line of the Agile manifesto, even the first* requires a stretch of the imagination, I can find a related ideal I gathered from my time on rifleteams in the Marine Corps.

* Individuals and interactions over processes and tools

BAMCIS!

The idea of responding to change though, is one that peaks my curiousity most. In the USMC before any mission, a ginormous protocol called, a 5-paragraph order was drawn up. Despite the name, they were never 5 paragraphs. This process at first glance is not unlike the Waterfall process most software teams followed before Agile practices were established. I think similarly to waterfall methodologies, boots on the ground ( …or in the case of a software team, the junior developers), were not expected to be involved in the team mission/objective process at a high-level.

The difference is that in my experience, their was a great deal of flexibility and team culture that was decided by the individual members of small 3-4 Marine teams. Junior enlisted were lead at the lowest level, where small-unit leaders can make adjustments without creating a conflict with or distracting from a rifle-team member’s individual & immediate actions ( …passing test by writing code that solves specific problems they encounter along the way of completing a story). It goes without saying, that not all small-unit leaders did this effectively, but I think mine did a decent job of creating a highly effective team for a couple of teenagers in charge of teenagers at war. Software projects are an awful lot like [conducting patrols] (http://www.trngcmd.marines.mil/Portals/207/Docs/TBS/B2H3317%20Patrolling%20Operations.pdf?ver=2015-03-26-101420-157), beside the ACTUAL fear of death for you and your teammates, when done right, there should be a similar safety and shared responsibility for making the hardest and most uncertain of tasks, the most enjoyable to complete. This is what I imagine, makes teams with high agility.

All of this revoles around accomplishing a mission. Which in my mind is the goal of incorporating agile practices.

I’ll end with 2 Agile principles that drew my focus in PPP’s Agile Practices chapter and which I think I need to catalyze:

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

_{paraphrased for simplicitiy}

Priority - ...satisfy... ...through... ...continuous delivery of valu—...