Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)
Download Scaling Agile with C/ALMThe overarching theme of the book is evident from the following quote: "This eBook is dedicated to all of the functional and dysfunctional organizations that are eager to break down the organizational and cultural silos, and become a finely tuned software delivery machine."
The eBook begins with a succinct depiction of an all too common (nearly universal) problem:
Let’s face it; most software development teams indulge in tribal behavior. If you’re working in a large enterprise the divisions between the business, development and testers can be deep enough that these three groups reject the idea of being on the same team. Even within teams you can have deep divisions. For example, developers loyal to traditional methods, and those committed to agile approaches. Each group has their own culture, their own rituals and their own tools. Development and testing teams fluctuate between war and peace but for the most part have managed to come to understand each other. Developers lob builds over the fortress wall, testers shoot defects back at them. Unless, you’re part of an Agile team, but even in Agile shops some testers (e.g. integration, system, and deployment testers) are likely to be outside the agile “whole team.”
But when it comes to “software teams versus the business,” it’s a completely different story. People representing the business speak a different language that developers and testers struggle to understand. The testers quickly discovered an ally for shooting arrows at the mighty fortress of development. The developers however, just think they’re crazy. After all, what they want and what is realistic is often so far apart, it’s easier to just not talk. So the business throws requirements at the development teams. The development team tosses them in the trash. The test team validates the requirements against the builds and shoots defects at the development team. Much to everyone’s dismay, Agile and Agile@Scale suggest these three groups collaborate as a cohesive unit.
Particularly dismayed is the project manager, wondering "how am I going to get my team to do that?"
Agile@Scale refers to the recognition that the general problems of "tribal" behavior are made worse by factors of team size, geographic distribution of team members, organizational distribution of team members, the need for regulatory compliance, environmental complexity, and enterprise discipline. Given that many organizations must deal with multiple combinations of all these factors creates the impression that scaling agile is improbable if not impossible.
The solution proposed in this eBook is strong integration and collaboration:
- Data integration vial inked artifacts across repositories using RESTful interfaces
- increased collaboration among team members who link, navigate and track the status of delivery team artifacts
- enabled automation such as real-time reports and queries
- and, increased transparency for everyone
The mechanism for achieving this type and style of integration and collaboration is explicitly not via a monolithic "one size fits no one" tool or method. Rather, the approach presented is based on the metaphor of the Web - multiple tools and resources; loosely coupled and therefore open to custom solutions as development shops have the freedom to choose the combination of products that best suits their needs.
The discussion of integration and collaboration solutions are illustrated with examples using, understandably, IBM Rational tools. However, care is taken to point out how other vendors, using publicly available APIs, can participate in formulating a mix of interacting tools that best suits the needs of a given enterprise development team. Using the Web as as an architectural (global, resilient, loosely coupled resources) metaphor, IBM Rational launched the Jazz project. This project incorporates four components:
- Collaborative Application Lifecycle Management (C/ALM) Scenarios – providing real-world, role and task based user experiences that explore end-user goals and their needs to access data throughout the lifecycle.
- Open Services for Lifecycle Collaboration (OSLC) – to unlock the information buried within development tools, open and agreed upon interfaces are needed that allow different tools to share and exchange the data that they produce.
- Jazz Integration Architecture (JIA) – a set of inter-connected technologies and specifications, consisting of reference architecture, API specifications, a set of common services and tool building blocks.
- Jazz Foundation – an implementation of the Jazz Foundation Services, and optional toolkits to aid in the construction of Jazz applications.
Following the introductory overview the eBook has three main sections: 1) a detailed scenario of an agile development project, showing who does what, how everyone knows what everyone else is doing, and how the performance of the entire team is enahnced; 2) a "Web We Wove" section that uses the Web metaphor to review the linkages made among team members that facilitated the observed results - a kind of retrospective on the scenario; and 3) "ALM Ecosystems" that explicitly addressed how different sets of tools can be configured and integrated to achieve similar results as described in the previous two sections.
A final section offers a conclusion in the form of a recap of the Jazz project goals along with a discussion of key communities:
- The community at Open Services for Lifecycle Collaboration is working to provide open public descriptions of development artifacts (resources) and the interfaces for sharing information across the development lifecycle.
- The Jazz Foundation that provides a set of services that help drive a common user experience.
- and Jazz.net an open, innovative, and collaborative community.
The eBook's authors are: Carolyn Pampino, a member of the C/ALM leadership team at IBM Rational’s Lexington lab, working closely with the Jazz team leads to define the Collaborative ALM road map and strategy; Erich Gamma, a Distinguished Engineer at IBM Rational Software’s Zurich lab. He is the technical lead of Rational Team Concert and is a member of the C/ALM leadership team; and, John Wiegand, a Distinguished Engineer at IBM Rational’s Beaverton, Oregon lab and Rational Chief Architect. John is responsible for defining the architectural and implementation aspects of Jazz as a platform for use in products across the software lifecycle.
Yes tools are important but isn't fixing the culture problem explained in the overview more important?
If IBM, especially Rational, isn't a "Tools are a substitute for fixing culture" organization, I don't know what is.
exactly...I was trying to be cheeky! Wonder how much they paid for that ad....uh, I mean article.Jason, we don't accept paid editorial at InfoQ. Companies can buy advertising to promote content, but they can't pay us to publish something. In this case, IBM is paying to "advertise" this book and create the PDF with them, but we had the option to publish it in the vendor content area or on IBM itself, but the editors decided independently that this could be pubilshed as a normal InfoQ article because there was enough educational value to make it worthy of being an InfoQ article even if it is written in the context of Rational's tools.
We care enormously about our editorial integrity so I just wanted to make that clear.
Floyd - InfoQ co-founder
It was still an *interesting* article, and, I feel, balanced out the traditional "tools are crap" attitude that we in the Agile community are so fond of. It might tend to be true that tools generally just get in the way, but without debate and discourse, it's far from proven.
Thanks for your comments. :) InfoQ is great.