It's easy to forget how things that seem as plain as day to us can often appear quite strange to those with different experiences and backgrounds. Years of helping teams and their stakeholders adopt agile have brought that home to me in myriad ways. I thought it would be interesting to explore what an agile transition might look like from the various perspectives of the people involved. In this series of articles, I am going to tell the story of an agile transition from a variety of viewpoints. To start off, I want to introduce you to a product owner named Arthur.
Arthur is a middle manager in the agent-support department of a medium-sized insurance company in a medium-sized city in the middle of the United States. Last week, Arthur's boss, the VP of sales, asked him to take the lead on a project called Phoenix, a project to replace the current hodgepodge of outdated applications, Excel spreadsheets, and rogue Access databases that the members of his department charitably call a commissions system with a single new system.
Arthur doesn't typically work on projects, mostly because there hasn’t been a project focused on the commissions area for the past fifteen years that he worked at the insurance company. All the same, he works regularly with IT with what could generously be called varying results. They seem to be fairly responsive when one of the hodgepodge of systems that he uses for calculating and paying commissions decided to pick check-cutting day to stop working or give up its existence all together. When it came to dealing with the myriad RIP's (Revision In Programming) he had submitted over the years to make changes to the commission system the responsiveness changed dramatically. Inevitably, when he asked about the status of a particular RIP—for example, one of the many he submitted to implement the latest month's compensation scheme his boss cooked up—someone from IT would remind him where commissions fits on the overall priority list; right after changes to the application that IT built to keep track of when to reorder coffee for the automatic coffee machine.
That all changed when Arthur's boss used the 25 percent drop in sales and 50 percent agent turnover rate as a reason to replace the commissions system. Seemingly overnight, Phoenix shot to the top of the priority list.
Arthur was initially very excited about the sudden attention that the commissions system was going to get from IT. “Finally,” he thought, “I'll be able to get these 142 RIP's taken care of!” He felt a little trepidation at being the lead on project Phoenix; although he had never been the lead on a project before, he reasoned to himself how hard could it be? He never had any difficulty arranging his family vacations, the department's food days, and he always managed to get the checks out on time. Leading a project couldn't be that much more difficult, could it?
His initial trepidation turned to apprehension, concern, and dread after his first meeting with IT. He found out his definition of "lead on the project" and IT's were fairly different.
IT told Arthur that they were going to use an agile approach called "scum"—or was it "Scrum?"— for Phoenix, and that it was much better than the old waterfall method. He asked what it was called again that the IT folks explained with only a twinge of condescension that it was called Scrum as in the term used in rugby. Arthur wasn't quite sure what rugby had to do with building a commission system, but if it meant that he got what he needed without having to wait for the IT staff to change the main coffee supplier, he was willing to give it a go.
Additionally, IT told him that he was going to be the product owner and that he was the "single wringable neck." Arthur was a little fuzzy on what product it was that he was expected to own, and he gingerly tugged at his collar. He didn't like the idea of his neck being wringable, let alone being the only one.
When IT said that he was supposed to come up with a prioritized product backlog, Arthur winced at the word "backlog." He was pretty sure he had one of those already. It was called the list of 142 RIP's he had created over the years that had never been delivered. In his experience, backlog seemed to mean "stuff you aren't going to get." And then there was that priority comment. Arthur always tried to prioritize the things he submitted, but experience had shown that it rarely helped. Only when a system was completely down (what IT classified as "double- secret probation urgent") would he get any response.
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.
The delivery team that Arthur is working with made some common missteps when it engaged Arthur. The team members focused on the process they were using and used a great deal of what seems like jargon without explaining why they wanted to use those processes and what was in it for Arthur. Because Arthur does not have a good understanding of the benefits of adopting these approaches, it’s fairly likely that Arthur will be more of an obstacle to the delivery team than a partner. He won’t do this intentionally, but he might appear to question the process and try to bring the process back to ways he is more comfortable with because he doesn’t have a clear understanding of how doing things in an iterative fashion can actually be more beneficial for him.
Fortunately all is not lost. Open, honest conversations between Arthur and the delivery team will help Arthur get more familiar and comfortable with the reasoning behind the approach, and he will begin to see the benefits he receives from following the methods, turning him from an obstacle to a big supporter.
