Building Complex Systems with SAFe


By Alex Yakyma and Harry Koehnemann

300x250-View-NowVersion 4.0 of the Scaled Agile Framework® SAFe® was released just about two months ago but has already generated keen interest on behalf of complex systems builders and large software enterprises. The new version provides specific depth for organizations that build world’s largest and most critical solutions. Version 4.0 has a new optional layer that includes a set of practices for building large, complex systems in a Lean and Agile manner. It provides better modularity and addresses a number of challenges that large systems builders encounter when organizing around the flow of value, such as coordinating Agile Release Trains in a large Value Stream, or coordinating multiple value streams in the portfolio.SAFe-Value-StreamIn this article we will discuss the challenges large systems builders face and key approaches for addressing them. But before we start down that path, let’s understand first what makes complex systems development so complex.

The Roots of Complexity

So, what makes the development process so much harder in the world of large, complex systems? Let’s consider some common factors:

  1. The multidisciplinary nature of the systems. These systems require collaboration and integrated components from a broad set of deep engineering skills that include software, firmware, hardware, electrical, mechanics, optics, and hydraulics, to name just a few.
  2. The architectural complexity of the systems. Even in the case of pure software, complex solutions may contain hundreds, or even thousands, of interconnected components, subsystems, services, and applications.
  3. Legacy technologies. Modern systems leverage existing solutions initially developed (potentially) decades ago and involve high cost of change and poor support for modern ways of engineering and testing.
  4. Complex production environments. Our complex operational environments challenge the creation of equivalent environments for integration, testing, and demonstration of results.

These factors are sometimes mistakenly considered impediments to adopting Agile and Lean. However, let’s explore where we stand with traditional methodologies.

Traditional Methods Are Not Up to the Task

Traditional, phase-gate methods fail to cope with these complexities. Despite heavy weight and robustness, they are subject to a fundamental flaw: the assumption that complex systems can be “figured” in a speculative, detailed, up-front manner. As a result, enterprises prematurely commit to detailed requirements and design before any actual learning begins, therefore dismissing a broader variety of more economically beneficial solutions that may emerge later. They fail to ensure quality and fit for purpose because of heavily inhibited feedback. They run over schedule and budget due to lack of objective measures of progress, measures that would rely on tangible increments of the solution rather than the amount of effort already spent or other poor proxies for value.

Despite all the problems with traditional methods, transition to Lean and Agile is often impeded by a number of myths that surround complex systems development. Let’s consider the most common ones:

Myth 1: Frequent integration and testing is not possible in the case of hardware development (or other non-software domains).

Myth 2: People from different domains (SW, FW, HW, etc.) can’t work together.

Myth 3: Complex systems development must follow the phase-gate process model to be successful.

 Myth 4: Non-software disciplines cannot produce meaningful value in small increments.

Let’s try to take a more pragmatic view and address these myths referring to a more generic view across all engineering disciplines as part of product development.

The Problems May Be Different But the Principles Are Universal

In his article on Agile in hardware development, Ken Rubin concludes that applicability of Agile methods is not a binary choice but rather is influenced by the cost of change of the underlying system. Hardware, he argues, has a higher cost of change than software. This dictates certain adjustments but does not exclude agility—just the opposite, in fact, since the cost of error is also often higher in the case of hardware. Dantar P. Oosterwal, in his book The Lean Machine, shares the experience of Harley-Davidson in their search of a better product development method. The great epiphany, he points out, was to realize that the success of a new development initiative did not depend on the success of individual phases in the process. Instead, projects that went through multiple, consequent design cycles supported by actual system integration were significantly more successful than their “waterfalled” counterparts.

These and other examples suggest that complex systems development is governed by a leaner and more Agile set of principles. Furthermore, these principles would hold true for different business contexts, engineering disciplines, and solutions. SAFe considers nine such principles:Principles

Having stated a set of governing principles, now is the time to consider specific practices and patterns for complex systems development.

Putting the Principles to Work

We will split the discussion of implementing the practices into three sections:

1 – Organizing Around Value

Large, physical systems often organize around functional areas. Organizing around function or discipline helps ensure technical integrity, but it also contributes to handoffs, delays, and waiting across team boundaries. SAFe adopts a more pragmatic approach: organizing around value. This paradigm aims at the key goal of establishing the shortest sustainable lead time in value delivery, and it achieves it by building organizational units in such a way as to contain most dependencies inside each unit rather than spreading them across different units.Dependencies

Building fully cross-functional and cross-domain Agile Teams (of 6 – 9 people) may not be feasible in many cases. However, creating an Agile Release Train—a self-organized team of teams that usually consists of 50 – 125 people—that includes all functions and aspects of engineering is absolutely feasible in most cases and should be done whenever it meets the objective of establishing a sustainable, fast flow of value.ARTsLet’s consider an example: a product that involves software, firmware, and hardware development, with hundreds of engineers in all domains. How should we organize the trains?

For that we need more context. Let’s say that in our particular case, hardware is tightly coupled with firmware, which in turn creates an abstraction layer for the software operating system and the specific applications and services that run on top of it. This gives us the first cue: putting hardware and firmware engineers on one Agile Release Train is probably a good idea. And in case we end up with too many people, we might end up with multiple FW-HW trains, each organized around a subset of the key system capabilities. But should software teams be on these same trains as well, or should they be separate?

In the case of our system, hardware and firmware changes are being released at a relatively infrequent rate, while software teams should be able to produce over-the-air updates every few weeks. Given both decoupled interfaces and release schedules in this particular case, we might benefit from actually having software teams on a separate train.Example2 – Synchronize Development

Once organized in the structure that supports value creation, we need to establish the actual rhythm of development. Aligning on a common cadence creates such a rhythm by focusing large programs to the work in the current Program Increment or PI (8 – 12 weeks), reducing excess work-in-process (WIP), and making unpredictable events more predictable. This common cadence aligns the diverse value stream members we find in these large, complex systems. We expect practitioners from different engineering domains, as well as Suppliers and the Customer, to participate in the PI Planning so they can understand what we are building as a set of ARTs in a larger value stream. SAFe® 4.0 provides additional mechanisms of alignment via Pre- and Post-PI Planning, in addition to the standard PI planning routine practiced by Agile Release Trains.

Teams on the train also execute on a cadence of short Iterations, each providing a demo of an integrated increment within the ART’s area of concern.

To close the loop, PI boundaries provide Inspect and Adapt opportunities that build on the objective measure of progress—the integrated, end-to-end Solution Demo. Thus the cadence provides the “meter” for incremental Solution development from end to end—the direct opposite of the phase-gate process model.SolutionIn order to support such a cadence, teams and trains in the value stream need to learn to frequently integrate and test.

3 – Frequent Integration and Testing

Delivering value quickly challenges large systems due to the lead time needed to acquire and then integrate their functional parts. Despite those challenges, we strive to demonstrate value quickly by continually providing increasingly closer approximations of the end-to-end, integrated solution. We create these closer approximations at least every PI, and possibly every iteration, to demonstrate progress and provide objective evaluation of the current solution for stakeholder feedback.

Achieving these frequent learning Milestones may be difficult when aiming only at a full, end-to-end integration of all subsystems and components. We might need to look for a way to provide approximations for the subsystems of the real solution for which the cost of integration will be sufficiently low and that would allow us to perform such integration on a frequent basis. When we do so, and replace a subsystem with a simpler “proxy,” we reduce the cost of integration but may negatively impact the quality of feedback from such integration. So, for example, replacing the subsystem with a primitive stub may incur significant cost later, when we learn that we made a number of false assumptions based on a very shallow proxy for our subsystem. In the general case, we are dealing with an economic trade-off, as the picture below suggests.


The horizontal axis represents different possible ways to “proxy” the subsystem behavior. It starts with the subsystem itself (as an ideal, perfectly accurate proxy) and follows a range of cyber-physical proxies through to pure software alternatives and all the way to the simplest possible stub. The vertical axis represents the cost associated with the process. The blue line shows decreasing cost of integration, while the grey line represents increasing cost of inaccurate feedback as we move from more complex and accurate approximations to more lightweight and primitive ones. Somewhere in the intersection of the two curves lies the optimum choice for our subsystem.

If we look at the entire solution, such a decision generally needs to be made for every subsystem.Entire solutionEach subsystem has its unique correlation of cost of integration and feedback fidelity. Therefore, we require a balanced approach to identifying the best point on the spectrum of possible proxies. The entire solution integration then relies on the respective choices for each subsystem: for example, some may be high-fidelity proxies, some may be actual subsystems and some may be just stubs, as the picture above suggests.

It is also useful to consider a more “incremental” approach to picking the right spot on the spectrum for different subsystems. It is not uncommon for hardware engineers to separate logical control from their physical device to create a closed testing loop. Initially, when no functional behavior exists, stubs that simulate the subsystem’s request-response behavior serve as proxies for integration and testing. Also, early in the process teams may use models (model in the loop, or MIL) that later evolve to software (SIL) and eventually hardware (HIL) proxies. Each step more closely approximates the sweet spot.


In this article we considered the key challenges that make complex systems development so complex. While some may appear to be impediments to the adoption of Lean and Agile practices at the first glance, it is even more critical to apply Lean and Agile where cost of error may be incredibly high. We explored the myths that surround Lean-Agile in a complex, multidisciplinary world and tried to take a balanced view based on SAFe principles—immutable, universally applicable “laws of physics” that govern product development. We put those principles to work by considering specific implementation of the core practices around organizational structure, synchronized development, and integration and testing. We showed how practices could be adjusted to provide improved results in different contexts based on selective optimization.

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in SAFe, scaled agile, scaled agile framewok | 3 Comments

Is it time for a SAFe Health Check?

SAFe-Health-Check-800x328Scaled Agile Framework® (SAFe®) is exciting!  It’s easy to see the possibilities that the framework can bring to your enterprise as it blends numerous best practices, values, and principles with a constantly evolving library of courseware.

If you’ve begun your SAFe journey, you’ve likely trained lots of your people, launched Agile Release Trains (ARTs), and seen some of the many benefits that Lean and Agile can bring to the Enterprise.  Alternatively, you may also be seeing that improvements have plateaued, the cadence of delivery has slowed, and people are beginning to disengage.

Late last year, I worked with a large enterprise client who was a fairly early SAFe adopter; however, they were no longer experiencing increases in the benefits that they had seen when they first implemented the framework.  We did an assessment, something we started referring to as a “SAFe Health Check,” and found that the values, principles, and practices that make up the foundation of Agile at scale did not make it into the sustaining phase of their change.

At the 2015 Scaled Agile Partner Summit, I was able to facilitate a session to discuss the concept of a SAFe Health Check with some of the great SPC’s and SPCT’s.  Together, we came up with a list of some of the common symptoms as well as a variety of treatment options.

Symptom – Low energy and lethargy: People are just going through the motions; energy and excitement is low; the right people have stopped showing up at meetings and ceremonies; the “old way” is exerting its gravitational pull.

Symptom – Something “Smells” Off: Deliverables are being missed; commitments aren’t being met; the metrics are perfect; agile ceremonies are being shorted; release planning attendees and/or time is cut; teams aren’t concerned about spillover from one sprint to another; there is a lack of valuable continuous improvement; singular focus on production without time for improvements and innovation; people aren’t laughing.

Symptom – “Un-SAFe” Living:   The focus is on processes as opposed to values and principles; big room planning includes “key” individuals only; constant or frequent change and churn within ART’s and/or teams; “I need it now” becomes the norm (interruptions and emergencies are the norm); people aren’t finding value in particular ceremonies; features are broken down into requirements and assigned to teams; people are focused on their own team or deliverables as opposed to being invested in the program.

Symptom – Major Life Events: Original advocates, sponsors, change agents, etc. have moved on, and “ownership of SAFe®” is not transferred and/or wanted.

Treatment Options – Triage: Have an “all hands” to reinforce the focus and vision of the ART, go back to the basics, and do PI Planning as intended (work the program), bring in a coach to help teams see why they need to work together, and use SAFe®, Agile and Lean values and principles.

Treatment Options – Continuing Care: Ongoing coaching and training; develop internal coaching skills (ICAgile, etc.); provide new people with the same level of training given to those when SAFe was introduced; regularly do SAFe self-assessments to aid in continuous improvement; respect WIP limits – especially at the program and portfolio level define and run experiments to test and learn; use 360 degree surveys, candid feedback forums, etc. to understand the values and principles upon which decisions are made; reinforce or define true success measures at the ART and team level; introduce and/or encourage the use of spikes; review the value stream and address areas of waste or blockage.

 Treatment Options – Alternative Medicine: Learn more about Change Management (ADKAR, etc.) and factor this into your journey; create a post in a SAFe forum to discuss your specific issue(s).

Treatment Options – See a Specialist:  Bring in a SAFe partner to assist you in assessing and addressing your challenges.

As with any complex system, continued care and attention of your SAFe portfolios and ARTs will allow them to run optimally and continually evolve.  Additionally, you may want to look at SAFe 4.0 as this new version of the framework includes a strong foundational layer that can help prevent many of the symptoms discussed above.

Please feel free to reach out if you have any questions or comments.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Posted in SAFe, scaled agile, scaled agile framewok | Leave a comment

Top 10 Things to Know About SAFe 4.0


Are you considering Scaled Agile Framework (SAFe) 4.0 for your organization? You’re
not alone. More than a thousand people participated in VersionOne’s recent AgileLIVE
300x250-View-Nowwebinar series on SAFe 4.0 featuring Dean Leffingwell, the co-founder and chief methodologist at Scaled Agile, Inc. Dean shared a detailed overview of what’s new in SAFe 4.0. Here are the top 10 questions from the webinar. If you would like to listen to the recordings, click on the view now link.

1. Can you highlight the addition and changes in 4-level with 3-level SAFe 4.0?

The optional 4th level, inserted between the Portfolio level and the Program level, is an explicit representation of a Value Stream. The 4th level is designed for situations where there are multiple Agile Release Trains (ARTs) working together to deliver customer value in a single Value Stream. At the Value Stream level, Features from the release trains aggregate into Capabilities, and those are delivered to the customer as a Solution. You can read more about the Value Stream level here.

2. Can you define a System Team?

The existence of the System Team is recognition that as the work of several agile teams is aggregated into Features and Capabilities, maintaining the infrastructure for Program- and Value Stream-level integration and testing is a full-time job. A more detailed explanation can be found here.

3. Can you explain the difference/relationship between a Value Stream and an ART?

A Value Stream is a long-lived series of steps that provide a continuous flow of value to the customer. An Agile Release Train (ART) is a long-lived team of teams that is organized around a Value Stream. A Value Stream can have many ARTs within it.

4. What is the key to crossing back in forth or connecting the various levels in SAFe?

The primary mechanism for this is the enterprise Kanban system. As epics move through the Portfolio Kanban, for example, there will be a state that triggers flow to the next lower level (the Program in 3-level SAFe or the Value Stream in 4-level SAFe). This article explains this in greater detail, and diagrams how Kanbans may connect to each other.

5. What is the difference between a Capability and an Epic or Theme?

Strategic Themes are high-level business objectives that align a Portfolio with the enterprise’s goals.  Epics, Capabilities, and Features exist within the context of those themes. This discussion of the SAFe 4.0 requirements model is helpful for understanding the relationships.

6. Why would you decentralize decision making? Doesn’t this disempower the product owner or cause confusion about who is the final decision maker?

When everything has to go through an “approval process”, flow can grind to a halt – especially in large systems. Decentralization of decision making simply means that a SAFe organization enables as much local decision making as possible. There are roles defined at each level to provide guidance. You can click on the role icons here to get a better idea.

7. Are there any reasons that Scrumban would not work with SAFe?

SAFe really is a Scrumban system of sorts. Prior to SAFe 4.0, Scrum teams worked at the Team level, within the larger iterative Program Increment (PI) cadence. Now, with 4.0, both Scrum and Kanban teams have been “legitimized” at the Team level, and can coexist within the same program. And while there is still a PI cadence, there are Kanbans now at the Portfolio, Value Stream, and Program levels. Here’s more info on team-level Kanban in SAFe.

8. We have some applications that use Scrum delivery practices and some that are milestone driven (waterfall). Can SAFe 4.0 support both epic and user story management planning, backlog prioritization for Scrum teams, as well as requirements management for our waterfall teams (until they transition to agile)?

Higher-level artifacts, such as roadmaps and milestones can help to maintain alignment between agile teams and those that operate within the same value stream using a non-agile approach. It’s important to keep the non-agile teams involved in the cadence of planning, demos, and adaptation.

9. Some teams may run continuous integrations while others not. How can we balance this if we have a fixed Program Increment timeline?

At the Team level, this is where the “XP” part of “Scrum/XP” comes into play. At the Program and Value Stream levels, DevOps and the System Team are emphasized, because fast delivery with quality is impossible on a large scale without the necessary infrastructure and technical practices. You have to start where you are, though, and implement steps to bring the teams that are lagging along.

10. Is SAFe making it more complex and less agile (e.g., more rigid, additional control)?

That’s always the challenge, isn’t it? The reality is that a 1,000-member organization will never be as nimble as a 7-person Scrum team. In SAFe, a foundation of Lean-Agile leadership and a bias toward decentralized decision making will help to mitigate the tendency toward bureaucracy.

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in SAFe, scaled agile, scaled agile framewok | Leave a comment

3 Things To Like About SAFe 4.0

Main_3-things-about-safe-800x328Scaled Agile Framework® (SAFe®) 4.0 for Lean Software and Systems Engineering was officially unveiled last month, and I like what I see.

SAFe 4.0 Big Picture used with permission from © 2011-2016 Scaled Agile, Inc. All rights reserved. Original Big Picture graphic found at

SAFe 4.0 Big Picture used with permission from © 2011-2016 Scaled Agile, Inc.
All rights reserved. Original Big Picture graphic found at

Here are three things that stand out to me:

The Framework Has Matured

I believe that SAFe can now be called a “mature” framework. Evidence of this is that the changes in the model from version 3.0 to 4.0 have been by extension, rather than by invention.

What I mean is that, although there are some new things in 4.0, those things are based on patterns that already existed in the framework. For example, the Value Stream level looks and behaves a lot like the Program level, and you could think of Capabilities as super-sized Features.

The lack of the need to introduce anything fundamentally new has also provided an opportunity to do some cleanup and refinement. Earlier versions of the Big Picture looked as if it would collapse under the weight of all those icons. The Big Picture is better aligned and less cluttered now, and I really like that it more clearly emphasizes that a Portfolio serves the Enterprise.

The Framework is Adaptable

The most obvious change in SAFe 4.0 is the addition of the optional Value Stream level for large, complex solutions delivery, where a SAFe Program isn’t comprehensive enough. Kudos by the way, to the Scaled Agile crew for abandoning their original plan to have two different Big Pictures — one with three levels and one with four levels. The single, collapsible picture is easy to use, and my guess is that this approach forced lots of discussion that might otherwise have not taken place.

The reason that this makes it on my list of things to like is not so much the direct applicability to large systems (although that’s important). It’s because SAFe 4.0 authoritatively demonstrates that the framework can be adapted to meet the needs of different situations.

Granted, there is a lot of documented structure around this “official” adaptation, as it’s a published change to the very framework itself. But this example should give heart to an organization that sees the need to make legitimate local adaptations to its SAFe implementation, but has been reluctant to do so for fear of being guilty of no longer “doing SAFe”.

The Framework Calls for Horizontal Cohesion

SAFe has always emphasized organizing around value streams over organizing around function or projects. But there’s no escaping the hierarchical orientation of SAFe’s organizational model.

On top of that, we humans can take any organizational structure and build silos within it, even when unintentional. Large, distributed organizations tend toward isolation of groups, regardless of what they’re grouped around, unless something is purposely done to counter that.

I’m glad that SAFe 4.0 highlights the need for Communities of Practice, and calls them out right in the Big Picture. Without communities of practice, it’s too easy to isolate ourselves within value streams as we organize around them.

In a Nutshell

I believe that SAFe will continue to evolve as the boundaries of business and technology keep pushing outward and overlapping each other, and as practice demonstrates what is and isn’t working. For now though, I see SAFe 4.0 as a robust edition of what was already a very good framework.

Click here for more information on VersionOne’s extensive support of SAFe.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Posted in SAFe, scaled agile, scaled agile framewok | Leave a comment

How VersionOne Supports SAFe 4.0

300x250-View-NowScaled Agile Framework® (SAFe®) 4.0 clarifies many aspects of the framework that have been evolving since its inception. It also adds explicit support for the development of very large systems. Even so, you may still be finding your SAFe transformation a little more challenging than you expected.

Here’s how VersionOne can help with your SAFe 4.0 implementation:

3- and 4-Level SAFe

SAFe 4.0 introduces an optional fourth level to explicitly represent the Value Stream. The 4-level model is intended for large systems that realize customer value via the aggregation of features from multiple release trains into a solution.

SAFe 4.0 Big Picture used with permission from © 2011-2016 Scaled Agile, Inc. All rights reserved. Original Big Picture graphic found at

SAFe 4.0 Big Picture used with permission from © 2011-2016 Scaled Agile, Inc.
All rights reserved. Original Big Picture graphic found at

VersionOne’s n-tier Project Tree enables you to easily create as many organizational tiers as needed. So whether you have a 3-level or 4-level SAFe implementation, or a combination of both models within the same enterprise, it’s just a matter of configuring the Project Tree.

A VersionOne Project Tree, with 3- and 4-Level SAFe

A VersionOne Project Tree, with 3- and 4-Level SAFe

Enterprise Kanban Systems

Multi-level Kanban is an important addition in SAFe 4.0. By having Kanbans at the Portfolio, Value Stream, and Program levels, Epics, Capabilities, and Features can all be visualized and managed for flow and economic benefit.

VersionOne has provided multi-level Kanbans for quite some time. Kanban Boards are configurable as appropriate at each level. By using Kanban boards, you configure your workflows, establish WIP limits to assure flow, provide real-time visibility for work in process, and drill into the underlying details as needed.

A Kanban Board in VersionOne

A Kanban Board in VersionOne

SAFe 4.0 also recognizes Kanban at the team level. By using TeamRoom™, VersionOne makes it easy for Kanban teams and iterative teams to coexist and collaborate within the same program.

Capabilities & Enablers

SAFe 4.0 has introduced two new portfolio item types: Capabilities and Enablers. Capabilities are aggregations of Features, and are the means by which solutions are delivered to customers at the Value Stream level.  In VersionOne, a Capability is simply a Portfolio Item type. Configuring a Portfolio Item type is easy, and includes the ability to distinguish one type from another by color.

A Portfolio Tree in VersionOne

A Portfolio Tree in VersionOne

Enablers are technical undertakings that support Stories, Features, Capabilities, and Epics. Enablers may be found at all levels, so you might have Enabler Epics, Enabler Capabilities, Enabler Features, and Enabler Stories. Each of these can be configured as a Portfolio Item type or Story type. Some organizations prefer to keep their type lists as lean as possible, and opt to use a custom field to designate a Portfolio Item or Story an as Enabler.  Either way will work.

Communities of Practice

SAFe 4.0 refers to Communities of Practice as “informational working groups designed specifically for efficient knowledge sharing and exploration across teams and groups of professions”. The idea is that as people become distributed across different teams and value streams, there needs to be a way to keep them connected. If “Communities of Practice” is too formal for your liking, Spotify’s “Chapters” and “Guilds” are different ways of expressing the same thing.

VersionOne Communities support your Communities of Practice by allowing people to communicate and collaborate on shared knowledge and “better practices” within the VersionOne platform.

Communities in VersionOne

Communities in VersionOne

Communities may also be used by your organization’s Agile Center of Excellence (or similar) to communicate guidance that applies across Teams, Programs, Value Streams, or Portfolios.

 Strategic Themes

Although not new with SAFe 4.0, Strategic Themes are a key factor to succeeding with SAFe – especially with very large systems. That’s because they are the high-level enterprise business objectives that guide and constrain portfolio-level investment.

Strategic Themes in VersionOne

Strategic Themes in VersionOne

Once you’ve created your Strategic Themes in VersionOne, you can identify and group your Epics by Strategic Theme. Then, using VersionOne Budgets, you can make specific capacity, currency, or percentage allocations to your Strategic Themes, and then track progress against those allocations.

Portfolio Budgeting

SAFe 4.0 advocates the allocation of budgets to Value Streams. VersionOne Budgets allow you to do just that. Budgeting can be allocated in terms of specific quantities of capacity or currency, or in terms of a percentage of the total. As work progresses, visualizations allow you to easily compare actuals to your planned budget.

Budgets in VersionOne

Budgets in VersionOne

As mentioned earlier, Budgets may also be allocated by Strategic Theme.

VersionOne also enables you to distinguish between work related to capital and operational expenses at any level that you need to track them. This facilitates CapEx and OpEx reporting.

Built-in Quality

VersionOne facilitates building quality in via its native Acceptance Test and Regression Testing capabilities, as well as its support for a wide selection of TDD, BDD, and ATDD tools.

A Sample of VersionOne’s Integrations

A Sample of VersionOne’s Integrations


SAFe 4.0 emphasizes agility and coordination throughout the enterprise. To enable the effective flow of value, software delivery and deployment processes must be tightly integrated across Teams, Programs, and Value Streams. In addition, as release batches become smaller, release velocity increases, and Value Streams become more complex, the ability to easily track and automate the flow of value all the way through production deployment becomes increasingly crucial.

VersionOne Continuum: End-to-End Continuous Delivery Solution

VersionOne Continuum: End-to-End Continuous Delivery Solution

More than simply DevOps automation, VersionOne Continuum™ is an enterprise-scale continuous delivery solution for orchestrating and visualizing the flow of change throughout the software delivery cycle. For an in-depth look at VersionOne Continuum, take a look here.


VersionOne is a Scaled Agile, Inc. Gold Certified Partner in both the Agile Tooling and Services categories. In addition to extensive support for SAFe 4.0, VersionOne’s Services team delivers training and consulting services through certified SAFe Program Consultants to help organizations implement and succeed with agile and the SAFe framework.

Interested in learning more? Join Dean Leffingwell for a free webinar to learn what’s new in each level of SAFe 4.0. Click here to register.


Continuum is a trademark of VersionOne Inc.
Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in SAFe, scaled agile, scaled agile framewok | Leave a comment

Top 10 Agile & DevOps Blog Posts of 2015

thumbnailTime flies when you’re having fun, right? We rushed through 2015 and we saw some excellent posts. Together with our bloggers our goal is to create free insightful and actionable content to help you with your agile and DevOps journeys.

To help us get started with a great 2016, we thought it could be helpful to share 10 of the most popular blog posts for inspiration:

1. Three Leadership Musts for DevOps 
To enable success, there are three “musts” that leadership should have when launching a DevOps movement. These “musts” are based on the premise that DevOps requires disruptive leadership.

2. 10 Benefits of Agile You Definitely Don’t Want to Miss Out On
Are you sure you’re receiving the most benefits of agile possible? Read this article to learn what nearly 4,000 of your agile peers said were the benefits of agile that their organizations are receiving.

3. ScrumMaster: Servant Leader or Secretary?
In Certified ScrumMaster (CSM) courses, many Scrum myths are busted. One such myth is that the ScrumMaster is somehow an administrative assistant to a development team, to a product owner or to an organization.

4. Top 10 Tips for Measuring Agile Success
Choosing the right agile metric to measure agile success is really simple, right? I wish that were the case, but in reality choosing the correct agile metric can be a little tricky.

5. What Kind of Agile Are You?
As many as 94% of organizations are practicing some form of agile according to 9th annual State of Agile survey™, yet I have first-hand experience seeing countless organizations that aren’t doing agile right, aren’t getting the maximum benefits and are just taking a superficial approach. So how can you tell if your organization is doing agile right?

6. Measuring What Counts: Introducing the Better, Faster, Cheaper, Happier Measurement Framework
The single biggest problem we see is organizations not understanding why they are changing the way they work – they don’t visualize the goal, set any targets, measure the improvements, nor demonstrate the benefits generated. In this article we will look at one way to establish a measurement dashboard to support your agile transformation.

7. The 7 Best DevOps Books
With the relative newness of DevOps, there are not yet a ton of DevOps books. That’s why we’ve assembled a list of the 7 best DevOps books based on four criteria: the number of ratings from Amazon, the average Amazon rating, number of ratings from GoodReads and the average GoodReads rating. Both Amazon and GoodReads use a scale of 1 to 5 stars with 5 stars being the best.

8. Why Agile Won’t Make You More Productive
According to the 9th annual State of Agile™ survey, more organizations are adopting agile in order to improve productivity. This made me wonder why there is a perception that if companies transition to agile, teams will be more productive. I could see where delivering working software frequently and at a sustainable pace speaks to teams being more productive in agile.

9. How the Words You Use Affect Your Team
Words have a huge impact on team members affecting their work and ultimately your project, yet we often don’t put much thought into the words we use every day. Check out some of the positive and negative connotations of traditional and agile project management words.

10. 7 Tips We Learned About SAFe from Dean Leffingwell
Here are seven tips I learned from the recent AgileLIVE Webinar on “Scaling Agile Faster, Easier, Smarter with SAFe and VersionOne.” In addition, there were more questions than we had time to answer during the live event. I’ve attached the Q&A here.

What were some of your most memorable agile and DevOps blog posts of 2015?

Posted in agile, DevOps | Leave a comment

Scaling Agile Across the Enterprise: An Interview with Kelley Blue Book

At Agile 2015, we had the opportunity to interview Stacy Lin, senior director of product intelligence at Kelley Blue Book, to find out how their organization is using VersionOne to successfully scale agile project management.

In the video below, Stacy talks about Kelley Blue Book’s positive relationship with VersionOne. As their agile needs have grown, VersionOne has been with them every step of the way.


  • Kelley Blue Book’s transition proved successful and now VersionOne is implemented across many Cox Automotive business units
  • VersionOne offers a single, common platform to manage and prioritize work
  • Kelley Blue Book benefited from flexibility to meet the needs of Scrum and Kanban teams
  • Cox Automotive now has the opportunity to build an agile community of knowledge within the organization


Kelley Blue Book, the only vehicle valuation and information source trusted and relied upon by both consumers and the automotive industry, started implementing agile in 2005. Initially, the teams began with sticky  notes to manage their backlog, stories and tasks. However, as the organization scaled agile in 2007, they realized they needed an online solution that could help them efficiently manage complex projects. Particularly when it came to reporting on the velocity and other metrics, they needed an alternative to the manual effort of entering data into Excel and SharePoint.


After an extensive evaluation of several agile lifecycle management solutions, Kelley Blue Book selected VersionOne because of its usability. They had a pilot for eight weeks with two teams – one on-shore and one off-shore. The teams not only found the solution easy to use, but they also increased productivity.  As a result, the management team decided to roll VersionOne out to all of Kelley Blue Book.  Since then, VersionOne has scaled with Kelley Blue Book’s agile adoption and now has more than 250 users on the platform. The use of VersionOne has been so successful, that the solution been implemented in many of the business units throughout Cox Automotive, Kelley Blue Book’s parent company.


According to Stacy, “Kelley Blue Book and VersionOne have been very good partners for more than eight years. As agile adoption in the software development industry has grown, VersionOne  has continued to add new functionality to support the needs of enterprises that are scaling Agile. VersionOne has been a great support in our Agile journey.”

Now Kelley Blue Book and the other Cox Automotive business units have a common platform and a consistent language to easily manage their Agile initiatives. For example, when it comes to managing its top-rated website (, an extremely large and complex website, the product managers and Scrum teams have the platform to efficiently manage their work at all levels. In addition, the Portfolio Kanban Board in VersionOne provides one clear view of where all the epics and portfolio items are in flight, so the leadership can see progress at-a-glance and make sure that teams are aligned with business priorities.

While the organization’s agile transformation started with just Scrum teams, over time there were teams that preferred Kanban. The inherent flexibility with VersionOne allows teams to use different methodologies and still provide an integrated view of all  agile initiatives in one platform.

Now that VersionOne has been implemented across Cox Automotive, the organization can share and start to build a community of knowledge. For instance, at the annual Cox Automotive Agile Open, all of the business units get together to talk about their agile practices and learn from each other.

Please visit VersionOne’s YouTube page for more video interviews.


Posted in Agile Project Management | Leave a comment

4X Faster Time to Market: An Interview with Autotrader

4X Faster Time to Market: An Interview with Autotrader

We recently had the opportunity to interview Nick Park, director of experience delivery, and Sherolyn Sellers, manager, process delivery at Autotrader, to find out how their organization is using VersionOne to successfully scale agile.

In the video below, Park talks about how the structure and flexibility of the VersionOne Enterprise Agile Platform is helping teams produce great working software significantly faster.


  • Time-to-market four times faster
  • Visibility into key performance metrics to ensure business alignment
  • Flexibility to support different methodologies – Scrum, Kanban and SAFe
  • Easy to adopt and implement
  • Excellent support


Autotrader, a leading online resource for car shoppers and sellers, is part of Cox Automotive. The entire organization was committed to the idea of agile at scale from the start, so instead of just focusing on agile as a technology team transformation, they looked at the positive impact that agile could have across all the disciplines within the company.


Autotrader started their agile implementation with a small pilot program with cross-functional team. The team decided to use VersionOne to give them a structure to get started with agile processes and their transformation.

After the initial pilot, other teams started asking to get into the system, so the organization selected VersionOne because of its ease-of-use, simple implementation and excellent support. It was very important to get team members up and running with the system quickly.

Autotrader took a planned approach to their implementation to make sure that they were setting up the structures of the actual work, matching it to all the portfolios, and adding team members as it made sense. The progress of adding new users has climbed steadily as they have added teams, and now they have more than 200 users on VersionOne.


With the kick start from working with VersionOne, Autotrader has seen immediate results. The teams were using VersionOne to establish their agile processes and make changes to adapt to their business along the way. After three months, the teams were building momentum and producing working software.

In fact, Autotrader is introducing new releases at least four times faster than before implementing VersionOne now that they have the structure, processes and the visibility to more efficiently manage the work. In addition, defects are decreasing and product quality is increasing because of the level of detail that the teams can capture in the solution.

Stakeholder satisfaction is extremely positive now that the organization has the visibility to manage team velocity, project burndown, and other key performance metrics to make sure they are on track with the goals of the business. Now executives have easy access to the data they need to see progress and make more informed decisions on the prioritization and sequencing of projects. In addition, since Autotrader is part of Cox Automotive, they are adding new procedures and processes so they can start to visualize how projects are aligning with the corporation’s strategic view.

As Autotrader has grown, the fact that they have been using VersionOne since the beginning has allowed them to scale agile without that ever being a concern. Currently the organization has more than 20 Scrum teams and is managing projects at multiple tiers. Autotrader managers are able to use the epic board to see how work is flowing through the system, understand how expectations are being met, and identify any roadblocks or dependencies that need to be resolved. VersionOne has become a critically important system of record.

It has also been important that the inherent flexibility in the VersionOne platform was able to support different roles and methodologies. Autotrader has Scrum and Kanban teams and they are also using the Scaled Agile Framework® (SAFe®). Even though the teams leverage VersionOne in different ways, they have a common platform for overall reporting to make sure there is alignment with the portfolio and initial investments from their leadership.  In addition, the ScrumMasters and Kanban leads have the platform to start building their own community of practice.

According to Sellers, “Hands down, the teams love VersionOne. I have implemented several solutions throughout my career and this is one of the easiest for the users to adopt and use right away. In addition, the support has been great. There’s not a single time that I felt like I was ‘on an island’ and couldn’t get answers to our questions in a very timely manner.”

Please visit VersionOne’s YouTube page for more video interviews.

Posted in Agile Project Management | Leave a comment

Faster Time to Market: An Interview with Cerner

At Agile 2015, we had the opportunity to interview Matt Anderson, director, Cerner Technology Services, to find out how their organization is using VersionOne to accelerate speed to market and increase throughput to stay competitive in a rapidly changing industry.

In the video below, Matt talks about the organization’s partnership with VersionOne has helped them align its people, processes and technology to realize significant results from agile over the past seven years.


  • Time to market reduced by 75%
  • Productivity increased by 24%
  • Development costs reduced by 14%
  • Turnaround time for resolving critical defects reduced by 50%


In 2009, it was typically taking Cerner’s development teams about 30 months – from concept to client adoption – to introduce major innovations. Cerner knew it had to accelerate its products’ time to market to help clients navigate health care reform and to stay competitive in the rapidly changing industry.

To achieve this, Cerner’s developers needed more agility in their software development processes. The solution was the adoption of agile practices across the enterprise. Matt Anderson, director, Cerner Technology Services and Cerner’s leading agile champion, calls the company’s approach “pragmatic agile.” In other words, the enterprise focuses on ensuring that agile principles and values are followed and the teams decide the agile approach they will take.

Successful organizational change must simultaneously incorporate people, process and tools. While Cerner had a great team who was committed to agile processes, they needed an enterprise agile application lifecycle management (agile ALM) platform that would enable the people and processes to succeed. After reviewing several options, they selected VersionOne as their primary tooling partner.


Cerner has more than 3,000 developers, with teams having different needs, different markets, and different preferences in the way they work. Scrum works best for most of their teams, while other teams prefer Kanban, XP, Lean or other variations.

The company selected the VersionOne agile ALM platform because it had the flexibility to accommodate the various agile methodologies being implemented. In addition, they found the platform intuitive and easy to use. “People can focus on doing the real work of software development,” explains Anderson.


For Cerner, success was about having more time to focus on adopting the agile framework rather than adopting a tool. The VersionOne platform’s inherent ease of adoption enabled Cerner to quickly start seeing the benefits of agile – in this case, a 75% reduction in time to market. Other measurable improvements include:

  • Productivity increased by 24%
  • Development costs reduced by 14%
  • Quality improved by 6% based on internal KPIs
  • Turnaround time for resolving critical defects reduced by 50%

In addition, by choosing VersionOne, Cerner development teams can estimate software delivery more accurately, allowing them to forecast and consistently meet their commitments to stakeholders. Developers can identify problems earlier and make midstream adjustments very quickly. And teams can innovate and test prototypes because VersionOne is adaptable enough to support changes to the underlying process.

The flexibility of the VersionOne ALM platform promotes a proactive approach to problem solving across the enterprise. Instead of reacting to issues, Cerner can develop solutions that prevent issues from arising. The flexibility also allows teams to try different things. If the experiment works, Cerner teams incorporate it as a part of their process. If the experiment doesn’t work, they just throw it out and try something else. As Anderson says, “That’s the true spirit of retrospectives.”

Another key benefit of VersionOne is the ease of creating roll-up reports with the ability to drill down from big picture into what teams are doing. With VersionOne, Cerner’s leadership can get a one click view of a release at any point in time. They no longer needed to deal with project management via spreadsheets or Visio, which often contained outdated information and rarely provided the needed level of detail.

“VersionOne is a great partner,” said Anderson. “The company continues to innovate to meet the needs of the agile marketplace. They are justifiably one of the top agile ALM vendors.”

Please visit VersionOne’s YouTube page for more video interviews.

Posted in Agile Project Management | Leave a comment

Happy Holidays from the VersionOne Team!

Happy Holidays from everyone at VersionOne! We hope your holidays will be filled with joy and laughter through the New Year. We’re so grateful for our amazing customers, partners, and friends in the growing agile community.  So we wanted to share our seasons’ greetings in a video featuring the people that power VersionOne. Have fun watching and let us know what you think!

Posted in agile | 8 Comments