Are there Preconditions to the Agile Manifesto?

NOTE: This is a re-post of an article I wrote in late 2015. While many of my views have evolved in nuanced ways and a few of the specific points I would alter if written today, the general point – and questions – I believe to remain solid.

First, let me start by saying that I am an Agile junky. I have at least three different sets of initials to describe my Scrum Master certification status’ and more for Product Owner, Trainer and Agile Coach. I love Agile – especially Scrum. I believe it is the absolute best, most effective and predictable way to develop a quality software product. I have long considered Agile an evolution from the good old waterfall days. I have also long considered Agile development to require far more discipline than other “comprehensive plan” process models. With that said, allow me to take what may seem like a contrarian view on the Agile Manifesto – though I would like to think of it more as a “chicken or egg” perspective.

The Agile Manifesto basically says:

At first blush this seems like a small reconciliation to the items on the right, but from some recent experiences with some specific teams, I have formed a “precondition postulation”. It is as follows:

Postulation: If a team, as a whole, does not possess the knowledge, skills or discipline to execute the items on the right, it is at least difficult, if not impossible, to consistently and appropriate deliver on those to the left.

Now, hold on, before you call me a process Nazi, or accuse me of trying to take away individual developer freedom or creativity – hear me out. I do wholly and fully believe in the Agile Manifesto, each and every one of the items to the left is more valuable than those on the right … so long as the team as a whole is capable of performing those items on the right. That of course does not free us, as leaders, from showing them how to deliver on the left-side items, but simply says that we must start (or at least close the circle), with those items on the right. Below are the point-by-point details of this postulation. I’d love to hear what you all have to think about it.

Individuals and Interactions over processes and tools

This is where true team member freedom and creative expression comes to bear. Individuals working autonomously and asynchronously, while interacting with one another are the ultimate in creativity and – from a manager’s perspective – total system throughput. However, what if those individuals are acting inappropriately, or interacting inappropriately? I think we can all agree, that if more than some critical mass of the team members are acting inappropriately, the creativity will not show, the efficiency will not happen, and ultimately the product will not deliver as desired.

However, the question is how do we know what is “appropriate” and what is “inappropriate”? What guides this determination? Clearly there will be slightly different definitions of appropriate and inappropriate based upon experience, personality, and a host of other factors. I propose one of the foundational pieces of each of our individual definitions of appropriate and inappropriate comes from our knowledge of processes, or “best Practices” if you will. Moreover, that the tools we use (have used) within and around that process, and perhaps more importantly how we have used (or misused) them.

Working Software over comprehensive documentation

This is almost certainly the most misunderstood of the Agile Value – specifically the meaning of “comprehensive documentation”. Many people think that this includes, or even means the user documentation, API documentation, etc. Even when you consider the lofty goal of making ones’ software so simple and intuitive to use that the user documentation consists of telling the user how to launch the application, it just isn’t true that that is what ‘comprehensive documentation’ means.

To understand the Agile Manifesto – like any other document that stands the test of time – one must take it within context. As it turns out, 2001 – the year the Agile Manifesto was first penned – signaled the beginning of the end of the heavy-weight process domination in the software industry. In those heavy-weight, waterfall processes comprehensive documentation means the detailed, front-to-back user requirements, technical, graphical design, and procedural specifications, including the entire series of revisions, reviews, approvals and signatures required by the heavy-weight process. This is what is meant by “comprehensive documentation”.

I say that that understanding alone is a prerequisite.

Customer Collaboration over contract negotiation

Ok, I’ll admit that this one is probably the weakest link in my proposition. Customer Collaboration is one of the true hallmarks of Agile – after all, the first four Agile Principles are about exactly that. This is often spearheaded by the Product Owner more so than the other team members. Can a product owner or team member really appreciate the value of customer collaboration, or understand or predict the pitfalls without having sat through a contract negotiation? Or at least had to plan or develop to a negotiated contract? Particularly a contract that did not reflect what the customer really wanted. I don’t know, and like I said – probably the weakest point to my argument here, but consider: When was the last time that you truly appreciated that stick of butter sitting on the table, or in the ‘fridge? – Unless you happen to have had to churn your own butter at some point. All I am saying is that it is probably very easy to take that stick of butter for granted unless you know from where it came.

Responding to Change over following a plan

Anyone who has been around software development for even a short period of time knows that things seldom go as planned. Therefore, the ability to respond to change is invaluable as a team and for all team members. Agile does not mean no planning, in fact planning is at the heart of everything we do. It is important to remember that ‘following a plan” refers to that same totality of a plan that is comprehensively documented.

A recent experience with a team of developers that have all grown up as a “team” that had no process – (yes I do mean no process) – has convinced me that being able to respond appropriately to change requires the ability to know and follow a plan to some degree. This particular team had spent so long “responding to change”, (reacting really), that it was completely driven into their demeanor that nothing ever was complete. EVER. Sure, they would produce something, and maybe sometime an individual “hero” effort would even come really close, but never actually done – as in the Agile definition of DONE. This team was constantly in a reactionary state. Reactionary-ism was so much a part of their expectations and culture that they would proactively react. – Yes, I know that sounds crazy, but they would change plans if they even thought there might possibly be an issue, ever … at all. This team psyche speaks to the maturity level, leadership and many, many other facets in the long history of that team’s culture. But, would that culture have grown differently if there was SOME sort of plan in place? To me, it seems it would require much more thought to change a plan rather than to simply react because there was no plan at all.

Conclusion

So, my question is; Do those of us that have had the (mis)fortune to operate under some of the older software development paradigms have some sort of an advantage over those that have come into the industry more recently – straight into a creatively free Agile environment? Does the discipline we gained from these gut-wrenching exercises actually have a long-lasting dividend? If so, what does that imply about our jobs as leaders and mentors of young, new developers? If not, and these items on the left can indeed be internalized without those on the right, what is the relative cost of doing so? Across a project? Across a career?