Agile Techniques, Agile Hype and the Essence of Agile [in IT and Business]

A discourse on what's agile and what's not and why we should care

Agile practices hatched in the IT world are also relevant to business and there is a pressing need to advance agile practices in both realms - “When the going gets tough, the tough get agile”. Fellow agile practitioner and CIO.com blogger Eugene Nizker and I have been conducting an ongoing discussion/debate about agility and its implications for the future of IT and for the future of business.

In Eugene’s words, “Agile is based on a simple philosophy of common sense. It puts forth a key axiom and a few related propositions and gives some very simple answers.” We’ve organized our thoughts by listing a key axiom of agility and then we present a short list of propositions that follow from that axiom. For the axiom itself and for each of the propositions, we respond with some observations on agile philosophy and techniques. Eugene’s responses concentrate on the impact of agile on IT, and I add my two cents on how agile relates to business operations.

Key Axiom: Uncertainty of Outcome is a Reality

EUGENE N: Do we (or our client) know what we need to get at the end?  Yes, but only in general terms. This sets a very different paradigm for the software development industry.

Indeed, the industry still works based on set of signed off requirements and uses approved set of “best practices”. It still uses this dated set of prescriptions that was not working even when it was just created. Expectation that following a set of instructions can produce desirable results is inherited by the software industry from manufacturing and construction industries. Although some of the principles that work well for those industries are applicable to software systems development, this applicability is rather limited. In today’s enterprise development the majority of software projects, related to business processes, have a completely different nature.

Indeed, in manufacturing or construction the vision of the project exists before the project is commenced. In software development a vague and incomplete vision exists at the beginning of the project. In manufacturing or construction the requirements are more or less stable (for example, we do not expect changing the number of stories in the building half way through the construction). But do we often (or ever) see stable software requirements?

Major (if not all) design decisions in manufacturing or construction are made before the commencement of the project – but every software developer makes design decisions every day. Testing in manufacturing or construction is usually partial and non-destructive, unlike in software development.

But more importantly, client’s expectations differ too. Clients are rarely surprised at the end of a construction project – and we know how often they are really surprised seeing a system for the first time that was developed for two years in an ivory tower by a group of techies.

This suggests that we are dealing with a very different matter indeed when developing a piece of software. Our world is not fully deterministic, but only partially deterministic. 

So, after we agree on the only partially deterministic nature of software development and business evolution (let’s call it the Great Axiom of Software and Business Indeterminacy - GrASBI), the rest is easy. In order to adhere to GrASBI, several traditional IT and business postulates of the past need to be modified.

MICHAEL H: About 80 years ago in the scientific world a scientist named Werner Heisenberg put forth a then radical idea that upended the traditional Newtonian belief which said if you took enough measurements you could confidently predict what would happen and when it would happen. Heisenberg said if you knew the position of an electron then you couldn’t say anything about its momentum and if you knew an electron’s momentum, you couldn't measure its position. This became known as the “Heisenberg Uncertainty Principle” and it is one of the cornerstones of the science of quantum mechanics. I would paraphrase this to create a business uncertainty principle that says, “A little analysis will tell you something about the near-term future, but lots of analysis won't tell you any more about the longer-term future.” So what's the use of doing lots of analysis?

1 2 3 4 5 6 7 Page
Join the discussion
Be the first to comment on this article. Our Commenting Policies