Resources

Serious gaming to encourage and nurture an agile mindset, beyond just software and product delivery teams, using jargon-light agility cards.

The Activity Spaces are an often-overlooked aspect of Essence. These 15 descriptions of types of common activities that all software development teams will do are often overshadowed by the specific activities from Practices. But as this article shows they have value in their own right and can be a powerful tool to help teams improve.

Welcome to the amalgamation of a short series of articles on crafting effective, well-formed objectives as part of the SAFe® Program Increment (PI) / Big Room Planning activity. We have seen a lot of confusion surrounding the use of PI objectives; confusion that often results in: Resistance to their use and; The production of poorly formed team objectives that appear to be completely redundant as they just list the Features being addressed. The first step to creating well-formed, useful objectives is for everyone to understand why they are so important. Covered in this document: Why do we need PI Objectives when we have Features? Writing good PI Objectives PI Objectives and the PI Planning Process PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments  

Our industry loves a fad - and in particular, we love to discover the Next Big Thing in development approaches. Each time we are promised a new (or improved) framework or playbook that will solve all our problems, and that we should immediately roll out to all our teams. And each time, we end up disappointed, without the results promised or anticipated, needing to look for a new Next Big Thing to repeat the cycle. It doesn't have to be that way, and the alternative needn't be as scary as it may seem. And it isn't another big framework!

The following blog provides a set of free, downloadable agile coaching cards that can be used by Agile Coaches, Scrum Masters and teams working in many different contexts. These cards have been developed while working outside of software and product development with government Defence teams and I’ve used these cards to teach agility and help develop an agile mind set.

As Agile Software Development practices become more and more popular both customers and suppliers are looking to find ways to have more agile contracts. Contracts that reflect and exploit the benefits of an agile way-of-working on both sides of the relationship. This hands-on workshop introduces and applies a number of simple but powerful tools to enable customers and suppliers to establish effective contracts that reflect their level of agility without constraining or compromising that of their partners.

In EM360's Podcast interview, Ian speaks about his experiences of specialising in large-scale agile adoptions. Drawing on his expert knowledge, Ian has worked with hundreds of projects to introduce iterative and agile practices in sectors as diverse as government, telecommunications, finance, and internet start-ups.

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

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?