A Requiem for Agile?
OK, so the Agile Software Development Methodology (SDM) is dead — at least according to several posts (see sources here) published by some of its founding fathers and others over the past 3 years. (Apparently it takes a long time for an SDM to die, but that is not the issue here.) The question from our perspective is, “What does the ‘death of Agile’ mean to the one wearing the Business Analysis hat?”
To answer that, let us first clarify our position.
Is Agile Really Dead?
For starters, if Agile were human, it would presumably paraphrase Mark Twain’s response upon reading his obituary, “The reports of my demise are vastly exaggerated”. In our experience, it is also a fallacy to claim that Waterfall (or Spiral or even Ad Hoc – aka “Chaotic”) SDMs are dead. All of these SDMs are actively in use within our customer base with varying degrees of rigor and success.
We certainly acknowledge that none of these SDMs (including, emphatically “Agile”) are implemented in their purest form in every organization. Trade-offs are necessary to implement any concept in the real world and SDMs are no exception.
Furthermore, we recognize that Agile can be improved — as can every past, present, and future SDM. But should we allow them to be executed for their minor offenses? If we did that, we would eliminate every SDM the IT world has developed to facilitate the process of delivering working software to the end users of the world.
But, again, what does this mean to the one wearing the BA hat?
Is Business Analysis Dependent upon the Software Development Methodology?
As a practicing business analyst with too many years of experience, I maintain that each SDM represents a legitimate and preferred approach to developing software — assuming that it is a good fit for the project, the people, and the organization involved.
Selecting which SDM is best suited for a given undertaking is a decision in which the one wearing the BA hat should be involved. Ideally, it is a decision that should be made based on the results of strategic business analysis efforts preceding the initiation of any project.
What Did Agile Do for Business Analysis?
From its inception, Agile really did not have a significant impact on the one wearing the BA hat. Depending on its implementation, Agile often changed who was wearing the BA hat and when in the development process “real” business analysis work was done (see The Agile BA – Myths and Misconceptions and Where Do Business Analysts Play on an Enterprise Agile Field?). It did not affect the skills and techniques needed by that individual to get the job done well. As a result, we really do not see a significant impact on anyone tasked with defining what the delivered software should do and how it should be used by the business community.
Agile, Agility, or Continuous Delivery?
Several new names/tweaks/expansions/replacements for Agile are being proposed on the WWW, but again, none of these will ever replace the crucial activity of thinking — the primary contribution of business analysis. The critical success factor on any IT project is not just delivering working software, but delivering business solutions that the business community needs — which may or may not include working software — and that is where the one wearing the BA hat plays a major role regardless of what the SDM is called or which SDM is best suited to the project, the people, and the organization.
For a more in-depth explanation of how SDMs affect the one wearing the BA hat, we recommend our free KnowledgeKnugget™ Business Analysis and System Development Methodologies (SDM).
