Through our combined forty years of experience consulting and running IT organizations in Fortune 1000 companies, we outline in this white paper what we have learned are the most effective and readily adoptable agile processes, as well as a few techniques to integrate hybrid waterfall approaches.
Companies adopt an agile software development framework to become more effective and more efficient, not to become a model of purist agile utopia—which, if attempted, ironically can be immensely costly and detrimental to progress, if not disastrous. A purist agile approach is not realistic for highly complicated Fortune 1000 companies that inherit unideal agile conditions. Teams with technical specialization, complicated reporting structures and governance committees, long-term roadmap planning and budgeting, conglomerate and subsidiaries in geographically dispersed locations, multiple shared product owners, mature legacy third-party installed applications, inherited roles absent in purist agile teams, a variety of IT vendors and partners with near-shore and off-shore blended workforces, and entrenched waterfall frameworks throughout hundreds of integrated applications are just a few Fortune 1000 company conditions that make it difficult to adopt agile.
As an example, one of our clients attempted to reconcile the Fortune 1000 conditions mentioned above with a full-on purist agile approach. This resulted in a fifty-six-page slide deck of prescribed instructions on implementing agile in their inherited Fortune 1000 environment that would also pass muster with all other stakeholders and their ancillary Fortune 1000 processes. It was complete with eight process flows, half-a-dozen swim lanes, and dozens of decision trees. They created this agile document after a year-and-a-half was spent gathering requirements in a waterfall-based approach. Their management, frustrated with the lack of progress, wanted to adopt what they heard was a new framework to push work forward more rapidly. However, the team ended up spending even more unproductive time creating the agile slide deck through countless discussions and approval rounds. And this was all before iteration 0 had even started.
In the end, they abandoned the fifty-six-page agile implementation slide deck, disbanded their attempts to socialize it, and instead called on us. In twelve weeks we not only implemented our simplified framework version of agile—what we are calling the “least common denominators” of agile—but we also developed the foundational components of their next-generation operational software.
As you can infer, there are aspects of agile principles that are more easily implemented in large, complex IT organizations that generate almost immediate benefits with very little relative disruption. These “least common denominators” of agile offer the biggest bang for the buck while being unintrusive enough to phase in at Fortune 1000 corporations. There are also hybrid waterfall and agile techniques that can be combined in order to gain the benefits of agile while both maintaining the benefits of the waterfall approach, which has been entrenched in the majority of Fortune 1000 companies, and enabling the framework to be more readily adoptable within these highly complex IT organizations.
Least Common Denominators of Agile
Agile is meant to be simple, but like all processes that start simply, it can quickly spiral out of control as layers are added and canonized in an attempt to standardize behavior. As a result, there have been tens of thousands of pages written about agile. But in this article, we are going to try to do the exact opposite and distill agile to its least common denominators. Agile can be broken down into three main process themes: artifacts, ceremonies, and engineering techniques.
The three key artifacts of agile are the product backlog, the iteration backlog, and the burn-down chart. Any individual team within a complex Fortune 1000 IT organization can adopt these artifacts by simply making a list of software requirements and to-dos (product backlog), breaking them into logical groups of work with estimates and assignments (iteration backlog), and tracking the work remaining (burn-down chart).