Merry Christmas.

I know it’s not considered politically correct to wish anyone a merry Christmas these days, but I just can’t get used to saying “Happy Holidays”. Although, having said said, I suppose I am always happy about holidays, so perhaps it’s not so bad after all…

Today I am busy getting ready for the aforementioned holiday, making sure everything that needs to be tied up, is tied up. Anything that needs to get done, is done. And everybody who may need me over the next week, knows that it probably ain’t gonna happen. 🙂 …unless of course there happens to be an agile emergency, in which case of course I will move mountains for the team!

Keeping the spirit of this post light, I wanted to share a little Christmas fun I found the other day: Top Ten Gifts For the ScrumMaster In Your Life  by Mike Cohn at Mountain Goat

I’ll be away the next couple of weeks, spending some quality time with my family – I hope you get the chance to do the same!

Have a good one and see you in 2014!

Better late than Never.

I’ll admit it, I was so busy and stuck in getting some system testing done, I completely forgot it was Tuesday and therefore “blog-day”. Shame on me!

So, this post is a little late, but nonetheless I hope you find it interesting:

Are we solving the right problem? by Mike Cottmeyer

Don’t Get Emotional.

One of my least favorite tasks as a product owner is having to prioritize the backlog and stack rank stories to make sure we develop the right things at the right time. In principle, I don’t have a problem prioritizing items, what I do find rather frustrating is how emotional and subjective prioritization often is.

I myself am a huge fan of logic and formulas and empirical research (geek alert!) to reach a conclusion as to which items are important, rather than just going with my gut. Having said that, sometimes it is necessary to go above and beyond what the data says, because there is a specific item that triggers a lot of emotion – negative or positive – from the overall user community, that warrants an increased priority.

On my project, we have a lot of those very vocal, very passionate users, that are sometimes rather difficult to temporarily drown out, so the product team can objectively assess and prioritize enhancements to our application. Furthermore, a lot of us product owners, myself included, have worked in the field as a user at one point in our careers and therefore still have some emotional ties to what is was like being a user. On top of that, we have spent a lot of time and effort to foster a culture of actively soliciting user feedback and enhancements requests, which makes it very difficult and rather uncomfortable to say no to requests, even though sometimes we probably should.

With all of this emotional baggage, a product owner’s judgement can easily be clouded – not deliberately, but subconsciously. Even more reason to develop a clear-cut, fact-based system to rank and prioritize stories and features based on their attributes. But which attributes are the right ones to look at? Do they all carry the same importance? Do we rank technology over user experience or vice versa? If the system crashes, because we overload it with data and logic, that is obviously very bad. But at the same time, we also cannot ignore the user emotions and aggravations. Instead, we need to find a way to quantify the user reactions to be able to compare and contrast them other measurable aspects of the product. Only then can we determine whether a screaming user is just having a bad day or it is a clear indication that something is very very wrong…

I don’t have all the answers yet, but one thing I am certain of: if you want to improve the prioritization of your backlog, be objective and don’t get emotional!

(Dis-)Organized.

This week I had a somewhat lastminute trip to the headoffice, so I didn’t remember to write a post in advance, so instead, I’ll feature another article today:

Reorganizing for Agility I by Anurag Prakash

Next time, I’ll try to be more organized.

The Gift of Feedback?

After an interesting conversation among my fellow Product Owners yesterday, I thought today’s post should be about something we always ask for, often receive and are not always happy about: feedback. In the English language of the corporate world, this is often referred to as the “gift of feedback”. For me, this expression always holds a certain sense of irony. While in English “gift” pretty simply means something that is given, in my native language German, “Gift” actually translates as poison.

Of course feedback is always a good thing, after all, what good is anything if I am the only one who thinks so, but there are certainly occasions where feedback can “poison a plan” – a sprint plan for example. Every now and then one of our showcases throws light on some additional feature, nuance and business scenario previously unaccounted for which the scrum team then dutifully investigates, vets and puts on the sprint plan for the next iteration. Perfect agile process, right?

The problem is though, since the showcase is at the end of a sprint, invariably most of the sprint planning for the following sprint has already been done by the team’s PO. Having to incorporate another item that late in the game does not a happy developer make! Agile scrum in itself is already a very challenging process at the best of times and including showcase feedback aka added scope at the last minute before the start of a sprint only increases the pressure.

So, what to do? Unless the basic principle of improving a product by iteration is completely thrown overboard, we must continually ask for feedback, digest it and include in our product moving forward. Otherwise, we are no longer agile, we are just “waterfalling” within a somewhat agile structure. The question remains though, what is the best way to accommodate feedback without disrupting the work for the following sprint? Schedule it to be done later, the following sprint perhaps? Plus, by simply accepting whatever feedback is given to us in a showcase and immediately implementing it in the next sprint, are we missing the opportunity to dive deeper into what we are missing and taking the time to truly understand the customer ask?

What about you – in your scrum process, how do you avoid the “Gift” in feedback?

Scope Creep.

In any kind of project “scope creep” is a term that comes up often. Depending on the kind of project, it may happen rarely or frequently, but in my experience it’s safe to say that there is always a certain level of scope creep, or at the very least, the continuous threat that it may surface.

While scope creep is mostly related to additional development work, further testing required or perhaps another chunk of analysis previously unaccounted for, what I have observed recently is a more subtle kind of scope creep. In fact, it is not even related to the technology or software of our project. Instead, we seem to be suffering some blurring of the boundaries when it comes to our agile scrum process, more specifically the purpose and content of the scrum gatherings.

When we first started working in the scrum module, a great emphasis was placed on making sure we setup the correct cadence of meetings. As per the scrum model, we dutifully setup daily standups, regular retrospectives and sprint planning sessions and of course end of sprint showcases to demonstrate the development completed to our stakeholders for feedback.

The one meeting where I have noticed a big change over the course of the past weeks and months is the showcase. It seems that we slowly but surely move away from the true essence of showing a live demo for the respective scrum teams, so our stakeholders and other teams can see the progress, the decisions made and provide feedback on the same. Instead, it seems the meetings is morphing into more of a general project update session.

Not that getting an update on what other teams are up to is not valuable time for everyone involved, it most certainly is, however I wonder whether the scrum showcase is really the right forum or whether we should try to go back to purely focusing on the demo of new software and put a stop to this new kind of “scope creep”…