Resources

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.

"I am excited about working with industry partners at SEMAT and leveraging the ESSENCE standard", said Scott Ambler in a recent phone interview, " in order to not just have different types of re-usable domain content built up for use as accelerators in Disciplined Agile Delivery projects, but also to clearly guide the industry on the benefits of specific granular practices that are currently uniquely only present within the Disciplined Agile Delivery method.”

Every agile organisation aims to run successful programmes that demonstrate true value and IT results, presented in a way the business can understand. But many struggle with showing how IT and the business are better, faster, cheaper or that their customers, users and other stakeholders are happier since going agile? The single biggest problem we see organisations continuing to grapple with in their agile transformation programmes is not understanding why they are changing the way they work – not visualising the goal, setting targets, measuring improvements, or demonstrating the benefits generated. The key here is to establish a set of actionable measures to drive the change and inspire the teams. These should explicitly support the principles and values being promoted and challenge the teams to improve.