Remote control.

The agile manifesto states that;

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I can honestly say: I wholeheartedly agree!

Many studies show that up to 80% of communication is actually non-verbal, relying on body-language, tone, facial expressions and eye-contact, none of which can truly be conveyed by an email or an instant message, even a phone call only barely touches the surface. The most effective communication always was and still is a face-to-face conversation. Makes sense, right? So to be successful communicators, we just need to make sure all important conversations, meetings and handovers happen in person. Every time. Plain and simple.

This is where it gets complicated. I look around and what I see is that I work in an increasingly global and mobile world, with more locations, more technology and more cultures working together. While all of these contribute to the quality of the work, the diversity of solutions developed and ultimately may improve the cost-effectiveness of an organisation, working this way also brings its own problems: How do I communicate effectively having to rely on technology? How do I bring together a team across multiple time zones? And how do I promote teamwork and engagement in multi-cultural team?

There are many articles that provide suggestions on how to deal with this scenario, I’ve whittled mine down to 3:

1- start with a face-to-face meeting – being able to see who I am working with is incredibly important to me, in my experience, it promotes team bonding, commitment and communication. I find meeting someone face-to-face gives me more of an insight into their personality. Someone’s body language and facial expressions show their personal and social style in a way a phone call simply cannot. Naturally, it can be too expensive to fly people in just for a quick meeting but even using skype or facetime or other video call tools can make a big difference, I found it is worth exploring the options and using the tools available to your advantage.

2- set crystal clear goals – when working away from your team, it can be difficult to stay motivated, I am no exception. To keep myself productive, busy and engaged I write lists of items to achieve for each day. That way I have a clear goal, I know when I have been successful and when I had a productive day. When working with a distributed team, setting clear goals and targets is even more important, especially so, when you work in different time zones where an unclear goal can lead to hours and hours of idle time until the other party “wakes up”. So I make sure that when me and my team talk about our goals, we do so in real-time. For me, it is important  that we collectively assess if we covered the right tasks and check that we have the right amount of work to get done until our next meeting and of course that everyone has understood and is aligned on our team goal. Only if each of us know where we need to be, are we able to assess whether we are on the right track to get there in time.

3- use every communication tool available – when I first started in this role, I really only used our daily standup calls and the occasional email to communicate with my team. This worked well enough in the beginning, however as soon as things got going and got a little more complicated, I quickly missed the advantage of a co-located environment, where I could simply walk over to a person’s desk. Since we didn’t have that option, we just needed to be a little more creative. Technology became our best friend: we added instant messaging, a dedicated webinar room and conference bridge, setup an online sharepoint and added online tools to track our progress.  We continue to use emails and our daily standup calls and team sessions, but using more communication tools has given us more flexibility, improve our communication speed and quality and ultimately made us more agile.

I realize none of this is rocket science, it’s actually pretty obvious once you stop and take a the time to look at it. As a new product owner however, there wasn’t much time to stop and look. Especially in the first weeks of working with a remote team it was challenging enough just to figure out how to get from one sprint to the next.

Now, I follow my 1-2-3 and I feel back in control, remote control.

Meet the challenge.

Be the change you want to see in the world. Mahatma Ghandi

When I am pushed out of my comfort zone or god forbid someone disagrees with me, I try very hard to be understanding and open-minded, but sometimes, just sometimes, I forget everything I have learnt and go for the reflex reaction. For me, that tends to be skepticism. Unfortunately, skepticism, especially coupled with criticism, is about the least productive output in any situation.

I do try to keep myself in check when in company of others, but every once in a while I catch myself. Closing off my mind, thinking along my own path and continuously saying “No” in my head, not staying open to the ideas and opinions around me. Most importantly, I catch myself dwelling on the fact, that I am not happy in the current situation, as opposed to doing something to change it.

I’m sure we have all been there, sitting in a meeting where a discussion around a particular subject morphed into something completely different, people have gone on a tangent, ranting about something completely unrelated to the purpose of why you got together in the first place. I am no saint here, I have done it, not just once, many times. If I’m in the moment and on a roll, all it takes is one person in the group to go along with me and I can get completely lost – I mean, having someone agree with me does flatter the ego…

The problem is being the person on the flip side of that very interesting and inspiring conversation, the one sitting in a meeting room, staring at the ceiling, willing it all to be over and people to get back to the point. And doing nothing about it. I mean, it’s so much easier to just complain about the meeting afterwards than making the effort to steer it back in the right direction there and then…Guilty as charged!

The problem is, if a meeting is not productive, there needs to be a second meeting, to cover the stuff you didn’t get to in your first meeting, and then probably another meeting to discuss the stuff you didn’t get to in the second meeting and so on and so forth! And who wants to be in a vicious cycle of meeting after meeting after meeting after meeting… I certainly don’t!

So, I challenge myself – and you for that matter – to do as Ghandi says and change myself from being a passive skeptic to becoming an active enabler! To speak up when I can steer a conversation back in the right direction, be open, engaged and focused in every interaction and be the change I want to see in others.

Stay Positive.

Ever felt like you are stuck in a project? When it feels like the customers or stakeholders or team members just can’t agree on which feature to prioritize, or what functionality is feasible, or how much time and resources can be made available? Not fun – right?

Unfortunately, my project is at this juncture of the process right now. We – that is really the people above me, me being a consultant in the discussions – need to decide what to work on next and how to divide the potential work that’s there in order to be able to properly budget and staff for the next stage. Obviously, this discussion needs to take place for every project, and it’s a very important one, unfortunately, it is rarely a quick conversation where everyone sees eye-to-eye. More often than not, there are conflicting opinions, agendas and priorities, which means a quick meeting to determine a draft plan can turn into a lengthy debate about the future of the product.

I am exaggerating of course! The meetings don’t really get out of hand like that, it just feels that way to me sometimes. Mainly due to the fact that I am the “outsider” in those meetings who normally wouldn’t even be included, was it not for the fact that my team has been working on defining some of the features that we might tackle next. From my vantage point, if I was completely and utterly selfish here, these meetings are stalling my work, because until I know what the direction and priorities for the next features are, me and my team are stuck. Yes, maybe we could continue some of our analysis work, but that would mean that we might end up doing work that will be redundant tomorrow. Or maybe not tomorrow, but next week…

Like I said, not a fun situation to be in. On the other hand though, being able to sit in these meetings, being able to see the estimations and understand the decision-making process is actually really cool. One of the things I found difficult when first starting out as a product owner was understanding why we actually chose the features we built, or rather why we chose one feature over another, given that all of them are on the to-do list because there is a user need for them. While I don’t think there is actually a clean and simple answer to that question, I do think that I now understand a few more pieces of the puzzle that determine what makes it “in”.

So, rather than being annoyed at too many meetings or frustrated with being stuck in my own personal progress, I decided will use this opportunity to learn. I will provide my feedback and put my knowledge on the table, I will observe and listen and contribute to the process as best as I know how.

I will keep smiling and stay positive! 🙂 

The Balancing Act.

One thing I have found particularly tricky in my work as a product owner is getting the right balance between the MVP (Minimum Viable Product) and the logically perfect solution.

While of course I would always like to build the perfect system it is usually not advisable to aim for perfection, but to aim for functionally sounds while technically simple  instead.  This is not just to save on time and resources but also to allow for the finer details and possibly exception to be fully worked through and solutions developed around them. Building the “perfect” more complex solution may turn out to have some underlying weaknesses I simply didn’t think of or have time to look into, because the technical complexity took up all of our time and focus.

In theory, this makes perfect sense, but in my head, I still resent the fact that I have to build something that is not the perfect solution.

Then again, I am beginning to think that the perfect solution is really just a myth anyway – if working in software development has taught me anything, it’s that there is no such thing as a one-fits-all solution that will be just perfect for everyone; for the user, for the development team, for the stakeholders and bank rollers. At least one of the parties will always be slightly disappointed.

And this is where striking the right balance is getting tricky. When I know that the user or the customer is hell bent on getting the perfect solution, when the development team is screaming that it simply cannot be done with the time and resources available and my boss is telling me that increasing the budget is not an option. What to do now? How do I steer all the stakeholders in the direction that I think will be the best option for all of them? It sometimes feels like i’m a diplomat in the UN trying to foster a peace, just to get the various parties to agree on where to start and where to finish – all the while realizing that what I thought was the best solution in the beginning, might not actually be the best approach. And admitting that I was wrong can be even more difficult than trying to convince others that I am right…

In the end though, I believe that simplicity is key. As a team, we have built the best solutions when we have tried to purely focus on the basics, go with the simplest, easiest and fastest to implement approach that only fixed the one main problem – not the other five that are somewhat related that I really wanted to fix because I believed it would really wow the users. Those simple solutions have been the ones that were easiest to train, adopted the fastest and ultimately made the most difference to our users’ experience.

As much I am a perfectionist and would love to built the most comprehensive and perfect solution, I keep learning to try to find the right balance and to accept that the perfect solution may be perfect, but may not be the best.

More than just software.

When I started realizing that I actually really like the Agile Scrum Methodology, I started looking around the web for more information, stories and blogs on the subject. Reading about how others do things and what challenges they face is always helpful, whether you can learn from their mistakes or simply get some encouragement that you are not alone in your struggles to try to get it right in the agile world.

One really interesting article I read recently on OpenViewLABS is actually not about scrum in software development, it’s about using scrum elsewhere, basically applying the principles of scrum to any part of an organisation: Scrum One, Scrum All: Why Agile Isn’t Just for Technical Teams. The idea to use scrum outside of technology development really struck a cord with me, particularly since doing the functional discovery work, where we applied scrum without actually building software…

The article suggests to use the basic principles of scrum to create a framework for any kind of complex project or task. Just like in technology development, scrum can increase transparency, accountability, organization and flexibility, team members understand the big picture and how their tasks fit in, time boxing the various tasks helps provide structure and organisation, while still allowing for flexibility  to change if needed down the line…

In our functional discovery team we decided to take a similar approach. Initially we just dove right into the various features assigned to us for analysis, which resulted in one thing and one thing only: chaos!

Realizing we were getting nowhere, we adapted, we are agile after all! After completing our initial feature, we took a step back and re-prioritized our other features. We broke each of them down into smaller tasks or phases and we built a high level release plan on when to do what, so we could actually track if we were making the progress needed to complete everything by our deadline. Since we didn’t have specific user stories to complete, we took a slightly different approach, only creating place holder tasks for each phase we wanted to complete for our feature: Define (what’s the problem), Analyze (what could be improved) and Solution (how to improve).

This kind of approach really is not specific to software development at all, it’s a principle that is ingrained in any kind of improvement methodology, whether it is agile scrum, six sigma or lean, the basic steps – having to know your current situation, figuring out what the root cause of the problem is and investigating how to fix – it are applicable everywhere.

…food for thought.

Crouch. Touch. Pause. Engage.

Lately, I’ve been thinking about the parallels between rugby scrum and agile scrum, more specifically with what comes before. There are 4 steps that have to happen before you start a scrum in rugby, otherwise the scrum will simply collapse and you have to start all over again: Crouch. Touch. Pause. Engage.

Obviously I don’t mean this literally, but for me, these four steps align with preparing a solid backlog. My work in the past few months has been focused on evaluating some items that we are considering to build in our next product release, they are asks from our users that are not at all or only partially defined, we know that there is a need, but we don’t yet know how to meet it. In order to figure out how best to tackle these features, we decided to form a dedicated team, exploring our options and coming up with solutions that we can then turn into actionable epics and user stories.

This is the first time that we have gone with this approach, so it has been an interesting discovery of trial and error before we came up with a general approach that so far has helped us a lot in structuring our efforts.

“Crouch”

Get into position, understand who is involved, who is on the team and what their role is. We needed to fully understand our problem statement, define our goals and success criteria and I wanted to have a clear idea of our ROI, what are we getting out of this that warrants the investment. From there, it was time to work out exactly what the current processes are, which parts work and which parts don’t and where we think we might want to focus our efforts.

“Touch”

Getting a first sense of how the users feel about our proposed solution was very important to make sure we’re on the right track. This is not a fully baked ready to roll backlog of precise features, it is more of a general approach, that outlines which problems, extra steps or issues we are removing, maybe show a couple of rough mockups of what the new process might be and how it would impact their day-to-day. We kept it general enough to allow for their suggestions, but defined enough to be able to clearly explain the  solutions we are suggesting.

“Pause”

When I say pause, I don’t mean just stop what we are doing, this is really more of a chance to reflect. We use this time to incorporate our user feedback into our design, further define our solution and do a  deep dive into technical possibilities and limitations. We spend a significant amount of time here, weighing up technical complexity vs user experience, the ideal solution vs the realistically achievable approach… The variables really depend on the complexity of the feature. What I also focus on here is documenting our decisions and recommendations, and most importantly; document the “why” it will be immensely helpful for others.

“Engage”

Once we have figured out what we want to do and how we want to do it, we are almost ready to start scrumming. Now, all we need to do is transfer the information to the relevant scrum team. Since we have been working on multiple features that cannot be achieved with just one team or even just one product owner, this piece is really crucial to get right. I learned that the hard way for our first feature, when we kept on getting drawn into the discussions time after time. Being out first attempt, obviously it was not perfect, but I think we learned from it and have a much better handle on how much detail and guidance we need to provide.

I think. I hope. We’ll see…

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.

And so it began…

There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.

Donald Rumsfeld