A current trend in the application development field is the emergence of new, highly integrated Application Lifecycle Management (ALM) tools that take teams through the entire development process, including requirements management, change management, quality automation, continuous integration and even continuous deployment. But with all of these new tools emerging, many of which are designed to work in tandem with an Agile development philosophy, it begs the question as to whether these tools are actually changing the way teams do Agile development.
“It sounds like a trick question.” Says Carolyn Pampino, Program Director for Strategic Offerings for IT Software Delivery at IBM. And in truth, it sort of is. After all, the Agile Manifesto really doesn’t pay any heed to tooling. Agile itself is tool agnostic, so from the perspective of a purist, the tooling shouldn’t have any impact on how an Agile team behaves. But does the situation change if the Agile team is behaving badly?
Last week, TheServerSide profiled IBM’s Scott Ambler, Chief Methodologist for IT at IBM Rational, as he discussed the water-Scrum-fall anti-pattern, where development teams cripple the process by bookending a short period of Agile development with drawn out requirements gathering and deployment phases. “We definitely don’t want to be promoting this,” says Scott Ambler about this anti-process. But many organizations are doing Agile this way, which means many organizations are doing Agile wrong.
“Agile is ten. There are a lot of teams who are talking about Agile, but not as many succeeding with it as hoped. It’s hard. It’s a discipline. It’s a behavior.” Says Carolyn Pampino. Tools aren’t necessarily a part of the Agile methodology, Carolyn explains, but if a team hasn't completely adjusted to an Agile mindset, or if a team is having a hard time adopting an Agile approach, a software platform such as IBM’s Collaborative Lifecycle Management suite can help smooth out the transition from a traditional waterfall development cycle to an Agile one.
“It helps facilitate your adoption; the process we provide helps guide the team on what you can and can’t do, and it’s very easy to change that process.” Says Carolyn about tools such as Rational Team Concert and Rational Quality Manager. “A simple change in process helps guide behavior. That can help some of the Agile adoption.”
IBM Distinguished Engineer at IBM Rational, Leigh Williamson, actually flips the question on its head, arguing that it’s not so much that tools change the Agile method, but instead, that teams working through an Agile process will constantly be changing how they use their tools.
“It’s inevitable, especially with Agile where how you use the tools will change in every iteration, based on what you learn in that iteration. How the developers use the tools must change.” Says IBM’s Leigh Williamson.
And creating software that can change and adapt as the Agile process changes and adapts is exactly what the creation of Agile tooling is all about. Talking about some of the adaptive features of IBM’s CLM tools, Leigh provides the example of where you might “go through an iteration, decide that there’s a particular metric that you didn't realize you needed before, and adjust the project dashboard to show you that particular measurement, which is now being collected automatically. The tools themselves change along with how the developers use the tools.”
The bottom line is that good ALM tooling can help facilitate the Agile process, it can help teams abandon some old, anti-Agile habits, and it can help developers make decisions that are more consistent with an Agile mindset. But in the end, tooling can only help facilitate the process, because good Agile practices transcend beyond the software being used. As IBM’s Carolyn Pampino said in her interview with TheServerSide at IBM Innovate 2012, “tools can only do so much, but bad behaviors die hard. Agile adoption is about culture change as much as it is tooling.”