Blog

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).

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.

In this short blog Ian Spence looks at how many Features a SAFe® Agile Release Train needs to prepare to be ready for their PI (Program Increment) / big room planning event.

I was recently asked to help facilitate and to act as coach at a multi-day kick-off event for a new Agile Release Train (ART). The agenda initially looked a lot like that of the SAFe Program Increment (PI) Planning event, but there were immediate differences, the main one being a restricted attendee list due to ongoing team recruitment. The people in the room consisted largely of the SAFe Program level: Release Train Engineer (RTE), Product Management, Product Owner, Architecture, and a few Subject Matter Experts...

Key to realizing benefits from agile is strong customer representation through empowered Product Ownership – to guide the team in delivering a solution that maximizes end-user value. But this is also often the hardest agile practice to get working effectively, because of its novelty for many stepping into the role, and because of the challenges in balancing time commitments with existing business responsibilities, and combining incisive decision-making with broad-based stakeholder representation and negotiation. Download the infographic and post it on your wall as a daily reminder of what's needed or better yet, download our Product Ownership Health Check Guide.

We must work as a team! Teamwork is critical! There’s no ‘I’ in team! These mantras are plentiful and many Agilists believe that success at the team level is the foundation to success at the organizational level. But what does it really mean to work as team and is there a common recipe to build and grow a successful agile team? Agile believes in principles before practices and in multi-disciplined, self-organizing teams. All teams need direction and guidance, but with an agile approach no one should be telling the team how to do their job. Teams need to be empowered to make choices rather than be told exactly what to do. But sometimes things can start to unravel and too much time and energy can be wasted arguing about the basics. You can forget about scaling agile if your team is unable to clearly demonstrate the value of agile at the team level. But, get the basics right at the team level and engaged, highly motivated, cross-functional teams of teams can follow.

Since their inception some 30 years ago, use cases have been used to identify, organize, synthesize and clarify system requirements for organizations across the globe. In most recent years, they have been used in techniques such as user stories. Use-Case 2.0 is the new generation of use-case driven development – light, agile and lean – inspired by user stories, Scrum and Kanban. Although they are much more agile and lean, they still embody the same popular values from the past while expanding to architecture, design, test, user experience, and also instrumental in business modeling and software reuse. But, for the adoption of use cases to be seamless, there should be a balance of principles applied.

Change. This simple word has been used to create communities, build businesses, and promote adoption within a myriad of other actionable objectives. It is as common as the air we breathe and as revolutionary as any invention. Yet in all of its grandeur, it has incessantly stumped many businesses and individuals along the way. Software has taken a front seat in several organizations. It has become the core to any business, and change initiatives have sprouted and evolved to provide better solutions, be they faster, smarter or more affordable. Furthermore, for those organizations that adapt to change well and continue to sustain said changes and evolve over time, the rewards are exponential and in many cases, lasting. As new companies emerge in markets offering innovative solutions that can ultimately disrupt the market, those organization that cannot and or will not adapt and change, and perhaps more importantly, sustain change will lose. As a result, software development teams are adopting agile development techniques to shorten development times, decrease risk, all whilst developing solutions to become more responsive to the needs of the business.