In my last post, talking about Organizational Risk, I advocated for a meeting once per iteration with members of different departments to reduce the kinds of project throughput risks that can stem from an dev team practicing agile working within a larger waterfall oriented organization. What might a meeting like this look like?

Infrastructure & Architecture Round Up

Standing at the board, the lead developer asks “What should we talk about today?”

“Network didn’t approve the changed we talked about for the redirection module.”

• Redirection Module

“We started working on the preview story, and we think it might be best if there’s a new host name for it.”

• Preview Module

“Did we hear back about the HA search approach?”

• HA Approach

“Anything else?”

Three bullet points on a white board, developers from the team, representatives from operations and architecture present, the group starts in on the discussion.

The issues being discussed are the stories in play this iteration, and likely the next iteration. Other items will come up as they talk, helping them understand one another’s work well enough to learn what else the other teams might need to know about. On a bad day, politics will creep in; on a good day, the attendees will all learn a little bit more about how the other groups think and work. The people in the meeting might find the same roadblocks – but they might find them earlier, and in enough time to build bridges around them or take alternative routes.

The dev team is starting to learn that to get a new framework or library approved, they need a six month lead time; but there are a number of already approved frameworks that will do the trick from time to time. The dev team is also learning that the operations team is managing a rather long list of technologies on a growing list of technology platforms with incredibly tight deadlines and budgets.

Building Trust

While this is one format and one idea for reducing Organizational Risk, the important thing is building trust. It doesn’t matter if you go to meetings, or manage it all over water cooler chats, or something else entirely. It’s the old theory about how fear springing from ignorance. If the groups we depend on don’t trust us, it will make it harder to finish our work. So how do we build trust? It’s perhaps a small part of what Dan North might call Deliberate Discovery. I’ll just call it getting to know each other better.

Over time you might even find that these other groups start to work with you differently. You can begin to compromise in ways that allow for greater success for both teams, increasing throughput.

In some organizations that have a mature CD practice, it might be other departments within the business, outside vendors, or partner organizations that have specific contracts about how a project will be addressed. In either case, it’s the same idea – work to increase understanding and build trust.