This is the fifth installment in our blog series describing the transformation of our internal ALM development organization toward a Continuous Delivery model. The previous post was Planning & Execution from Prototype to Practice. In this series, we describe the motivations behind adoption of a Continuous Delivery model and the many challenges we faced as we embarked on this transformation from both the planning and execution perspectives.

Is it SAFe yet?

The short answer is ‘yes’ and if that’s all you’re wondering, stop now and be comfortable in the knowledge that yet another enterprise organization like yours believes the Scaled Agile Framework (SAFe) is valuable for scaling agile practices to the enterprise.

Since you’re still reading, I’ll assume you’re interested in how we have adopted, or more accurately adapted, the methodology and best practices prescribed by SAFe. Even further, you probably want to know about the tools. Details please!

Okay, but bear with me a few minutes while I bask in the success of how far we have come. Today, we have launched our new environment and Rational Team Concert dashboards are currently being used instead of spreadsheets to conduct reviews and planning sessions. Yay! I am extremely proud of how our organization has embraced not only the process changes but, more importantly, the cultural changes required to shift from delivering products or features or functions to delivering end-user solutions. Specifically, the ALM Program team is putting the process into action on a daily basis – and terms like ‘epic’, ‘feature’ and even ‘release train’ roll off their tongues as if we had always worked this way!

Realistically, this is an ongoing transformation – it may never be fully complete. It may also never be completely SAFe. And just as our goal is to apply agile practices to how we plan, develop, and deliver solutions to our customers, the transformation of our process is also being done in an agile way. We’ve introduced the solution internally to our organization, they will use it for planning our next quarterly release, and they will provide feedback. We will tweak and improve, use it for planning the release after that, and so on… My goal in this blog is to provide you with the details about how we developed this first iteration of our solution using our own ALM tooling in the context of SAFe.

Embracing  SAFe – Sort of…

Some SAFe “purists” snicker at my claim that we have taken a pragmatic approach to SAFe adoption – Isn’t SAFe already pragmatic? Isn’t that the whole idea around the SAFe methodology? Well, sort of… I argue that SAFe’s description of an enterprise is not necessarily the same as ours. Even the ALM organization, small relative to IBM as a whole, blows the SAFe enterprise organization characteristics out of the water. Ultimately, we may consider growing our SAFe adoption by implementing nested SAFe frameworks, something like Programs of Programs, but I digress. For now, let’s explore the details of the SAFe solution.

Organizational Overview

Consistent with the SAFe methodology, the ALM Foundation organization is comprised of teams operating at three levels, and the tooling infrastructure is designed to fully support this:

• Portfolio Level: Owner of the ALM Foundation vision and definition of “what gets built”
  • Rational Focal Point contains the artifacts that define the vision and objectives along with an articulation of ‘value streams’ in SAFe terms (although we use Business Tactics and Business Requirements)
• Program Level: Owner of the solution-level, cross-product content and release objectives, the planning and execution based on the vision
  • Rational Collaborative Lifecycle Management (CLM) tools contain the artifacts describing the solution content in support of the vision and roadmap
• Product (Team) Level: Owner of the implementation details, “how to deliver what gets built” in support of Program release objectives
  • Rational Collaborative Lifecycle Management (CLM) tools are used across our product teams.

Our focus currently is on transforming planning at the Portfolio and Program levels. We had no need to address Team-level planning except to better inform how teams prioritize and rank their backlogs. We did have to be careful not to burden the process with a bunch of extra work that brings no value – we really wanted to avoid reverting back to the dark ages by going on a planning binge. There is a balance between being agile and having a vision and roadmap. With that in mind, we do plan at regular intervals but there is also an understanding that plans can, and will, change. The key is to be able to react quickly when that happens and make good decisions based on real-time data to adjust to that change. The ALM Foundation environment leads us in the right direction.

There is one significant addition to our process that is not prescribed by SAFe, at least not to a large degree, and that is the presence of the Design team as a key player across all layers of the SAFe framework to elaborate and inform the development and delivery of solutions driven from the user perspective. SAFe does indicate that User Experience design is part of the process, but we go further to ensure scenario, functional and user experience design is integral in planning and executing on our Portfolio vision.

Infrastructure Overview

The ALM Foundation lifecycle project is a CLM project that includes:

• Rational Team Concert – ALM Foundation (Change Management)
  • Epic and Feature work items
  • Roadmap and Release plans
  • Team management
• Rational Requirements Composer – ALM Foundation (Requirements)
  • Design (Scenarios, Acts, Scenes, Wireframes, etc.) to elaborate the Epics and Features
  • Solution-level Requirements elaboration (phase 2)
• Rational Quality Manager – ALM Foundation (Quality Management)
  • Scenario-driven solution test plans and related artifacts

Phase 1 of the transformation focuses on the establishment and configuration of the ALM Foundation (Change Management) project area, which involves Rational Focal Point for Portfolio management integrated with Rational Team Concert. The artifact component model, derived from the SAFe model, is shown below (apologize for the eye-challenge!):

ALM Foundation Component Planning Model

In an effort to use as much out-of-the-box capabilities in our tooling, we have customized as little as possible to adopt SAFe. Where we have customized, there is nothing we have done that you cannot also do – no magic here. The ALM Foundation (Change Management) project area is configured using the Scrum process template as a starting point.

Project Area Associations

We must be able to link ALM Foundation work items to artifacts in other project areas. To do that, we  establish Uses and Provides associations to each of the Team level project areas as well as to other Jazz-based project areas providing support to ALM Foundation.

Team Areas

There are two types of teams represented in the ALM Foundation project area:

• Persistent Teams – These are cross-cutting teams with functional responsibilities, such as the Design, Release Engineering, Solution Test, and Architecture teams.
• Transient Teams – These are cross-cutting teams created to deliver a business capability, or value stream, driven from a Business Tactic. While these teams might exist for multiple years to complete a capability, eventually we are done and the team can move on to something else.

Members of the ALM Foundation project area are members of the Program Management team, or a supporting sub-team, and can play multiple roles across the Team Areas. Just like your own organization, our team members wear many hats!

Work Item Types

We limit the set of work item types that can be used to Epic, Feature, Plan Item and Task. The Epic type has been only slightly modified from what is configured by the Scrum template; Feature is completely new. We use Plan Item and Task as configured.

Link Types

There are many link types supported by CLM. To keep our SAFe implementation simple and consistent, we limit the link types that can be created to these, as documented in the domain model above. As we use the the project area on a daily basis and roll out additional teams, we are adding to the set of link types, but this represents our starting point.

Planning

Three types of plans are used for Program-level planning. Plans are created for the ALM Foundation as a whole to manage the set of capabilities delivered through our solutions as well as for each of the capability teams that deliver a specific solution.

SAFe best practices supported through our plans include:

• Ranking within the context of a value stream (solution capability mapped to a Business Tactic)
• Ranking across all value streams (all ALM Foundation solution capabilities mapped to Business Tactics)
• Release Objectives captured in the Release Plans and defined by Program Management team

What’s not SAFe?

I’ve already indicated that our SAFe implementation does not fit within the boundaries prescribed by SAFe for an enterprise or a Program in terms of size or complexity. Over time, our implementation may change bringing it closer to SAFe recommendations, but in the vein of “do something now” and “improve over time”, where we have started is working.

Another SAFe guideline that I believe has real value is the notion of an Architectural Runway. As described above, we do mark Epics as either Business or Architectural in nature, and we have established an Architecture team area, but we have not made significant progress in planning and managing the architecture to the same degree as the business capabilities we deliver. On our list…

In terms of more formalized or robust ranking, I believe we also have room for improvement. Ultimately we would like to introduce the concept of WSJF (Weighted Shortest Job First) into the process. For now, we operate on gut feel for the most part. Again, on the list…

So much left to do!

Our cultural shift is not complete – not by a long shot — but we are beginning to see the value of having visibility from business strategy through IT execution. In the next phase, we will add capabilities for cross-tool reporting that provides executive-level dashboards to manage the deployment and delivery at the business level as well as automated deployment and release management capabilities to align our plans with deployment and delivery. Regarding the adoption of SAFe, it has been a journey of discovery and exploration and we believe that ultimately the rewards will be great!