What sort of conversations can you have with your organisation about software development practice and process? By which I mean not only – what do you talk about – but just as importantly, what do you bring to the conversation that affects how you frame the discussion, and how do you improve its chances of creating lasting change?

I’ve seen many missed opportunities at these sorts of conversations, in companies large and small. Every circumstance is different, but here’s one that seems to crop up a lot:

You’re a team or group working in a large organisation. You’re trying to change the way you develop software, but there are organisational structures and processes in place which govern how projects are started, managed, and run. As a committed agile/lean/kanban enthusiast, you’re certain that this is no way to run an army, but you’re not sure how to explain these new ways of working to your organisation, nor are you confident of being able to effect any immediate change either for your team and the way it works in relation to the rest of the company, or outside the scope of your team and its work.

It’s all to easy to rail against organisational structures that seem to you to be getting in the way of adopting a lean or agile approach. The zeal with which the agile case is sometimes put, particularly by people with little experience outside software development, can generate resistance or incredulity. Conversations between agile evangelists in the technology organisation and experienced project managers might as well be conducted in two different languages, and serve only to lower understanding and respect.

I’m not going to tell you what points to make in favour of your new way of working, but here are some things to bear in mind about the conversation itself.

If you enter the field with the belief that everything the other person believes is wrong, you’re not going to have much of a conversation. Don’t forget the agile manifesto’s recognition that there is value in many of the things that characterise traditional approaches to projects. After all, if (as we’re often told) 70% of waterfall projects fail, then 30% succeed.

The person you’re talking to is likely to have had plenty of experience in what they do, and will often be more aware of the organisational big picture than you are. Program and product managers see projects from beginning to end, and often have to navigate the treacherous waters of long-term planning and corporate governance. Respect that experience, and learn from it. After all, why should they listen to you? (if you’re really lucky, this remains a rhetorical question).

What sort of relationship do you have with the person you’re trying to convince? And what sort of relationship would you like to have? Is this person going to be a collaborator? An ally? Or are you just needing to keep someone informed?

What is the goal of your conversation? It’s one thing to enter a discussion about running a single team’s development in the context of your organisations larger practices around planning, project and product management, it’s a very different thing to be involved in taking a whole group or organisation agile.

A conversation is always with a person, not with a set of ideals. Try to understand the individual’s motivation – are they individualistic or group oriented? Will they dare take a risk and pioneer new ideas, or is security and group belonging more important to them? For people who’ve progressed within and find safety within an existing organisational group and process, you won’t have much success in promoting radical notions of self-organisation, responsibility and entrepreneurship.

The beliefs and activities of traditional project management support a set of values. Don’t limit your polemic to the outward signs of the traditional approach. Before you wade in with the “agile is best” arguments, understand those values, and how the existing project/program management regime embodies them. For example, there’s nothing wrong with wanting to take account of and manage project risk: if you can talk to those values, understand how they’re expressed by current practice and convincingly demonstrate how what you’re doing embodies these values then you’ll stand a much better chance of creating genuine understanding.

Some sources: I’ve been impressed with the Harvard Negotiation Project’s books: Getting to Yes, Getting Past No, and Difficult Conversations are all classics, and should be on the bookshelf of anyone who needs to communicate as part of their work and life (that’s all of us, isn’t it?). Robert Kegan and Lisa Lahey’s How the Way We Talk Can Change the Way We Work is the best sustained reflection I know on getting beyond the obvious in conversation to uncover values and motivate real change.

(Thanks to David Joyce for a question in advance of a CATeams Clinic for prompting these musings)