VersionOne has announced its Winter 2016 release which includes support for Scaled Agile Framework° (SAFe®) 4.0 along with more features which support both strategic and team level use of the product.
InfoQ spoke to Lee Cunningham (Director, Enterprise Agile) and Mark Crowe (Director of Product Management) about the release and why the changes in SAFe 4.0 are considered to be so significant.
The conversation focused first on the new aspects of SAFe 4.0 and how VersionOne sees the framework in the marketplace.
Cunningham said that the most obvious change is the addition of the optional Value Stream level, which is really just a natural extension to what was already in the model. Along with that new level comes a new artifact in the SAFe framework called the Capability, which he described loosely as a “supersized feature”. The budgeting structure and flow have been streamlined as well, providing better guidance on how to allocate budgets to multiple value streams .
He stated that the most significant change at the team level is the integration of both iterative development teams and Kanban teams working within the same program.
In response to the question “What organisations is SAFe aimed at?” Cunningham responded
It’s aimed at organisations who want to take the team-level benefits of Agile and extend them into larger, more complex environments. The expectation with Scrum is that every sprint should produce a potentially shippable increment of customer value, but the reality with large organisations is that this is not always the case. In many such organizations, it’s an aggregation of stories from multiple streams of work that come together to produce an increment of customer value. This is the area where SAFe has resonated – it has provided a framework which fits with the reality of large organisations building complex products.
Three-level SAFe was targeted at organisations that have a lot of people working together on a single program. Four-level SAFe is designed for larger organisations that are coordinating and aggregating the work of multiple programs into a single solution. An example of such an organization is a defence contractor that may be building not just software, but large systems consisting of multiple components and multiple technologies, even cyber-physical systems such as satellites, aircraft, and battleships.
He explained how a very large VersionOne client had worked with the SAFe designers to devise a ‘release train of release trains” which had a significant influence on what SAFe looks like now.
He was then asked “When does SAFe become overkill?” which elicited the following response:
You need to examine the complexity of the work being done and the number of people needed to deliver value to your customer, and if what you are currently doing is working. If you have three or four teams working on a single product, you’re going to need synchronization and you’re going to need to optimize around the system you’re building, but you probably don’t need SAFe. If you are trying to coordinate many teams, though, across various streams of value, then it makes sense to explore a framework such as SAFe.
We have seen some organizations gravitate toward SAFe simply because of the structure that it provides. Those organizations weren’t necessarily dealing with an inordinate amount of complexity or hordes of people – they just needed something to help provide discipline and alignment. So although in many of those cases, I’d have said that SAFe was too much to bite off, it turned out that they needed the kind of detailed guidance that SAFe provides.
Given this clear understanding that SAFe fits best in the large, complex environment how come it seems to consistently be offered as a panacea for any agile adoption, irrespective of the nature of the organisation?
SAFe articulates a clear way to achieve success with agile at scale, and the SAFe “big picture” poster provides a nice visual representation of how all the pieces of the framework fit together. I see this poster at organisations I visit, irrespective if they actually use SAFe or not. Dean Leffingwell recognised that for agile to be accepted in large organisations, you need to be able to paint a vivid picture, and he’s done that very well. SAFe isn’t the only approach to scaling agile out there, but it’s certainly the one everybody asks about first.
I do see a pendulum swing happening lately and SAFe is no longer viewed as the silver-bullet to all scaled agile challenges. Initially there were some organisations that perceived SAFe as a way of continuing to work in their traditional, hierarchical way by simply changing some of their terminology, and that created disappointment and problems. This is no longer as frequently the case. Most folks in the agile world have a couple of years of SAFe familiarity under their belts at this point, and realise that it’s just a framework, and as such, it’s a tool. It also helps that SAFe’s adoption entails lean-agile leadership training early on. This helps ensure that executives and leaders understand how important the core agile practices and disciplines are, and how important leadership transformation is.
Mark Crowe pointed out that one of the key aspects of the SAFe framework that makes a big difference to many organisations is the discipline of the frequent sync points – planning in the 10-12 week cycles and collaborating across multiple teams to align the work being done. This goes beyond scrum-of-scrums and brings the benefits of an iterative cadence into the higher levels in the organisation, which brings predictability and regularity to value realisation. SAFe brings ideas from many places together into a packaged framework and makes it easy for organisations to adopt them without needing to look in many different places.
The conversation then explored what is in the new release of the VersionOne product.
Continuing the conversation with Mark Crowe, he explained the new features in the January 2016 release of the VersionOne product.
There are features aimed at both the team level and at the strategic level use of the product.
At the enterprise level there are new dashboards in the analytics product, adding a new level of reporting to identify metrics across the whole organisation which will indicate improvement in the outcomes from agile adoption. Metrics that are simple enough to understand and which give an indication of enterprise-level throughput, quality and predictability. What is happening across the organisation in terms of sustaining and improving outcomes in these areas?
These metrics include:
- Throughput at the portfolio level – the rate of delivery features, epics, initiatives. Similar to team-level velocity the key is to understand consistency vs. spikes/valleys in the flow, are there bottlenecks, are we improving or degrading?
- Predictability at that same level – how consistent is the organisation-level throughput? A good planning process with clear understanding of the available capacity across the organisation should result in a predictable rate of delivery.
At the team level some additional features have been added. These include:
- Explicit TeamRoom support for Kanban processes. TeamRooms enable teams to focus on their specific work and document their practices, approaches and metrics, either from the corporate standard/guidelines or by updating the information based on their own specific context. This now includes specific Kanban metrics for teams who work in that way.
- Metrics from both Kanban and iteration-based teams gets combined at the higher levels and the consolidated view of throughput is not determined by how the individual teams operate, release level burn-downs and team-level autonomy to select their preferred way of operating.
- Timesheet or effort reporting is something that many organisations need, for accounting, capex/opex reporting or perhaps for billing purposes. The timesheet view allows teams to record information as they currently do and in a weekly timesheet view.
- CommitStream is a cloud-based service which integrates with source control and deployment systems such as GIT and link the commits to the work in a TeamRoom or down to the individual Story level, with simple setup and configuration.
Beyond the current release there is a new Continuum™ for DevOps product which came out of the acquisition of ClearCode Labs, extending the visibility and management of work all the way from idea, conception and strategy to delivery (product owner signoff) and now on to the build in staging and production environments, automating many of the steps in the deployment pipeline and keeping track of the status of all the work items which feed into a build release. It links the stories and features to the build version, and maintains traceability as builds are deployed.
