Resources

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.

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.

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 modularized set of interchangeable practices that enable organizations to scale agile smoothly as part of a tailored transformation program that delivers value early and often, and builds a flexible and long-lasting library of practices, able to flex and grow over time in response to changing technology and business challenges.

The Agile Essentials practices provide a basic starter kit toolbox that covers all the common and critical aspects of team-based development. Each practice contains a small number of cards that provide useful, structured advice on how to successfully adopt and apply each practice.

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.

A new, cutting-edge approach can help you harness the principles of disparate software methodologies to accelerate adoption and deliver value. Essence, a modular standard created by the Object Management Group and promulgated by SEMAT (Software Engineering Method and Theory), provides a method-agnostic, common language for re-using software practices. Companies using Essence have seen dramatic cost-savings, process improvements and even new business creation.  Essence enables configuration of the 17 best-known agile methodologies in the market into smaller, foundational atomic “bricks” of re-usable practices. Currently the CA Technologies stack (CA PPM, Agile Central, CDM, Release Automation and Service Virtualization) is one of the unique environments that support all of these re-usable bricks of Agile practices.

Essence  Agility is instrumental in moving software development toward a true engineering discipline.