The Framework Isn’t the Change

A model that worked somewhere else offers something tempting, a ready-made answer, copied roles, renamed teams, new events. But the problems that shaped that model may be very different from yours. Sprints, product owners, scrum masters and backlogs can help. Their usefulness depends on the work they enable and the problems they help people solve.

Don't lose the plot when it comes to using frameworks. Prescribing them before understanding how a complex changing adaptive system like an organisation skips the discovery that made the original approach valuable. Start with what needs to improve. Explain why it matters. Give people the authority and support to experiment. Then use what is learned to shape the way they work. The framework should earn its place through the difference it makes.

A few other thoughts on this and potential things to come back to:

Making any kind of “Agile Transformation” goal can distract from improvement. I’d think about systems goals and being clear of outcomes. Counting agile teams, events or behaviours can tell you about adoption, but it does not establish whether customers and colleagues are experiencing better outcomes.

Mandated change limits ownership and motivation. Prescribing practices from above can often undermine empowerment, even when teams receive coaching and some freedom over implementation.

Organisational change cannot be fully planned in advance. Treating transformation as a predictable project with a fixed completion date overlooks uncertainty and shows a lack of understanding that an organisation is a complex adaptive system and how people can respond differently to change.

Three interacting sources of complexity play a key part. Organisations are complex adaptive systems, product development involves discovery, and changing ways of working involves social relationships, culture and identity.

Culture and incentives shape behaviour. What gets recognised, rewarded and encouraged strongly influences how people work together. Team identities also affect whether people optimise for their own group or the wider organisation.

Learn through experiments. Try changes, observe the organisation’s response and adapt. Expand and amplify approaches that help, or adjust, dampen down or stop those that do not.

Use a balanced set of outcomes. Help find a balance of competing forces and don’t over-do any of them too much at the expense of another. Define early warning signs of ‘too much / too little’. Think Better quality, value, flow. Flow includes time to learn, time to value and time to pivot.

Choose practices to suit the context. Agile, lean or progressively smaller delivery cycles may all support improvement. Respecting existing roles and evolving working practices can be effective, particularly after unsuccessful transformations.

Establish a clear, shared why. Explain why change matters in the organisation’s particular context. The purpose should consider customers, colleagues and wider stakeholders, alongside shareholders. If leadership can’t all articulate the same why, then things are going to become more blurry for other people as the ‘why’ message permeates through the organisation.

Empower teams and help shape the how. Give teams clear outcomes and meaningful autonomy to solve problems, building continuous improvement into everyday work.

Leaders can be at all levels coaching and removing impediments. Help teams develop their thinking and experimentation skills, while addressing obstacles they cannot resolve themselves.

Improve the underlying system of work. Trust. Better feedback loops, quality, safety and working conditions can reinforce one another, supporting shorter lead times and more satisfied customers and colleagues.