Most organizations often begin their agile transformation with a series of low risk, stand-alone pilots. While these pilots may prove that teams can adopt small team agile practices such as “Scrum” or “XP”, however these pilots often don’t help prove that your organization can adopt agile at the enterprise level.
Scaling agile to support larger more complex programs requires gaining alignment across stakeholders, providing program-wide transparency, and delivering end-to-end value with a large number of teams to work together (e.g., 100 – 500+).
A few months ago, I had the opportunity to launch an agile release train (ART) for a large IT project (110+ resources) at one of the financial institutions that IBM provides agile coaching and mentoring for. The organization had been following a waterfall approach for most of their larger projects until last year when they were purchased by a larger bank that was already undergoing its own agile transformation.
IBM was brought in to assess their current progress and provide additional training and recommendations for rolling out to large enterprise programs. Our mission was to assist them with:
- Defining a set of outcomes that supported the expected business benefits and assist them in successfully launching agile programs
- Identifying the value streams – the long-lived series of system definition, development and deployment process steps used to build and deploy systems?
- Defining the Agile Release Trains – the virtual organizations formed around these value streams?
- How to launch an ART and what Support IBM provides for SAFe
Here are a multi-part blog to help you launch your own train:
- Launching Agile Release Trains: Where to start?
- Preparing for first Agile Release Train (ART) launch?
1. Launching an ART. Where to start?
In its simplest form, agile offers a lightweight framework for helping organizations build software using a rapid delivery approach to providing business value. As a result these organizations are able to significantly reduce the overall risk associated with software development while providing high quality products and services.
Agile is a powerful tool for software development, not only providing benefits to the development team, but also providing a number of important business benefits to the client. In addition, many agile project teams have been able to overcome many of the most common project pitfalls (such as cost, schedule predictability and scope creep) in a more controlled manner.
The first step in our approach was to conduct a short agile assessment (or feasibility study) to verify the scope, identify the current challenges and recommend an adoption roadmap to support the transformation for the program (110+ resources).
Having helped a several customers with agile transformation projects along with the challenges and business outcomes associated with those adoptions, I was immediately concerned about our ability to coordinate across multiple teams.
The organization had several waterfall programs underway and had successfully piloted Scrum on some of their social apps. The leaders wanted our help to adopt a multi-team agile approach where some parts of the organization would stay waterfall.
After performing a quick assessment we identified the following organizational concerns
After reviewing some of the most common approaches at the time, we concluded given the organizational challenges that the Scaled Agile Framework (SAFe) would be our starting point. SAFe, created by +Dean Leffingwell‘s Scaling Software Agility, is a proven, publicly-facing framework for applying Lean and Agile practices at enterprise scale.
In most cases we have found starting with a small to medium size program is the best place to start when attempting to help an organization scale agile in their organization.
Benefits of starting at the Program Level:
- A couple of key business stakeholders usually have finally say on budget, delivery teams
- Can select program within sponsors span of responsibility / influence
- Requires more organization than going team-by-team, but significantly less effort than a “big bang” enterprise transformation
- Makes visible the real challenges of agile at scale
- Gives true, fact-based measures of enterprise agility… the ability to quickly deliver quality software incrementally in a large, complex enterprise
Here are some of the challenges of starting at the Team level.
- Have the organization / cultural impacts that a larger adoption would have
- Provide the visibility to “move the needle”
- Cover enough ground. Delays dealing with the real challenges of implementing agile at scale
Here are some of the challenges with starting at the Portfolio level:
- Working with too many In-Flight Projects
- Taking on too are a structure to impact (.e.g, Chaotic Architecture and Bloated Technology Stack)
- Working with teams outside the reach of the team to really impact them.
- Requires lean-thinking leaders and an Agile PMO who understand lean economics
- Can be delayed due to the complex organizational and cultural changes needed for a full enterprise transformation
- Difficult to manage software “assets” in a Lean|Agile portfolio if asset development isn’t agile
See here for additional information:
- http://www.slideshare.net/ScaledAgile/webinar-launching-ar-ts-why-start-30may2013?related=2
- http://www.scaledagileframework.com/
- http://www.slideshare.net/ScaledAgile
2. Preparing for first Agile Release Train (ART) launch?
For any IT project to be successful (traditional, agile or otherwise), it’s vital that it has a clear vision which can be used to guide the project team in the right direction. The team should review the vision regularly to ensure program is fulfilling what it has set out to accomplish.
Here are 3 key steps that must be done before launching the ART.
- Identify the initial set of Value Streams
A Value Stream is a long-lived set of capabilities used to provide a continuous flow of benefits to the business. Value Streams are typically realized by 1 or more ARTs and are the primary organizational concept for understanding how value is delivered in SAFe.
Here are some questions to help identify the Value Streams
- What are the larger, ongoing programs or initiatives that will differentiate your business over the next 2 to 3 years?
- How do external customers perceive the value you provide? For example what are the key products or services that you provide
- Can you describe the strategic initiatives that have 200+, 100+ or 50+ more developers / testers working together already? Do they have a high degree of interdependence between the features and components?
- What key business processes do you enable? What internal departments do you support?
- What key process, cost, KPI or business improvement initiatives are targeted in this upcoming year?
For more information checkout:
- http://www.scaledagileframework.com/strategic-themes/
- http://www.scaledagileframework.com/value-streams/
- Define Vision, Scope and identify Portfolio and Program Epics
SAFe organizes large agile projects into an scaled agile program structure containing three levels: Teams, Agile Programs (also referred to as Agile Release Trains – ARTs), and Portfolio
The Agile Release Train is the primary organizational and operational construct within SAFe. Each ART is a self-organizing team of teams, responsible for delivering business value. Ideally each value stream should be mapped to a corresponding ART, however in many cases ART may be needed to support multiple value streams or in some cases a single value stream may require the support from multiple ART to delivered the required business value.
SAFe defines an artifact hierarchy of Epics – Features – User Stories. The agile program backlog (a.k.a, ART) containing a prioritized list of features and stories. Portfolio epics are large initiatives in SAFe that drive business value. These initiatives typically cross organizational and financial reporting (quarters, years) boundaries. Most organizations Business epics are large initiatives in SAFe that drive business value. These initiatives typically cross organizational and financial reporting (quarters, years) boundaries.
Weighted Shortest Job First or WSJF comes from a comprehensive model defined by Don Reinertsen as a way to improve prioritization. In IBM’s solution, WSIF is automatically calculated based on the Job size, Business Value, Time criticality and Risk Reduction/Opportunity Enablement values provided. Then, the Program Roadmap is automatically sorted based on the WSIF score and gives a ranked view of the features’ backlog. WSIF is an useful tool to help with decision making process based on factual assumptions instead of personal feelings.
Features are usually decomposed into User Stories, which flow to Team-level backlogs, and can originate at the Program level, or they can derive from Epics defined at the Portfolio level. Features are prioritized based on Weighted Shortest Job First (WSJF) economic decision framework.
- Ensure you have established “Whole Teams”
SAFe is based on Lean principles where the minimal viable product (MVP) epics and features are identified scheduled based on both business needs and technical constraints / dependencies. Like Scrum, SAFe assumes each agile delivery team (typically between 5 to 10) people each have all the cross functional roles necessary to deliver working solution each sprint.
Unlike Scrum, SAFe assumes some stories may depend on each other or that multiple teams may need to work on Epic before it can be delivered. Prior to launching the ART, important to ensure that each of the teams have been formed with the appropriate set of agile practices (i.e., Whole Team) and know how to execute the ceremonies associate with Scrum / XP. Whole team is a philosophy that involves significant collaboration between the team members and stakeholders.
Each team includes all individual who materially define, develop and deliver software for a project:
- Any and all contributors
- Both direct and indirect participants, such as sponsors and key stakeholders
- Together have the skills to successfully communicate the essentials of a problem and deliver an agreed solution
Here are seven tips for building an effective agile team:
- Does the team have the skills to get the job done – they are “whole”
- Is the team as small as possible
- Are the people dedicated to the project and is there a single product owner
- Have a single team lead (who is not the product owner)
- Are team members cross functional, made up mostly of “generalizing specialists”
- May include specialists, hopefully on their way to becoming generalizing specialists
- Are self-organizing within an appropriate governance framework
The greater the deviation from this strategy, the greater your project risk
3. How does IBM Collaborative Lifecycle Management (CLM) support SAFe?
As part of the engagement, the IBM team led the effort to implement IBM’s Collaborative Lifecycle Management (CLM) solution to support the Agile Release Train (SAFe). IBM DevOps combined with SAFe provides a comprehensive process and tooling platform and framework that will optimize your end-to-end lifecycle, so you can synchronize development, testing and deployment across teams in heterogeneous environments, and collaborate across all roles in the organization in the planning and execution of software delivery.
IBM’s SAFe support provides the following key capabilities:
- Get up and running quickly with out-of-the-box infrastructureto lead a SAFe Program
- Improve agility and predictability with dashboardsfor visibility to adjust business goals in real-time
- Simplify change to culture and process with quick and easy access to SAFe guidance
Each team works in fixed-length time-boxes, called iterations or sprints, which typically last from two to six weeks. At the end of the sprint, there is measurable product increment or (PI).
Planning an iteration is simple: From the Product Backlog, the Product Owner (PO) and the Scrum team holds a Sprint Planning meeting to select the most important stories that can be delivered in the upcoming iteration. Once the set of stories are identified, the team breaks down the work into smaller tasks and assign it to individual team members.
The Agile Planning capabilities in RTC, can assists you doing this by several means:
- Plans are accessible to everyone in the team – Be transparent.
- Plans reflect the team’s position and direction – Know when you are about to fail.
- Plans are live as they ground on work items – No unnecessary planning artifacts to be taken care of.
IBM’s approach included a set of accelerators specifically designed to help organizations adopt a Lean mindset to take their current agile projects to the next level. Agile Planning includes a set of development practices that allow teams to plan and deliver high quality software rapidly. For more details see: see the following value-added assets:
- IBM’s SAFe Support YouTube Channel
- IBM’s SAFe Solution – Release Overview
- SAFe Point of View (POV)
- SAFe with the Power of IBM DevOps (whitepaper)
- SAFe RTC Migration Guidelines (2015-08-14)
Finally for those teams that are using Scrum methods, here is an article on using Scrum with Rational Team Concert (RTC)
About the Author/ Reedy Feggins
Reedy is a Lead Agile Coach and Software Architect with certifications as a SAFe SPC, Certified ScrumMaster and PMP® certified project manager with over 20 years’ experience leading successful IT projects, employing a combination of Agile, Waterfall, and RUP processes. At IBM he currently works as a Agile Coach leading large and medium agile transformations. Reedy has published papers in several magazines as well as been an invited speaker at conferences. His experience as a trainer has led to the development of several custom workshops on topics ranging from Project Management to Process Adoption.