If successful software deliveries are the product of a team-based approach to application development, why is it that organizations so often build barriers between the various teams participating in the broader application lifecycle management process?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
In a typical organization, it's not uncommon for one team to do architecture, one team to do requirements gathering, one to manage deployment, and of course, given the proven success of the Agile methodology, another to do Agile development.
Now, does it really make sense for so many clear lines of delineation to exist between teams? And more important, if one team experiences a measure of success using a certain set of tools and techniques, shouldn't the sharing of that success be immediate, unimpeded by imaginary barriers put between different sets of people? It's a question that many converts to Agile have been asking.
Tearing down the silos
The derogatory term of the day is silo, intended to conjure up the image of a long chain of concrete grain elevators standing independently, yet side by side. Many IT managers and CIOs are frustrated because, despite working together toward a common goal, the various teams and groups that participate in the software development lifecycle behave in a far too isolated manner.
In the silo of software development, Agile has proven itself as an effective process for dealing with change, delivering releases on time, keeping software quality high, and maintaining a high level of motivation and enthusiasm throughout the workforce. Naturally, managers and directors want these types of successes for all the teams participating in the ALM process, not just those working on the development side. But extending the success of Agile throughout the entire ALM process can't be achieved by simply applying the same Agile techniques in each silo. The approach tends to be much more drastic: The walls of the silos must be torn down.
"What I favor is a one-team approach that connects all stakeholders, including the developers, coders, testers and operations engineers, who all should be using the same processes and tools," said Michael Hüttermann, author of DevOps for Developers. When the walls that often separate architecture, development, requirements gathering, quality control and operations management crumble, everyone with a stake in the software project has no other option than to work together in a continuous and Agile fashion.
Of course, tearing down silos is a highly disruptive process, and like any disruptive change, there are challenges that stand in the way of a smooth and easy execution. The biggest hurdle is often the cultural changes required to make such a shift in behavior. Far too often, teams that are comfortable with more traditional, Waterfall-based approaches are hesitant to commit, adopting only the methods with which they are comfortable while ignoring other Agile practices. Fortunately though, there are certain key practices that, once put in place, act like a rushing stream, and individuals who decide to work against the current will inevitably get washed away. Continuous integration (CI), delivery and deployment are interrelated approaches to software development that undermine the foundations of the various silos that organizations have been unwittingly erected over time. Once they are in place, they will begin to force collaboration and interaction between previously separated teams.
The continuous trifecta
CI has become a de facto requirement for any software team doing Agile development today. "Continuous integration is basically building and testing your application every time you commit a change to version control," said John Smart, author of Jenkins: The Definitive Guide. "The basic tenet of CI is this: When a developer has completed a piece of code, that code gets checked into the master repository. Immediately upon being checked in, a variety of tests are triggered, ensuring that the code not only works, but that the change on the current branch doesn't adversely affect the build as a whole." CI is the cornerstone of any Agile software team, but it isn't until we start moving into continuous delivery that the Agile process begins to break out of the confines of software development and starts affecting how other silos work.
Continuous delivery builds on CI, but goes one step further by automating the movement of a given software package out of development and into the hands of regression testers, quality assurance (QA) or user acceptance testing (UAT). "Continuous delivery is the principle that, if it passes all the automated tests, any commit should be a potentially valid release candidate, and changes the way you think about releases," Smart said. When continuous delivery is done right, the successful completion of running various test suites in each of these stages -- be it development, testing, QA or UAT -- can be the trigger that automates the continuous delivery of software from one environment to the other.
Beyond development and integration
For those organizations that streamlined the process of CI and continuous development -- while maintaining a history of delivering quality software to their users -- the next move is continuous deployment. Deployment is when software is moved immediately into production and released directly into the hands of the user. With continuous deployment, it appears that tasks traditionally performed by QA or the operations management teams are skipped, but in fact, nothing could be further from the truth. Instead, many of the jobs historically performed by other silos in the organization are baked right into the CI process. The continuous development process doesn't go away, but the manner in which it is stitched into the fabric of CI makes it invisible. When this level of collaboration and integration between testing, development, user acceptance and operations has been achieved, organizational silos have no other option than to cave in on themselves, making Agile the only option for managing the application lifecycle.
There is little debate in the software development community about the fact that combining an Agile approach with CI technologies is an effective method for developing applications. Converts to Agile have recognized that the strategies and techniques used to deliver high-quality software products should not be limited to the software development team. Forward-thinking IT professionals are working to make the entire ALM process a continuous and Agile one, but that's not easily achieved.
Fortunately, there are mechanisms that can be put in place, such as CI, delivery and deployment processes, that allow all the various teams with a stake in ALM to work together better. As more teams in the organization embrace the continuous, more Agile approach to software development, the successful delivery of quality software will become more routine than it has ever been before.