Scaling Agility Without Killing Agility

Scaling Agility Arlen Blog

Frameworks for scaling agile methods have exploded in variety and popularity over the past few years: Scaled Agile Framework® (SAFe®), LeSS, and DAD are a few prominent examples. A common facet of these methods is the delineation of Portfolio, Program, and Team layers, with the idea of allowing goals at the executive level to be effectively communicated and driven through groups of teams.

The growth of scaling patterns has had significant effects, notably driving adoption and interest in areas where agile methods have historically encountered skepticism, such as government agencies and some large organizations. But not all is peaches and cream, as companies like mine which have helped organizations employ these methods have seen time and again. Based on these experiences, I offer the following guidelines for those considering the adoption of agile scaling frameworks.

  1. Get the team right first. Fundamental to all agile methods is the idea of autonomy at lower levels, such as a team in Scrum/XP, or a group of aligned individuals in Kanban. The ownership that this drives keeps teams more engaged and interested, while also speeding the process of evaluating and executing decisions. Our coaches have often noticed that introducing hierarchies early on can dramatically impede the ability of teams to decide, flex, and adapt to local circumstances, hence limiting the organization’s overall agility. Ensure that teams are able to make decisions and deliver locally before linking them in large hierarchies.
  2. Keep hierarchies as flat as possible. Layers of approvals slow decisionmaking, which hampers organizational agility. They also tend to slow delivery, and limit local innovation.  However, it is often the case that scaling methods are introduced largely with the idea of limiting organizational disruption, and hence they can provide an excuse for avoiding deeper (and often needed) organizational redesign. Consider how you might break an organization into smaller autonomous units before introducing multi-layered hierarchical planning processes.
  3. Pay attention to infrastructure and tooling. While perhaps the majority of agility focuses on the human element, the technology that underlies the process is just as critical when dealing with software delivery. The recent DevOps movement echoes the early agile method Extreme Programming by emphasizing the critical need to automate basic delivery capabilities through techniques like continuous integration, test driven development, and build automation, to the greater end of dissolving dependent silos. Absent this sophistication, teams find themselves still dependent on one another and external testing/release groups, once again defeating the local speed and flexibility that define agility. Scaling before addressing tooling can hurt organizations by allowing them to retain lengthy release cycles and dependent specialized teams, whereas short time boxes force better delivery capabilities.
  4. Release often to learn. Patterns like SAFe’s Agile Release Train can have some great effects by aligning historically separatist business-oriented silos such as Sales, Marketing, and Finance with their technology partners in Development and Operations. However, release cycles often end up settling on one-three month cycles. While there is nothing inherently wrong with this, it is of course possible (and often desirable) in many environments to deliver much more rapidly than that.There are two core purposes for releasing software in agile methods: to learn and to profit.  These must be considered separately. Constrained availability releases are generally meant to drive feedback at scale, like giving software to a field testing group or doing gradual rollout of new functionality through live A/B testing. This helps us understand what features are used most often, where glitches occur and so forth, and hence drive subsequent planning cycles. These should happen very frequently, on the order of days and weeks, and should not be constrained by higher-level planning cycles.Typically we have a higher bar for full-scale production release, which can also be driven or constrained by customer demand cycles. This can happen less often, as seems appropriate based upon market and customer cycles, but should not hamstring the ability to do small, quick releases for the purpose of learning.
  5. Ensure that information flows up, not just down. Building on the point above, much of the reason why agile methods encourage rapid releases is to ensure smarter, more empirical data-based planning, as opposed to the typical “guess what the customer wants then build it for months” approach we’ve seen historically. However, this requires that information garnered from user testing is rapidly received, understood and acted upon. In general, hierarchies dampen or eliminate the ability for such granular information to travel back up the chain and influence decision-makers.Some of my best agile business stories came from projects that were canceled or dramatically altered based upon information that was unavailable during initial planning, but that rapidly became available as ground truth became apparent from user and system behavior in the wild. If this information had been suppressed in the interest of avoiding disruption of some higher order, millions would have been lost in building the wrong thing. This isn’t an impossible problem to solve, but it requires curiosity and flexibility at higher organizational levels, and a clear strategy for ensuring that team-level data is considered properly during planning cycles.

Agile scaling methods have clearly filled a demand void, and they have introduced many tools and patterns that have been observed to work in certain environments. However, not every company or situation is the same, and hence no one method is likely to work the same way for everyone. One must remember that such methods are essentially toolboxes, so understand your goals before picking your tools, and keep in mind that true agility will never be so simple as adopting a methodology.

Lithespeed is a VersionOne premier partner. You can learn more about Arlen Bankston at


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

2015 Spirit of VersionOne Award


Mark Schultz in front of the Spirit of VersionOne award winners wall of fame.

Mark Schultz in front of the Spirit of VersionOne award winners wall of fame.

Each year the VersionOne team nominates employees for the annual Spirit of VersionOne award to recognize an individual who best represents the core values of VersionOne. This year we are sincerely honored to announce that Mark Schultz is the Spirit of VersionOne award winner.

Based on nominations from fellow employees, Mark exemplifies the culture and spirit of VersionOne. He is respectful, honest, authentic, and truly cares for the success of his team, colleagues, and customers. Many of the nominations also referenced Mark as the ultimate servant leader, who is constantly looking for ways to use his experience to help others succeed. The only attribute that exceeds his work ethic is his passion for the success of the company and its employees.

Since he first joined the company more than five years ago, he has consistently gone above and beyond to be available to others whenever needed. His positive attitude is extremely infectious. And while years of success have provided Mark with a wealth of experience to share, he remains incredibly humble and willing to learn from the experiences of others.

In a world of many managers, Mark is a true leader that inspires many on a daily basis. Trust, humility, and integrity are some of the qualities that great leaders possess and all of which you will find in Mark. It is rare to find one individual who has this combination of personal and professional integrity at such a high level. Thank you, Mark for your unselfish commitment to VersionOne!

Posted in agile, Agile Powered By People, Agile Software Development, VersionOne | Leave a comment

Shiny Objects and SAFe


R300x250-View-Nowecently, while I was teaching new teams on how Scrum fits in a larger Scaled Agile Framework® (SAFe®) structure, the question kept coming up from a product owner. “Yes, all this new Scrum stuff is great, BUT how do I juggle multiple requests from multiple stakeholders?” “My customers keep asking for more and more without taking anything off the plate.” I often refer to this as stakeholders chasing “the next shiny object.” Or, I want it all and I want it now.

Our business customers often fall into this mode due to the delivery nature of the waterfall projects we have been running for 40 years, where we deliver late, we do not deliver all they want, and it is not the best quality. As a result, I think they ask for everything they think they might need, which results in some of the difficulties of delivering what they REALLY need.

So the answer led me to explain how not only the Scrum teams deliver work, but how each of the teams is part of a larger ecosystem of project, program, and portfolio control that helps define work and priorities from original stakeholder requests to the work dispatched to the individual team members.

Walking the team through the SAFe Big Picture was exciting, and I’m not sure everyone took it all in a short time, but the questions kept coming: “Where do we fit in?” “What happens if I get buttonholed in the hallway and asked to do something by one of my customers, do I promise to deliver what they want?” and (well, you get the idea), new practices, new ways of acting and reacting to old situations. As team members they were afraid to tell a customer “No, we cannot do that”, or “I don’t know we have the staff to cover that request.”

In a recent engagement, the CIO never refused a request. We needed a way to corral her “Can’t say no” responses with SAFe. And we did. I’ll explain further a little later. The end result of these problems is a book of work that continues to expand, priorities that are not met, pet projects that take precedence and generally, queued work that gets out of balance with priority requests.

SAFe has some of the answers. We need to look at adding a strong helping of simple discipline and rigor following the SAFe principles and practices. But in my opinion, SAFe adoption alone is not enough – you need the Circle of Life in an IT shop: People, Practices, and Tools. All three combined are a recipe for success.

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

People – SAFe does give us governance structures, roles that staff needs to play, and definitions of how they interact. This is highly valuable as it gives substance to the various roles in SAFe, while being flexible enough to add or revise, as needed. After all, it is a framework.

Process – With the introduction of Scrum and Product Owners, all the Inspect and Adapt cycles, potential added capabilities with Portfolio management to direct traffic, the picture looks a lot better from the standpoint of someone driving and managing those priorities. Now we actually have a framework to customize and make “our own” to manage a book of work for a medium to large shop (say 500 – 10,000 staff). New versions of “Essential SAFe” are available for smaller shops as well.

Tools – They give us the necessary discipline and rigor to carry through with the often complex dance of delivering systems and features to production. We need a single global collection point as a repository of the work to be delivered, a means of dispatching the work to various teams, a collection of metrics to report our current state, past efforts, future capabilities, compliance with practices, and so on. Tools provide us with the ability to do this. Strengthening the back-end delivery through DevOps is also a great capability to deliver.

Still, Stakeholders of Systems Want LOTS of Features

So, our business customers are still going to come at us from many different directions with a ton of Features, which can often be identified as “the next shiny object.”

What work may already be in stream or in construction can get impacted as the “next shiny object” can now be added to the list.

Shiny objects occur with amazing regularity as a result of:

  • A competitor introduces a new function – keeping up with the Joneses.
  • A stakeholder gets impatient for the delivery of a feature and becomes focused on that current shiny object.
  • A simple request in an email, which you mistakenly agree to do, goes from being a small paper airplane to a B-2 stealth bomber-sized project or program.

The results of stakeholders repeatedly chasing shiny objects tends to distract teams from delivery. Stakeholders can change their minds about what is important based on what is happening in the business world – which is often disconnected from our IT delivery world.

Unless we have a strong commitment to the SAFe processes and practices, we are unlikely to actually combat the shiny object syndrome.

SAFe practices corral, organize, prioritize, and deliver whole categories of shiny objects based on the needs and priorities of the stakeholders. At the portfolio level:

  • We corral, organize and prioritize (and even set the value of) shiny objects.
  • We use Kanban capabilities to organize and prioritize objects.
  • We use Value Streams to align work and fund the work (unfunded work like those B-2 stealth projects die at this point).
  • We make strategic level decisions for the good of the enterprise.

Remember that errant CIO who promised everyone who asked whatever they asked for? We gave her a sheet that became an input form to the portfolio screening process.

So what happens when that commitment starts to backslide or fail? How can we make sure a complex system of systems like this keeps on working?

SAFe is based upon a set of key Lean and Agile principles:

List of 9

Also of critical importance are the core values of SAFe:

ImageFor organizations to effectively implement SAFe, we also need a significant amount of individual and team based capabilities of rigor and discipline. In addition, we need some mechanism to keep us on track, and monitor speed, delivery, quality, and compliance, plus deliveries in a priority cadence that is driven by the stakeholders. Rigor and discipline of this type can come in the form of using an enterprise agile lifecycle platform (such as VersionOne) as a key to providing:

  1. Planning capabilities at various levels for various roles
  2. Metrics gathering and reporting
  3. Quick methods of prioritizing
  4. Globally distributed capabilities of defining and managing work

In my own experience working with large and globally distributed organizations, performing SAFe planning and execution, and utilizing technology with enterprise-wide capabilities of the caliber of VersionOne, provides them with the rigor and discipline to successfully be SAFe.

You can contact Tom Weinberger at

Graphics reproduced with permission from © 2011-2016 Scaled Agile, Inc.  All rights reserved.

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

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

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