InfoQ

InfoQ

Article

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

Posted by Carolyn Pampino, Erich Gamma, and John Wiegand on Jun 29, 2009

Sections
Process & Practices
Topics
Team Collaboration ,
Collaboration ,
Architecture ,
Agile
Tags
IBM ,
Jazz ,
IBM Rational
Scaling Agile with C/ALM (Collaborative Application Lifecycle Managment) an eBook from IBM Rational in collaboration with InfoQ, is now available.

Download Scaling Agile with C/ALM

The 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.

Download Scaling Agile with C/ALM

  • This article is part of a featured topic series on Agile
huh? by Jason Little Posted
Re: huh? by Barrett Nuzum Posted
Re: huh? by Jason Little Posted
Re: huh? by Floyd Marinescu Posted
Re: huh? by Barrett Nuzum Posted
Re: huh? by Oleg Smirsky Posted
  1. Back to top

    huh?

    by Jason Little

    perhaps I'm not too bright, but this sounds an aweful lot like "does your culture suck? since your team members hate each other, throw this tool at them so they can collaborate without actually having to interact with each other"

    Yes tools are important but isn't fixing the culture problem explained in the overview more important?

  2. Back to top

    Re: huh?

    by Barrett Nuzum

    Yes, but consider the source.. It's IBM.

    If IBM, especially Rational, isn't a "Tools are a substitute for fixing culture" organization, I don't know what is.

  3. Back to top

    Re: huh?

    by Jason Little

    exactly...I was trying to be cheeky! Wonder how much they paid for that ad....uh, I mean article.

  4. Back to top

    Re: huh?

    by Floyd Marinescu

    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

  5. Back to top

    Re: huh?

    by Barrett Nuzum

    Floyd - You also don't seem to sell my email address to everyone under the sun. :) Thank you for that. I believe TechTarget does just that, to my dismay.



    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.

  6. Back to top

    Re: huh?

    by Oleg Smirsky

    Huh, agile manifesto says "That is, while there is value in the items on the right, we value the items on the left more". Nothing about "tools are crap" ;-)



    Oleg

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.