Publications

The SAFe® principles are very powerful but our coaching and consulting experiences have shown that, as currently presented, they are far less accessible and intuitive than the Agile Manifesto and its supporting 12 Agile Principles. In line with the release of 5.0 of SAFe®, which simplifies and enhances the SAFe® big picture, we have produced a set of cards that we believe do the same for the underlying SAFe® Principles. The cards present the ten principles in a self-contained, readily accessible fashion — allowing executives, leaders, and team members to readily understand the principles and quickly assess their relevance. Download the cards today to help your teams be SAFe®. This blog post introduces the SAFe Principle Cards produced by Ian Spence (SAFe Fellow, SPCT) with help from Brian Kerr (SPC) and Brian Tucker (SAFe Fellow, SPCT).

The Industrial Internet Consortium predicts the IoT (Internet of Things) will become the third technological revolution after the Industrial Revolution and the Internet Revolution. Its impact across all industries and businesses can hardly be imagined. Existing software (business, telecom, aerospace, defense, etc.) is expected to be modified or redesigned, and a huge amount of new software, solving new problems, will have to be developed. As a consequence, the software industry should welcome new and better methods. This article makes the case that to be a major player in this space you will need a multitude of methods, not just a single one. Existing popular approaches such as Scrum and SAFe (Scaled Agile Framework) may be part of the future, but you will also need many new methods and practices—some of which aren’t even known today. Extending a single method to incorporate all that is needed would result in something that is way too big and unwieldy. Instead, the new OMG (Object Management Group) standard Essence can be used to describe modular practices that can be composed together to form a multitude of methods, not only to provide for all of today’s needs, but also to be prepared for whatever the future may bring.

Many organizations don’t realize they are in a method prison. It is easy to understand why not. They have not identified any problems because they haven’t seen how it could be different than today. The problems are too abstract without a solution to them. Once upon the time users didn’t know that software should be built using components, e.g. java beans. Similarly, they didn’t know they needed use cases or user stories to capture requirements. And so on. However, once they got it, and started to use it, they saw the value. Similarly, once they see that they can have access to a global library of practices, which are continuously improved, and from which they can select their own method, they won’t go back to what we have today.

In May 2017, agile leaders from the banking, insurance, telecom, technology and publishing sectors gathered with Ivar Jacobson International (IJI) at the Tower of London to discuss the important role executives, product managers and release trains engineers play in a successful agile transformation programme. With clients from Deutsche Bank, SimCorp and Mastercard participating in the panel discussions, guests heard first-hand what it really means to adopt, resource and carry out these roles in large, often quite traditional, internal software development organisations.

Many teams struggle to let go of their waterfall, silo mentality when they first transition to agile ways-of-working. In particular they shy away from collaboratively working on the definition, evolution and implementation of their backlog items insisting on up-front definition of Features and Stories, and clean handovers between the Product Owners and the Development Teams. This is an issue that we see with all the various agile methods but which always seems to get compounded whenever teams try to scale. In this short blog series we will look at how this tendency towards waterfall thinking can seriously hinder team’s adopting SAFe® and working with a Program Backlog full of Features. We will also provide some advice on how to get your Features Ready without succumbing to premature Story writing.

Many teams struggle to let go of their waterfall, silo mentality when they first transition to agile ways-of-working. In particular they shy away from collaboratively working on the definition, evolution and implementation of their backlog items insisting on up-front definition of Features and Stories, and clean handovers between the Product Owners and the Development Teams. This is an issue that we see with all the various agile methods but which always seems to get compounded whenever teams try to scale. So what are the worst things you can do to compromise the agility of your program when using Features? In Part 4 of this series, Ian Spence provides some practical tips to avoid waterfalling your features.

Many teams struggle to let go of their waterfall, silo mentality when they first transition to agile ways-of-working. In particular they shy away from collaboratively working on the definition, evolution and implementation of their backlog items insisting on up-front definition of Features and Stories, and clean handovers between the Product Owners and the Development Teams. This is an issue that we see with all the various agile methods but which always seems to get compounded whenever teams try to scale. So what are the worst things you can do to compromise the agility of your program when using Features? In Part 2 of this series, Ian Spence defines the seven deadly sins of feature preparation, and the most wasteful practices we have seen teams adopt in an attempt to be better prepared for the PI Planning event.

Better quality and better predictability of delivery The entire product division talking the same language using the same concepts More responsive delivery with the ability to demo features to clients as the teams are developing them

To be agile as teams, we need to adjust our approach to meet our immediate challenges and needs. To be agile as an organization, we need to learn collectively and evolve our approach over time to support our evolving mission, so that we continue to excel in an ever-changing environment. We would not call a TV set “adaptive” if, in order to adjust the volume, we had to throw it away and replace it with a model with a different volume setting. So why are we prepared to accept process frameworks that leave us in a similar predicament every time we want to improve our product development performance as an organization?

A simpler view of SAFe—Essential SAFe—was created to help even more teams to scale effectively. In this presentation Ian reviews: The basics of scaling — what do we mean by scaling and when is SAFe applicable Essential SAFe — what is it and how can it help How to be safe with SAFe — how and when to go beyond the essentials