Shadow Agile

A cave wall dances with shadows. Product, Delivery & Engineering Managers are transfixed by the pale shapes of their reality. From outside of the cave sounds can be heard “Daily Standup”, one says before it fades, “Product Refinement” says another before vanishing, “The Backlooog~”

The managers, however, refuse to look outside the cave, to the true source, they stay held captive by the shadows and the choice to dismiss what depth could exist. It’s enough to understand these fuzzy one-dimensional outlines. The value is seen in the words echoed through the cave, words with no soul. Until those within start to repeat the words, filling the cave with echoes.

Thus, Shadow Agile is passed from one person to another in the cave. The words become the proof that they are in the cave, and being inside becomes the goal. The complexity of real software delivery cannot be understood via education or disciplined practices. Only seeing these shadows is proof of practice and proof of their mastery of Agile.

Those who learn about the depths of Agile become the heretical few unwilling to go back and unwelcome all the same; shunned for not embracing the flat, shadows cast on the wall.

For me, after nearly a decade of software engineering, I have seen many sides of Shadow Agile and I’m sharing my name for it in the hope of reducing its power to confuse, and clearly denoting this avoidant behaviour of ideas as the hindrance it is to building software.

I don’t have an answer on how those who are stretched or uninterested in education can be convinced by the simple truths of Agile development. Agile came about in a world where Agile didn’t exist, but disrespect of engineering, and a lack of trust in people was proven to make worse products and cost businesses money.

We now live in a world where the answers exist, when disrespect and a lack of trust in engineering is reinforced by Shadow Agile. I know this is sometimes earned, trust is eroded by promises to keep stakeholders happy, and respect degrades when people hide behind Shadow Agile to mask their insecurities.

People aren’t perfect, however, true Agile frameworks create ways for the business to get closer to engineering, creates transparency and builds trust between everyone involved. People are messy, but Agile frameworks help businesses nip issues in the bud; albeit, it does require that management does the management bit of the job.

My call to action is to not let this Punch and Judy puppetry of ideas be allowed to get away with pretending its a carefully choreographed theatre. Call these flat, ignorance filled practices Shadow Agile. If you think what you know as Agile is Shadow Agile, make efforts to learn and understand why so many experienced and successful engineers still choose to push Agile values. Resources exist, even if you aren’t lucky enough to learn from senior engineers who understand Agile.

Remember, ignorance comes from inaction, and inaction is a choice that is being actively made by many in our industry. Don’t get stuck in that cave, either by becoming transfixed by the false shadows, or by throwing out the whole idea of Agile as a waste of time.

Know now that Shadow Agile is just a pale reflection of Agile, and to say you understand anything from only seeing its shadow is to throw away growth and learning.