Developing Agile Culture in an Agile Way

Tana Linback and Chris Daily told a good story in their presentation to the APLN agile users group meeting last week. They titled their talk “Culture Eats Agile for Breakfast,” meaning the organization’s native culture will always be bigger and more powerful than any agile team or adoption initiative.

The brilliance of what they did, as an IT leader partnered with an HR leader, was to apply an agile approach to culture change. They created a culture change “backlog,” a vision, broken down into goals and then tasks that mirrored the usual Scrum backlog in software development. They created a “culture owner” as the analog to Scrum’s product owner. They formed teams, worked and experimented in sprints, and learned and adapted in retrospectives, and so on. And they seem to have achieved some enviable results, especially as measured by employee engagement surveys where key metrics more than doubled.

That said, I think they missed one deep and important distinction and opportunity: they started from the view that the customers of an organization’s culture are its employees. I think the customers of an organization’s culture is it’s actual customers – anyone who buys their products/services (consumers), plus job candidates AND spouses and families. For each of these groups, culture matters because of what it supports outside of the organization, in the real world. Culture determines what consumers can do with their purchases, what kind of people employees can be when they get home, and what job candidates can achieve if they buy in. This matters because agile and a Scrum backlog must be about delivering value AND because customers, hiring targets, and families are the ultimate arbiters of the value of the organization’s culture.

Once hired in, employees are ALL part of the development team, in Scrum terms. Culture is what we all create and evolve together. To say that employees are the customers of culture, automatically cuts the organization into culture-makers and culture-takers, the latter absolved of responsibility and limited in their ability to contribute to shaping the organization’s culture.

This defeats the point of using Scrum to suggest, and guide work in, self-managing teams. Cultural is a whole piece of work in which all employees are necessarily involved. The ideal to shoot for is having them all engaged in shaping and adapting it. The organization owes all employees, and requires of all employees, an active membership on the culture development team, continually learning and adapting together – not a finished “culture” product produced and delivered by a small, select, or senior team.

Tana and Chris described their ultimate result in terms of high engagement and widespread self-organization in their organization’s culture development work, exactly what you’d want and expect. So my comment is really about the way they tell the story, and how we might approach it from the beginning in other enterprises, rather than about the quality of their work.

The common experience is that corporate communications gets the story exactly perfect and the whole thing falls down in practice. This would seem to be just the opposite, where the story was a little bit off, but good results were borne out by sound practice.

Join the meetup group for their presentation.