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?

Scope Creep.

In any kind of project “scope creep” is a term that comes up often. Depending on the kind of project, it may happen rarely or frequently, but in my experience it’s safe to say that there is always a certain level of scope creep, or at the very least, the continuous threat that it may surface.

While scope creep is mostly related to additional development work, further testing required or perhaps another chunk of analysis previously unaccounted for, what I have observed recently is a more subtle kind of scope creep. In fact, it is not even related to the technology or software of our project. Instead, we seem to be suffering some blurring of the boundaries when it comes to our agile scrum process, more specifically the purpose and content of the scrum gatherings.

When we first started working in the scrum module, a great emphasis was placed on making sure we setup the correct cadence of meetings. As per the scrum model, we dutifully setup daily standups, regular retrospectives and sprint planning sessions and of course end of sprint showcases to demonstrate the development completed to our stakeholders for feedback.

The one meeting where I have noticed a big change over the course of the past weeks and months is the showcase. It seems that we slowly but surely move away from the true essence of showing a live demo for the respective scrum teams, so our stakeholders and other teams can see the progress, the decisions made and provide feedback on the same. Instead, it seems the meetings is morphing into more of a general project update session.

Not that getting an update on what other teams are up to is not valuable time for everyone involved, it most certainly is, however I wonder whether the scrum showcase is really the right forum or whether we should try to go back to purely focusing on the demo of new software and put a stop to this new kind of “scope creep”…

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…

Showcase Discovery.

This week my team and I are once again faced with the question: How do I showcase work done in a discovery phase? Since our team is running on a sprint cycle like the other development focused lanes on our project, we are also expected to showcase our work every 2 weeks. In our organisation, and I presume elsewhere, showcases are not only use to actually showcase the new functionality and code developed, but also to keep track of the teams’ progress, highlight risks, challenges and get feedback on future development work if needed.

Of course, we can easily give updates on our progress, highlight risks and challenges, that part is simple, no matter what you do. Where I struggle is to find a good way to actually showcase the work my team  and I have done. Demoing work completed is all fun and games when you are showing fancy new software, but it seems a bit dull when what we have a produced is a required mapping document, written a bunch of user stories, maybe drawn up some flow charts and logged our work on questions, answers and follow ups on a spreadsheet. All of this work is necessary, important and very relevant to ensure we are discovering and documenting the best possible solution, but it doesn’t make for a very entertaining showcase…

And then, there is the other, far more important aspect, that the showcases are supposed to be a forum to gather feedback, float opinions and ultimately leave with suggestions on how to make our solution even better. This part is especially important to my team, since we are working in a “pre-user engagement” environment, where our only feedback comes from internal sources, most of whom are the people attending our showcases.

So, the question is, how can we condense all the complicated discovery work we have done into a bite-sized, easy to understand solution overview that will allow us to get the feedback we need to get to the best possible solution for our product and our users? At this point, I’m afraid I don’t yet have the answer, but I’ll keep trying different things until I find one that works…

Any suggestions or ideas?