Collaboration.

Working in a large global corporation, it always baffles me how little we actually collaborate and utilize each other’s talents. I don’t mean working within my small team or even my extended product owner team, but across disciplines, teams and departments. Why do we hesitate so much to seek the assistance of others? Do we shy away from admitting that we could use some help? Are we afraid to lose control if we let others in on “our” area of expertise?

You might wonder what this post has to do with agile and well, perhaps it doesn’t specifically. It only crossed my mind since agile puts such a large emphasis on team work, collaboration, co-location, crossing skill sets… seems that these are all things we should embrace, not just on our agile lanes and scrum teams, but in our organization as a whole.

I try to encourage exchange of ideas by reaching out for help, offering to assist someone and most of all, genuinely invite somebody to challenge my point of view. I seem to get the best ideas when somebody challenges my initial approach and calls out my assumptions. I mean, as much as I would like to, I can’t be right all the time…and I am sure we can all benefit from a little more constructive feedback.

As it stands today, I think we have quite a way to go to communicate and collaborate successfully… There is a lot of talent out there and we can only to reach our full potential if we continue to challenge ourselves and others.

The post Collaboration first appeared on Agile, Now What?

Advertisements

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!

User Advantage.

A big part of agile development is engaging users, regularly and frequently, to get feedback on the product developed to date. Since our product spans multiple user groups in many different locations, it is not always the easiest thing to get a good subset of users together to evaluate what we have done so far.

Even the simple choice of choosing the location can be quite a challenge. Do we meet at our corporate office? Do we spread out and schedule various sessions on location? Do we just run the whole thing via video conference?

While we have done various versions of the above, the one thing we have yet to try out is do the entire interaction online instead of in person. The one main benefit of trying this out is fairly obvious, it would save the project both time and money if everyone could simply run the meeting(s) from their own location. No lengthy plane journeys to foreign locations, no rental of meeting space, no expensive printing of workshop materials. Sounds great! …or does it!?

Perhaps an approach like this might work if our entire user base was American. (I realize I’m going to stereotype a little bit here, and I apologise in advance if I offend anyone in the process.) In my experience, our American user base is very engaged, very critical and not shy to voice their opinion. For them, having a few shorter online sessions to review the product might actually work quite nicely. They can work it in to their day-to-day and still provide the valuable feedback we really need.

However, a significant portion of our users are based in Asia. And Asia is a completely different story. Not that our users aren’t as engaged or keen to share their feedback, they are, but they are also a lot more reserved and more careful about what they share. Also, a lot of them are newer to the software and have never been involved in feedback sessions before, unlike their American counterparts. For me and my team this means we need to spend some time making them comfortable to really say what they think, not what they think we want to hear.

In the end, it’s up to us to find the right balance and approach for each of our user groups, and to make sure we don’t accidentally favor some of them, only because they make more noise…

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.

Root Cause.

I read a few interesting blog posts recently about the value of root cause analysis when investigating product defects. I myself am actually a fan of the principle, since there is nothing more infuriating for a user than having a problem fixed without understanding how to avoid it in future.

However, sometimes a root cause analysis simply doesn’t help in avoiding or even fixing the problem as Mike Cohn so beautifully describes in this post:  http://www.mountaingoatsoftware.com/blog/root-cause-analysis-of-the-failure-of-root-cause-analysis

This doesn’t exactly convince me to never do a root cause analysis again, but it certainly makes me wonder whether we sometimes spend too much time analyzing that could be better spent fixing the problems right in front of us…

Instead, it is a lovely reminder that one solution most definitely does not fit all – and that we have to be a little more creative in trying to figure out what went “wrong”.

Quantity or Quality.

It seems the QA testing team is the one interested party in agile scrum that tends to get a little neglected. Nobody disputes the necessity or indeed the importance of testing the new code, however in my experience, our testing team have received the least amount of training and support to change to this new methodology.

In our project, we are very lucky in that the vast majority of our testers have been with us for many months, they are familiar with our application, have met some of our users and are therefore very well equipped in understanding what we need the system to do. Each of our scrum teams have their own QA resources that are involved in the discussions around each story. Of course, in agile, testing happens much sooner in the development cycle which has certainly helped us in mitigating risk before going to production.

However, I am personally not quite convinced that we haven’t shifted our focus ever so slightly away from the quality of our QA. It’s not that we are finding more defects now or that the team are putting in less effort to trouble shoot everything. But to me it seems that we have taken away some of the focus off QA, as it no longer functions in its own testing cycle. Where before, everybody on the project team was 100% focused on QA and bug fixing for several weeks, now that the process is built in the scrum cycle, it really is predominantly the testing team that are in charge of QA.

Is that a problem? Frankly, I am not quite sure… Based on our recent experience, I get the impression that there are ever so slightly more defects that we are surprised with when going to production. It’s not that we would have fixed every single defect prior to go-live previously, but I do think that we usually  found them beforehand and were able to mitigate that risk by communicating with our user community.

So, I do ask myself the question: Is the constant push for production ready code at the end of every sprint putting too much focus on quantity at the expense of quality?

Backlog Defect.

On my project, I am constantly challenged with trying to combine and separate our product enhancement backlog from our defect backlog.  Now, if you read this carefully, you will probably think, wait a minute, how can you combine and separate the backlogs? Exactly that is my conundrum!

In principle, I am of the opinion that it makes more sense that the two should be combined, so we can streamline the priorities, the sequence in which we should tackle defects over enhancements and so on. However since there are different teams of people that work on the different requirements and features it is difficult to get to one master list that everyone can work off, as it blurs the lines between responsibilities which can lead to some unnecessary confrontation.

And then there is the question of continuity. Just creating one big list at one point in time, so we have a complete view of what is on our plate, is definitely do-able, the problem starts when it needs to be maintained as such. Suddenly the list morphs into several independent lists, updated by different teams and prioritized without cross referencing other items, that is very difficult to keep track of and control.

In our project, particularly as we have to engage external vendors for some of the work we do, both to support our enhancement work and to help out with certain defects, having a disparate backlog causes a bunch of complications that make it difficult to communicate to the “outside world” with one product voice. What seems to happen is that various teams have parallel conversations that are not necessarily aligned internally, which is complicated and confusing – for everyone involved.

It’s a big challenge and one that I hope to find a good solution for – how do you stop your backlog from becoming a defect?!