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!!

Crossword.

Since most of my friends are actually not involved in the world of software development, when trying to describe what I do and how we do it, I tend to try and make comparisons to real life scenarios they can relate to. Today, I thought I’d share a wonderful example I stumbled across a little while ago;

 The Crossword Effect by Clarke Ching (Clarke Ching’s Rocks And Snowballs)

Wish I had come up with that one myself….

 

Location. Location. Location.

Over the next few weeks, I am lucky enough to be on location on the beautiful Island of Tasmania – better yet, I am here on vacation. 🙂

Since I don’t particularly want to spend my time writing about work while relaxing with my family, instead I will share some thoughts from others in the agile community.

Today:  Distributed Collocation.. an Oxymoron? by AccuRev

I hope you like it – see you in a few weeks!

Remote Possibility.

These days, more and more people are engaged in conversations about distributed agile. Is it really necessary to have the entire team be co-located in an office all of the time?

I have a strong opinion that agile can work just as well with distributed teams, as long as the basic principles are followed. Starting first and foremost with trust. I am a product owner who works remote. My situation is perhaps not very common, in that I am one of several product owners in our organization working on the same end product. The other product owners all work in the same office along with the majority of our development and QA teams and of course our scrum masters. I on the other hand work in a different location and even a different time zone than the rest of the team and have done for several years.

Initially, our company was working in waterfall, which means that this arrangement, albeit unusual in our organization, didn’t raise that many eyebrows. After all, working remote is becoming more and more popular these days, although admittedly it is still relatively new to the hospitality industry. Developing in waterfall, my working remote meant that I was able to spend many focused hours writing detailed requirements, without interruptions or distractions that naturally occur working in an office. I was able to produce a lot of quality work, delivered on time and with no adverse effects on any other member of the team.

Then came agile… all of a sudden working remote became somewhat of an enemy. Agile says teams should be co-located. Period. Or so people thought. In my situation, re-locating to be with my team at all times simply wasn’t an option. Luckily for me, my managers and team members were open to exploring slightly more unconventional setup of remote scrum. So for the past few releases I have been the remote PO of a scrum team, sometimes with all other team members located together, sometimes with some of them also remote. And I can honestly say: it works.

I wouldn’t go as far as to say it’s just as easy as doing scrum when you are co-located, although I can’t say that with complete certainty, as I never have done scrum without being remote. I can say however that being remote makes me far more organized and forward thinking than I believe I would have to be otherwise. Because my team is working for a portion of the day without being able to reach me, I need to be extra clear in our daily meetings, always make sure I prioritize making myself available to them when I can and ensure that the teams’ priorities are crystal clear, so we don’t run into any bottlenecks.

For me, the key to being a great scrum team is trust. To be successful as a team, I have to be able to trust the developers, the developers will need to trust the QA, everybody needs to trust the scrum master and trust the product owner. Without trust, there simply is no team, without trust, we are just a bunch of people giving and following orders.

While it might seem that working remote scrum makes trusting each other harder, in my experience, it is actually the opposite. Allowing the arrangement where some of the team are remote, is an immediate sign to them and the outside world, that they are members of the organization that can be trusted to work unsupervised. In remote scrum, there is no space for micromanaging or looking over people’s shoulder, we just trust that we each get on with our work. And when we do get together each day, we make sure our time together is focused and used effectively, because we know it is limited.

I can’t say whether working remote has made me a better product owner, but I can say that our team has been able to deliver just as much value as any other co-located scrum teams. So for me, distributed scrum is more than a remote possibility.

Checklist.

I was actually very happy this Monday, strange I know, but right now, everything to do with my (part of the) project seems to be going very smoothly. My team is primarily focused on the technical discovery for the next feature, which leaves me with a bit of breathing time to focus on the backlog.

Not that it was easy to get to this point. It took us quite a while to get to a point where everyone was aligned and understood what our next steps should be. Now that we have switched to agile, everyone involved in the process is less and less comfortable with the idea of spending time on anything that may not yield shippable software. Problem is, this next feature we are working on is so complex, involving multiple systems, multiple skill sets and processes that we simply needed the extra time.

We already spent a few weeks digging into and defining the business process – we really needed to also allow the same focus on the technical discovery to make this piece of the puzzle work – and more importantly work well! But, how can we communicate what we need to do, show our progress and make everybody understand the value?

Well, we ended up trying various different approaches and quite frankly, in the end, the most effective way of communication was a checklist, albeit combined with a couple of fancy graphs to make it interesting. Having a clear list of what we needed to do and investigate in order to be able to move forward with this feature was ultimately what we all needed in order to move forward. For our team, it gives us clear direction on what to work on now and next and for our stakeholder outside, it gives them a good idea of exactly what we are going to deliver and when.

Being a big fan of lists – I make lists for everything, literally – it was more of a compulsion to create a list of tasks and I did it primarily for myself to get my head around the process. In the end however, it turned out that it gave us and leadership the direction we really needed to stop talking about how we might do what and just get started and get stuff done. We eventually turned our checklist into stories, so now they live as our spike backlog and we can create the usual burnup charts that show our progress and productivity – making sure our stakeholders are happy  and informed.

So, we are now back in the world of scrum, with backlogs, showcases and burnup charts, but in the beginning, there was my good old friend: the checklist. I couldn’t have done it without you!