Choosing Change.

Something I find particularly difficult to deal with sometimes is how to handle all the suggestions, ideas and requests we receive from our end users. I am not talking about feedback regarding functionality that we are currently working on and where we specifically asked for feedback and user input. I am talking about all of those little things that users would really really like us to change or add to the application – particularly those that may not necessarily be a good idea.

Of course, users always have a specific reason in mind why they want the system to do something. However, not always are these requests really born from necessity. Especially in our case, where our application is replacing another system that many of our users have been working with for years, in some cases even decades. It’s no surprise really, that a not-insignificant number of enhancement requests could be simplified into one user story:

“As an experienced user, I want the system to handle this process the way my old system did, so that I do not need to change.”

Like I said, nobody is at all surprised that we receive requests like that, however somehow we haven’t yet figured out the best way to deal with them. Yes, we do have an extensive team of trainers, support staff and even a specific change management department, but requests such as these seem to bypass those teams entirely and in the end, tend to end up as enhancement requests in our product backlog.

For us product owners, this makes the process of prioritizing and grooming the backlog that much more difficult, because not only do we need to evaluate, prioritize and write user stories for all the very valid and great suggestions we receive from our users, we now also need to figure out what to do with the undesirable ones, who frankly just clog up our queue.

I do believe that the product team is responsible for choosing change – but we are probably not the right team to manage its undesirable cousins and the users who request them…

Don’t Lose Focus on Collaboration.

I was looking for inspiration for the blog when I stumbled across this post by Satish Thatte on the Agile Management Blog.

Balancing Individual Focused Work with Collaborative Team Work: Open-Office Bullpens are Harmful!

I have always been a believer in making sure that my work is a balance of team-time to catch up on what’s going on and focus-time for the more complex and intricate tasks of my day-to-day. Working remote from my home office, it’s pretty easy for me to make that happen. When I really need to focus, I can just avoid my instant messenger, screen any non-urgent calls and dive into the deep pool of total concentration.

My colleagues who work in our “agile friendly” open plan offices are not so lucky. Yes, agile promotes co-location, but how useful is it really to have non-focused chatter in the background while you work? Let’s be honest, not every conversation that happens in an office is actually productive or even related to the work going on. We all chat with our co-workers about our weekends, where we should go for lunch, and so on… Yes, we also discuss our work, but not all the time is the topic of conversation really worth the interruption of and breaking our concentration.

Therefore I question, are open plan offices really the best layout for productive work?

Happy New Year!

Another year gone by, another set of project milestones achieved, another pile of features, enhancements and bugs evaluated, developed and fixed. If I may say so myself, 2013 was a fantastic year for our project!

We made the switch from waterfall to agile scrum. We became more focused, more transparent, more efficient and effective. We learned new tools, techniques and threw ourselves into the change. We tried, we failed, we tried again, we panicked and cursed, we never gave up – and when we look back now, we succeeded.

We involved more users and subject matter experts than ever before. We designed the software with our users for our users. We delivered high value, high impact solutions and earned great feedback and appreciation in return. Our product has never been better, our process is working and we have an incredibly talented, committed and positive team!

It is now 2014. The (never ending) cycle of software development begins once more. From where I am standing, I can’t wait to jump in! I feel motivated, I feel excited and I feel like I have a brilliant team in my corner itching to make our product even better.

So today, the first post of the New Year, it is all about inspiration, motivation and saying THANK YOU!

You all know who you are, you make our team awesome, you support each other, you work like crazy to deliver and you have fun doing it. Thank you for your hard work, your dedication and your energy.

Here’s to another great year!!

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!

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?

Managing Change.

During a recent internal stakeholder meeting, our leadership team brought up the challenge of dealing with changing the working model for a technology project and how we experienced it in our team(s). Since we are (one of) the first teams in our company that have adopted the agile scrum model, it’s often all eyes on us to try and determine whether it is something that should be rolled out to other projects and teams within the company.

While it is easily communicated, documented and supported with facts how working agile has improved out productivity and product quality, it is not so easy to also share the process and the challenge of managing change. Changing from waterfall to agile is not just simply a change in the way we do things day-to-day, more like a huge fundamental upheaval of everything we do and the ways in which we do it.

For myself – and I assume everyone else in my extended team – it was a very big adjustment. Working agile is an approach so completely different, that it was almost like starting a new job, rather than just adapting how we work. During our change process, this was more often than not accompanied by feelings of uncertainty, sometimes confusion and frustration along with it. More importantly, it was more than just a little difficult to suddenly have to work so closely together within our scrum teams. With everyone feeling a little uneasy and overwhelmed by it all in the beginning, it didn’t exactly create the best atmosphere for productive team work. Moving from a process that is known, that I was good at, that I thought I had mastered, to this new thing called agile was a big deal!

Luckily, in my organisation, we had a lot of support. We had consultants who helped us learn the process and apply the methodologies in our project. And honestly, without them and their constant push to keep going and keep looking towards the benefits, I think a lot of us would have cracked and revolted to get back our nice, comfortable waterfall approach. Especially in the early days, when we were working through our very first agile release, it really isn’t all that obvious upfront, that agile really does improve the project, not just the output, but the day-to-day working within. For anyone wanting to implement agile in their organisation, the one thing that I would say you simply have to do, is get an expert in to help you, not just to explain the process, but have a “cheerleader” there to support, guide and motivate your team to keep at it during the tough times at the start.

Now, a few releases later, I can clearly see how working agile is benefiting us, both in terms of project output, as well as enjoying the daily interactions within and across our scrum teams, getting to know the colleagues specializing in their respective disciplines and gaining a much better insight into how we can collaborate and help each other achieve our goals.

I am pretty confident in saying that most of us have converted to agile scrum. We learnt it. We do it. We like it. Change is good.

The fear of the unknown.

A little over 6 months ago, my company decided to change their methodology from the traditional waterfall to the newer, brighter, shinier agile scrum methodology. With relatively little experience within the realm of software design, this being my first assignment in this area, I didn’t think that much of it at first.

My employer is a large multi-national hospitality company embarking on customizing new Sales & Catering Software for their 500+ sites globally. While the company certainly has experience with designing and customizing software, my own background is probably most accurately described as being the customer. Having worked in various roles in hotels and with various types of hospitality focused software for years, I initially joined the project team as a subject matter expert on our customer requirements with little or no knowledge of what goes into designing successful software.

In my career to date I have made every effort to embrace new challenges, so I am no stranger to change. Whether it’s putting my hand up for new projects, pushing for promotion to stretch my skills or even pioneering to set up entirely new job profiles that no one ever did before, I’ve done it. I won’t try to pretend that I was comfortable doing it, far from it, pushing ourselves out of our comfort zone never is, if it feels comfortable, you simply haven’t pushed yourself far enough. It is however hugely rewarding!

The beauty of trying something new is that every little win, no matter how small, can feel like a huge victory.

Only the thing is, you have to actually choose to embrace the change. When we were first introduced to “agile” and “scrum” during a team meeting, my first feeling was: “Great. Just as I have figured out how to do my job, you’re changing everything.” I wasn’t immediately excited, I didn’t jump for joy at the prospect of having to start from scratch, I also wasn’t sure that I really liked the idea of agile, particularly its transparency. We all have doubts on whether we are good enough every once in a while, so hearing that “agile improves transparency” was a little scary. What if my work isn’t actually any good? What if I don’t learn fast enough? What if I fail? Enter: the fear of the unknown.

Of course there were training sessions arranged, consultants brought in to teach and support and assurances were made at every opportunity that “everybody knows we are new at this, we are not perfect yet”. So together with my peers of other product owners, we sat through the training, we observed our consultants, we assured ourselves that “everybody knows we are new at this” – and it felt ok. However there is still nothing that can prepare you for the moment where you become the one in charge. Where you need to actually be the agile scrum product owner you have been trained to be. Where you need to take responsibility for your newly formed scrum team. Where you actually need to guide them on what to do. And all of it at a point in your own learning when you are not all that certain as to what that is yet. Scary? Oh yes!

The key to success for me was to embrace the mistakes I made, learn from them, improve myself and then when I eventually got something right, take a moment to celebrate. And the successes do not have to be big. Having a productive team meeting, having a good laugh with my scrum team and see that they are actually starting to trust me, getting a little pat on the back for a nice showcase presentation, delivering a tiny piece of working software. All those things are not huge, but they are little milestones in your journey to embracing agile, to realizing that scrum is fun, that transparency actually helps the team and that continuous improvement, not just of the product, but also of the scrum team, is really what agile is all about.