A Product Owner’s First Glimpse of Agile

Kent McDonald introduces us to Arthur, a middle manager and product owner in a medium-sized insurance company who has been assigned to take on an agile project. 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. Kent explains the challenges product owners like Arthur face and how to make product owners understand agile better.

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.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.