The Unbearable Weight of Incompleteness

People don't like ambiguity. There is a natural inclination toward finding completeness, closure, balanced books. In the software world, this can feed into the stress of writing code. It's difficult to show progress like one can with building a chair or a house. Common questions from management-types intent on holding to a budget and timeline: "When will it be done?" "Is it done yet?" Before Agile was a defined thing, answers to these questions were never satisfactory. From this emerged a culture of distrust between a management class used to direct and immediate observation of progress from line workers and software developers creating unseeable things with unreadable languages.

In the late 90's, I was contracted to build an application in Microsoft Access that would track required OSHA training for a furniture manufacturer. Agile hadn't been formalized, but I was armed with the principles of rapid application development.¹ The value of prototyping a solution with the client's help as a way to shake out what they actually wanted was a new idea at the time. Those early years were spent learning hard lessons about the gap between our relative understanding of how technology works, particularly if the prototype had any UI/UX elements. Naively, my initial efforts would focus on pretty user screens with zero functionality so the client would be pleased with the illusion of progress. What they invariable - and I do mean invariably - concluded was that work was nearly complete and the solution could be used in production the next day. This also caused them to question my fee.

Disappointing clients, it turns out, isn't the best way to get repeat business.

I modified my strategy to only show screen captures that were gray scale, had the word "PROTOTYPE" emblazoned in bold, red letters at the top of every screen and a variety of other tricks in an effort to convey the message to the client that they were not looking at working software. This helped, but only marginally. I haven't been a contract coder for decades, but before shifting my career direction I had resorted to showing pictures of hand-drawn whiteboard sketches, selectively cropped screen captures, and, occasionally, actual code. That last trick was a bit like a car mechanic popping the hood of a customer's car to show them where the problem is. Unless the customer is a mechanic, they're going to get that fixing the car is way outside their skill set. And if they are a mechanic, they're going to understand the effort involved with fixing it.

The advent of SaaS applications has, by and large, eliminated this issue. Iterative development, rapid release schedules, feature switches, and A/B testing are beautiful things. Yeah, for software development! The old cognitive patterns, however, are still in place and represent an unslayable dragon when it comes to implementing Agile principles and practices. The assumption - by those not doing the work - that tossing employees into an Agile training hopper is all that's necessary and sufficient to successfully implement an Agile methodology is alive and well. Alas, if we could place bright red temporary tattoos that persist for 4-6 months and display "PROTOTYPE AGILIST" on the foreheads of newly minted Agilists, that might help.

The notion of "minimum viable/valuable product" doesn't seem to translate well from software to the wetware running inside the people tasked with implementing Agile within an organization. Debugging this process, however, is what I find fun and challenging. Yes, when it works the people using the new process are more productive and products of higher quality are delivered in less time. More importantly, the people actually doing the work are happier. They grow as people. Some more than others and at different speeds. The analogy of a garden isn't as far fetched as it might seem. Every plant has its place and its purpose. And those that don't, the bindweed in the garden, usually don't last long before they self-select to leave the thriving culture.

It takes a lot of hard work to shift an organization's mindset and culture in a way that supports the experts in doing what they were hired to do. Assuming an organization gets there, the work isn't done. Wealth managers say becoming wealthy is easy. Staying wealthy is harder. The same is true for establishing an Agile organization. Once in place, watching for signs of danger on the periphery that could disrupt the environment and damage the balance of the ecosystem becomes a central task to the on-going maintenance.

---

Photo by Birmingham Museums Trust on Unsplash

1. McConnell, S. (1996). Rapid Development: Taming wild software schedules. Microsoft Press.