A Product Owner’s First Glimpse of Agile

IT told him that they were going to work in two-week time periods, which IT somewhat inexplicably called a sprint. “Geez,” thought Arthur, “They seem to be going overboard with the sports metaphors. I wonder if I can call a ‘delay of game’ if they don't deliver when they promise.”

IT told Arthur that they wanted to meet with him at the beginning of the sprint so they could tell him what they could and could not work on. Also, they wanted to meet with him at the end of the two weeks to demo what they had built. When he heard this, his mind suddenly flashed to his calendar and all the meetings that were already on it. How could he possibly fit more meetings into the mix? As he was pondering this dilemma, IT staff also indicated that they expected him to be available to answer specific questions from the developers, and it would be really handy if he would just come down and sit with the team in its bullpen during the course of the project.

Arthur's germophobia kicked in at this point and he shuddered at all the diseases he stood to pick up from being in that close of contact with so many people, day in and day out. Not to mention the nagging realization in the back of his head that he probably couldn't answer every detailed question the developers might have. He just wasn't as familiar with the day-to-day work anymore. He was, after all, a middle manager for crying out loud.

He had finished the discussion with IT saying he would think about it and that he would get back to them. Then he went back to his office, closed his door, sipped his cold cup of coffee, winced, and wondered what he just gotten himself into.

Arthur's story is not too different than that of many first time product owners. For those unfamiliar with agile, the terminology and techniques of agile approaches can seem strange and often a little silly when not accompanied with an explanation as to why those techniques exist. Past interactions and modes of working between IT departments and their stakeholders inside organizations often leave a lot of baggage that needs to be dealt with when moving toward a more collaborative relationship. The first step in building that collaborative relationship is seeing things from your stakeholders' perspective.

In enterprise-driven situations, such as Arthur’s where software is not the main business of the organization, stakeholders most likely do not have an appreciation for the uncertainty and complexity inherent in software development projects. They may even not be familiar with project work in general, being used to working in the somewhat more predictable world of day to day operations. Merely explaining an agile process to these stakeholders will often leave these stakeholders more confused than enlightened. This is especially the case with the unique language that agile approaches invented to differentiate themselves from traditional waterfall approaches, which your stakeholders may not be too familiar with either.

Once you understand your stakeholder’s perspective, the best way to strengthen the collaborative leadership is to help your stakeholders learn the approach, particularly why the delivery team uses the practices and techniques that it does. In other words, help your stakeholders learn agile by helping them learn the principles and values of agile. If your delivery team is just starting to learn agile, include your key stakeholders in whatever training or workshops your team participates in to get familiar with the agile approach. If your delivery team is utilizing coaching, provide coaching for the stakeholders as well.

When you are introducing the agile approach and if your delivery team is already familiar with agile and you are bringing on a new stakeholder, lead off with why your team uses the techniques that it does and explain what the benefits are for the stakeholder; it’s a greater likelihood that team members will get their needs satisfied even though they may not quite understand exactly what their needs are when the project starts.