Succeeding with Agile.

Abstract

Agile has been all the rage for a decade.  Some organizations have been more successful than others in adopting agile methods.  Agile has been marketed very heavily both by software developers and by the members of the agile alliance; therefore, it is important  to separate the wheat from the chaff. To be certain, agile is not a silver bullet.  Merely, adopting agile ceremonies will not ensure that an organization will reap benefits from adoption of agile practices  Simply stated: an organization cannot expect a stellar transformation in software engineering outcomes by proclaiming "We are an agile shop."  Nor will the goal be achieved by overlaying scrum ceremony on top of a broken software engineering approach.

To place agile in the proper context, we raise four germane questions:

1)Why should an organization adopt agile?
2) How can agile benefit an organization?
3) What decisions can aid in successful agile adoption and ensure that an organization reaps the  intended benefits of agile?
4) What software products are good candidates for agile?


Why Agile? How can Agile benefit an organization?

These are the two most important questions when contemplating agile, and they are clearly reciprocal to one another.  An organization should adopt agile if it is very firmly committed and resolved to long-term improvement in software engineering cost controls and overall improvement of software quality  This is precisely how agile can benefit an organization; however, Agile does not come with this guarantee.  Agile must be adopted with pragmatic expectations and a willingness not only to disrupt traditional conventions and practices, but to embrace the foundational changes that are necessary for a successful agile practice.

What decisions can aid in successful agile adoption and ensure that an organization reaps the  intended benefits of agile?

There are many changes that are necessary and proscribed for any organization adopting agile.  There are no shortcuts here, all of the proscribed tooling and practices are essential to getting agile right. All of these proscribed elements are necessary and, in fact, crucial to employing agile successfully, and thereby achieving the outcomes that underpins the question "Why Agile?"  These prerequisites for agile success are as follows:

1. An organization must possess the willingness to part with brittle or failed software architectures that do not adapt well to Agile practice.  In short Agile will not work with any old software and there is no way to evolve a brittle or unwieldy architecture through iterative development to arrive at a viable agile architecture.  Consider the following realities:
• One of the most fundamental paradigm shifts that is vital for Agile software development is test-ability and test-driven development.  Software that is not designed for test-ability is not well-suited for agile teams. 
• Experience shows us that organizations who try to superimpose agile on software that is not designed to be testable are prone to fail at agile adoption.  
• Similarly, certain software architectures fundamentally lend themselves to agile development where as others do not.  
• An organization must be pragmatic about whether it's underlying software architecture is sufficiently agile and understand that an unwieldy architecture will invariably lead to a failure to succeed with agile.  A governing maxim: software that is failing without agile practices will almost certainly yield the same results in an agile regime.
• Agile doesn't just happen because it's proclaimed.  It takes a great amount of discipline at all levels within an organization to successfully employ agile practices.  Furthermore, there are fixed costs for successfully managing agile development which cannot be overlooked.  The organization needs to have a reliable and efficient platform and tooling to manage it's agile deliverables.  This goes far beyond SCM. products such as JIRA,HP ALM and similar ticket management technologies are prerequisites for a successful agile implementation, simply because there must be transparency and line-of-site visibility of every in-progress activity solution at any point in time for agile to work.  Tooling alone does not achieve the discipline.  There is a need to devote time and resources to triage status, activities and iterations on a burn-down list.

• Agile is essentially a gateway drug for Continuous Integration.

• In fact you cannot realistically implement agile development methods without having a comprehensive set of tooling for build and release automation that are needed to adhere to the agile cadence.
• SCM is a given, Build Automation with a tool such as Jenkins is also essential and automated deployments are needed.  These in turn are commonly gateway drugs for tools such as Artefactory and a variety of other software products that are commonly found within agile teams.

• Agile is also a gateway drug for DevOps and most agile teams cannot succeed without a strong DevOps team supporting the work. 

• DevOps greases the skids for Agile development teams and effectively clears the path for innovation by the Development Team by validating key platform decisions and verifying that the technologies that are proposed in a given Epic will function reliably within the release environment.  DevOops also serves as the gate-keepers of the environments so that each environment within the release cycle can be certified for use before developers introduce newly released sofware in the environment that may be faulty and may have side-effects that destabilize the entire release environment.

In short, it is important for decision-makers to avoid getting sold on the hype of agile.  It is also important to firmly grapple with the realities of agile and the importance of agile planning and deliberate and measured implementation of agile.  Most of all it is imperative that decision-makers not allow themselves to make the mistake of trying to superimpose agile on a brittle and failed software architecture, nor can it be expected to transform legacy code in even a few short years, much less the few short months that management would like to see results.