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

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?

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…