Agile Transformation

Part 4: Some practical tips to avoid waterfalling 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 4 of this series, Ian Spence provides some practical tips to avoid waterfalling your features.

Part 3: What Does it Mean for a Feature to be Ready?

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 3 of this series, Ian Spence provides guidance on what it means for a Feature to be Ready.

7+Sins-Feature Preparation

Part 2: The Seven Deadly Sins of Feature Preparation

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.

The Critical Roles Executives, Product Managers and Release Train Engineers play in Enterprise scale agile software development.

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.

Better Predictability of Delivery and Closer Connectivity to the Customer

  • 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

Feature Slicing Guide and Poster

One of the key activities that will help make your SAFe® program a success is the careful preparation of your Features prior to Program Increment (PI) planning. And one important part of this preparation is to slice up any of the targeted Features that are too large to be easily delivered within the PI.

This handy downloadable guide shares some of our experiences in slicing Features. And, in tribute to Richard Lawrence and his popular Story Splitting poster, the authors have provided you with a complementary Feature Slicing poster for you to use in your SAFe program. Sweet!

ABC of Essentialization

An ABC Guide to Leveraging Adaptive, Bite-Sized, Composable Practices

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?

What Should You Measure?

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.

Pages

Subscribe to RSS - Agile Transformation