Stepping into the Product Owner role

In 2015, Christine Densley moved into her role as the Digital Product Owner at MiWay. Coming from a more traditional corporate environment, Christine was used to working within the Waterfall way of thinking – an environment consisting of business owners, project managers, business analysts – and lots and lots of documentation.

The Manifesto for Agile Software Development values "working software over comprehensive documentation". This core value asks us to think about how much and which kinds of documents are needed and when they need to be written.

In this post, Christine shares her experience of moving into an Agile environment – a difficult path, but one that she now believes has value.

To document or not to document?

“In many corporate environments, Waterfall development is the norm and delivery takes time - a lot of time! With that in mind, I love project planning, spec workshops and the feeling that what we are ‘scoping’ is going to be the best thing the insurance industry has ever seen.

“Stepping into my new role as Digital Product Owner for the MiWay team in 2015, I was so excited to start my workshopping and planning for the best Digital innovation I had ever run. So, in my first week, I got to work on my BRS (Business Requirement Specifications) and my BUCs (Business Use Cases). I was on fire and my thoughts had never been so clear!

“Eventually, the time came to circulate my draft documents amongst my stakeholders."

"The moment I pressed send, I silently congratulated myself, as I knew people would be glad that I had gotten the ball rolling so quickly.

“After a day or two, I had not received any feedback. I thought this was odd, and sent a follow up email. Days went by - and still no feedback! So, I decided to go speak to a few of the stakeholders and find out why I wasn’t receiving any comments, tracked changes or tabled suggestions.

“The responses I received blew my mind and confused me more than my first attempt at a ‹br /› tag!"

Here at MiWay, documentation is not needed, nor will it be read. This made absolutely no sense to me, and in that moment I thought, “Mmm, what have I gotten myself into”.

“I thought that perhaps my team would appreciate the documentation I had so carefully, and lovingly put together. So, in our first kick-start session, I spread the documentation out like a pack of cards -with the wireframes and process flows in their own pile. I started explaining what the project was about, the timelines and what was expected and in scope. I asked where I could save the documents for them to easily access.

My team were very polite and, in not quite so many words, they said, “Well, we don’t use documents here at MiWay; we are Agile. We don’t need predefined requirements of how things must work; we are Agile and this will evolve. We don’t need a BRS and BUCs to understand what we should create; we use stories in Agile.”

And then the penny dropped.

"I had gone about this all the wrong way. My first mistake was assuming that this project was about ‘my’ thinking and not about ‘our’ thinking. And unlike my past experience in Waterfall, MiWay is an Agile company; MiWay is all about team collaboration, and ever-evolving requirements. My second mistake was thinking that I should try mould MiWay to be more Waterfall. I wanted to change the way MiWay worked, but they had been doing really well without documents and long-winded processes."

That was when I thought, “Mmm, let me give this Agile thinking a chance”.

"Nine months down the line, I am super happy, document-free and loving my team and how we work together. Instead of spending hours preparing documentation and waiting for feedback, our team has discussions about what’s best and we make decisions right there and then. We have backlog grooming session to flesh out the stories and sprint planning session for prioritisation. It’s the perfect combination of a great team with great ideas that will create the best Digital innovation we have ever run! "

“To be honest, I really do miss my documents every now and then. It would be great to have documented how we got to a decision. But I guess that’s not Agile.”

There are many debates on how much and how little documentation should go on in an Agile environment. InfoQ’s post on “Documentation in Agile: How much and when to write it” is extremely comprehensive and sums up both sides of the argument, and well worth a read!

Related Articles

Saving Lives: From Passion to Daily Mantra

Introducing Lerato Thinane – or, as she is affectionately known in the MiWay offices, ‘Miss T’. Getting emergency services and police to the scene of clients’...

MiWay Hosts Second Actuarial Hackathon

MiWay Insurance will host our second invitation-only Actuarial Hackathon in April 2019 where graduate students’ modelling skills, resourcefulness and perseverance...

Become part of MiWay's Actuarial department!

MiWay's Actuarial department plays an essential role in the company since the work we do is at the core of insurance - i.e. charging the right client the right premium. We...