Transformation of Visma Commerce R&D towards Scaled Agile Framework for Commerical Software Development Products


Scaled Agile Framework or “SAFe” is one of the leading frameworks to address enterprise agility, i.e. product development that involves several development teams with dependencies between each other’s deliverables/code and where each program initiative needs to be in synch with the overarching business initiatives. SAFe has rapidly gained in popularity in “product oriented” software organizations around the world using traditional agile methods like SCRUM/Kanban (SCRUM Ban), where the real challenge lies in see the “Overall View & Status” at the various levels in the organization in unified unambiguous way. SAFe has a website  and through their partner program they offer certified trainings for business, product & software development stakeholders on how to lead and implement & execute SAFe in an organization, this mean agility not only for development teams, but also Product management, DevOps, System Test teams and executives. This is in my view the first serious attempted framework to address “Portfolio”, “Program” & “Team” levels in 1 collective framework with best practices on “HOW” to do it.


For some years now agile processes has increased in popularity among development teams at the same time as most Project Management Offices (PMO) and executives often experience an increased frustration in the limited possibility to gain a real “hands on understanding” on collective progress, quality & health state performance across a multiple set of development teams & across multiple program/project/functional initiatives (streams) which many times are interrelated. This is usually boils down to that the understanding, thinking, offset, expectations and measurements are not collectively aligned by all parties. SAFe is an attempt to address this, where transparency by appropriate tooling, Bottom up planning that dictates how much work we can do in a given time slot, with basic production flow principles as guiding principles and agile adoption at organizational level, especially in budgeting & resource allocation are key areas to cover for all stakeholders.

From the agile development community, which (if we are going to be candid here) in many cases has used the agile process as leverage for a power shift from traditional project management (“Top Down” setups) revolting in repeated upfront over allocation of workload and expectations of what they can accomplish without having a say, now the “post-agile” movement is gaining terrain, where new insightfulness on the development teams behalf also appreciates that some coordination and follow up is indeed needed, without making trade off  on the “artistic freedom” that each developer nurse so dearly and should be respected.

On Management/Executive Level

A summary on this “Portfolio” level as it is labeled in SAFe is revised thinking around cost account budgeting, frequency of value stream budgeting for ongoing business initiatives, light weighted (agile) business cases, Work in Process limits (WIP Pools) for how many business initiatives that can realistically be in motion Before the throughput in the organization goes down, so agile principles and production flow principles are very much applicable to this audience indeed. There is no HIP factor in kicking off yet another business initiative if we don’t have bandwidth to deliver it in competition with other ongoing initiatives, the overall throughput goes down.

For the Development Teams

Development teams needs to appreciate the funders gets pretty uneasy and sooner or later “pulls the handbrake” if we are not transparent in what we are doing and can demonstrate a “tangible collective view” on progress, quality & health status for all teams involved, fully visible based on an infrastructure that enable this view automatically, typically dashboard views on Portfolio/agile planning tooling made available for all stakeholders to follow or Project “on screen” in real time.

Briefly put to use an analogy within research “It doesn’t matter how good of a researchers we are, if we don’t have research money to fund us and we can’t demonstrate how we add value with them, we will not be able to get continuous trust and hence no funding”. So in conclusion we need to be as open and transparent as we can with what we are doing and if possible demonstrated small steady repeatable improvements against the agreed business goal for all teams within an initiative. But the transparency goes both ways, in the same fashion Product management’s ability to complete Roadmaps & Feature backlogs prior to co-planning essential for success, as is executive ability to “as the right set of questions and drive the right set of behaviors” which comes with understanding Enterprise agility and production flow principles.


The Implemenation of SAFe @Visma Commerce

Anders Lundell, Head of Development at Visma Commerce states

“We need to take a new approach and how we view products, releases & team efforts and initiated a “change program” to implement SAFe at all levels in the Enterprise. We started this change process together with a Certified Scaled Agile Framework Consultant (SPC) – Lars Brodén from LB Consulting Group that also served as a trainer & agile coach & agile tool mentor, in our case Jira Agile”

  1. All people within R&D, Product Management & targeted executives went through a 2-days training in “Leading SAFe” with the ultimate goal of understand and appreciate the foundation of the framework, primarily, joint program agile planning, production flow principles and portfolio management
  2. Product Management plans & conduct budgeting in an agile manner and applies “Lean principles” for defining and nourishing large functional building blocks, i.e. “Features”, define them in a dedicated feature backlog and takes these features through proper pre-development phases for further qualification based on lean business rules for priority (Weight the Shortest Job First) in order to have a ranked feature backlog in place prior to joint “release planning”
  3. All teams including Product management “Bottom up” plans 1 quarter ahead and set business objectives collectively for this quarter, breaks down features into smaller more vertical functional slices (i.e. User Stories), roughly estimates in story points and map these deliverables into 5-6 sprints each lasting 2 weeks each
  4. The whole initiative (all teams included) are involved in what are called an “Inspect & Adapt” exercise, where a System Demo is conducted, walkthrough of “Objectives met” precision for the quarter, defect trends, Business value metrics and productivity metrics for all teams collectively.

The very fact that we start and stop at the same time, i.e. cadence & synchronization is set between all teams, estimate in the same way, use the same cadence for sprints and evaluates in the same way with the same agenda at the same time face to face makes it possible for us to also get an objective view of how we have done for the past 12 weeks for the entire initiative fully transparent to executive levels. Cost & time are treated as “fixed parameters”, cost can then easily by projected/calculated given the fixed cadence for all teams and the fact the team structures are kept relatively stable over time.

In order to launch this model, with the help of our SAFe Consultant, we prepared an implementation plan that contained the following elements

  • Prepared configurations in infrastructure required in Jira Agile for joint SAFe program planning
  • Migration & configuration of required repositories & systems to accommodate “On Demand” build cycles
  • Initiation of auto test code/scripts for stories developed, applied on both unit level and functional, API (Module tests) & acceptance test levels
  • Training of all stakeholders in a 2 days “Leading SAFe” course – To get an understanding & appreciation of all levels in the value chain from business initiative to code and vice versa.
  • Common “SAFe Program Increment” planning, “Inspect & Adapt” sessions and SAFe coaching on the entire planning and execution of multiple Program Increments
  • Establishment, Execution & follow up on Enterprise Agile metrics to measure productivity, Goal fulfillment & Product quality
  • Establishment of comprehensive “system demos”, to demo large functional building blocks (Features, not only stories)
  • Same view on Estimation, Velocity, Load & follow up for teams, Program management & executive levels
  • Establishment of “Program Level” service teams to accommodate development, i.e., DevOpS, System Test, Release Management

Concrete benefits and paybacks we can see after running this program for 1 year now are;

  • Drives a behavior within product management to prepare product & feature roadmaps with a longer horizon than before and set expectations with external stakeholders better as a result
  • Product management & surrounding stakeholders are pushed in a direction to apply lean principles to rank a feature backlog, as a result focus on what is essential for now and have a “Quick realization value” for our customers. (The people who shout the loudest or has the best “sales”, does no longer get their will through automatically, there is a documented method on how and why we rank things in a certain way, a process which they are a part of.
  • Less parallel activities & context switching in the development teams as a result, which results in quicker throughput in the deliverables which are really important in time
  • Optimal breakdown of large building blocks (SAFe Features) by the development teams which also results in quicker throughput and less risk factors in sprint deliveries
  • More frequent (but smaller) releases of incremental values to customers – The marketing departments which before was one step ahead now have a hard time to keep up marketing all features that incrementally is released.
  • Already at day 2 into our quarterly plan, development teams can answer the question (Based on their bottom up planning) with confidence if expected scope is realistic within the given time window as a result, expectations can be set with customers earlier in the cycle than Before
  • Load balancing is addressed throughout the sprints for each development team, in what “MUST” be done and what “SHOULD” be done by setting objectives for the entire release with adequate business value
  • All levels in the enterprise uses the same “currency” for estimation and estimation is done in the same way, i.e. relative sizing of building blocks expressed in “Story Points/Ideal Developer days”, the Estimates are then “rolled up” to features and ultimately business initiatives, making a “size baseline” for the future for a certain type of business initiative
  • A normalization model is adopted between development teams for how much work that can be taken on for a sprint or a program increment. (Over allocation slows down progress)
  • Work in Progress (WIP) pools are established for both development teams, Product management & Portfolio management levels to ensure optimal flow of development
  • Dependent deliverables between teams are mapped out and illustrated on Dashboards in Jira from day 1 in the planning cycle, this accelerates the resolution actions and fixes for each dependency


We believe (apart from the Concrete values in the ongoing programs) that Visma Commerce as an organization benefits from this and added values we can see are;

  • More attractive employer that works & adopts modern methods, frameworks & technologies
  • We are starting to get in Control of our Destiny in terms of understanding “value in relation to cost”
  • We are starting to build a reliable metrics bank, that we can draw conclusions from for a single Product, between releases and work proactively to adjust if needed
  • Management in the organization are also obliged to be transparent and do their “homework” in order for the initiative to become successful – Transparency goes 2 ways – from team to management and management to teams, a trust is established
  • Partly a new thinking on “scope management & planning” starts to sink in for all associated stakeholders in the organization. A bottom up approach for planning and recalibration of scope based on insights from this is now fully transparent & accepted.
  • Productivity within the development teams has increased since they work against a more concrete expressed “Objectives” views which they themselves has been part of expressing in Corporation with Product management. As a result detailed task management is abandoned for the benefit of delivery/release against a clear set of objectives which everyone subscribes to, and is measured and followed up continuously
  • Marketing departments is starting to “shadow” R&D in order to make it for the nowadays more frequent releases/news to the Product.
  • We can more precise predict how many business initiatives we can run in parallel without slowing down the overall capacity to deliver optimal scope in a given time window

We are now aiming to take SAFe to the next level and optimize certain parts of SAFe for application with the pre-requisites that are unique for our organization, but the feel so far is that we are really going in the right direction in terms of continuous value deliveries, predictive release dates, and quality assurance of code & system functions.

Visma Commerce 2015-11-25

Anders Lundell                                                                                   Lars Brodén

Head of Development, Visma Commerce                                     SAFe – Certified Program Consultant