Team.Chat – episode #4 – review

We install a fresh build onto several test phones and put them in users’ hands. The users then tap through the apps’ new features and the discussion starts. We collect first impressions, discuss everything and anything about new features and other parts of the app, and gather feedback with new ideas that come up. The exchange of all that is free flowing and completely unhindered by any formality. People freely move around the room to enter discussions they’re interested in, they talk, take notes, and sketch ideas onto pieces of paper. Like a small town marketplace we have here in Croatia. We take note of everything that seems important – in probably the most unstructured format ever – feedback, feature refinement ideas and all kind of user stories. On average we write down 2 or 3 new stories per review. But what we’re most concerned with is user comments that gives us deeper insight into how they think and behave. In the end, we show them our backlog and explain the content and ordering.

How did we get to such a nice review?

First, a few words about the space in which we hold it. Two high bar tables and a few stools, one giant TV, lots of natural light and an overall comfortable and relaxed feel. It’s fantastic. It’s not designed and built for our reviews, it’s rather a large multipurpose space. People mostly use it for small chats and meetings, to relax and play pool, foosball and darts.

How did we decide for it? Accidentally. When we started I wanted a laid back space that is comfortable and that particular space was the most obvious candidate. Did I have criteria for selection? Yes – “comfortable”

Ok, is comfort the only criteria?

The looks and the feel are just one minor thing in the space. What matters most is its floorplan.  It’s well known that it affects what positions people will place themselves into, which affects how they communicate. It’s very different if people sit on both sides of a long slim table opposing each other, or if they’re side by side around a round table, or if they gather around a high bar table. Also, sitting is very much different than standing, or sitting on a high chair. I’ve seen many people that just don’t want to get up now that they’re seated so nicely. Some are even blind to the possibility of getting up and drawing that one important bit on the board because they’re so focused on the matter. The brain turns a blind eye. Its facilitators task to find and arrange the space that will enable participants to step into the discussion whenever they want – seamlessly and without any friction. It’s very interesting how long some people take to realize that small factor. For example, it took Pixar 10 years to get rid of their perfectly designed, picked by Steve Jobs, long meeting table.

Very interesting, but it’s not the space that takes all the credit, right?

Of course not. You can have the best space in the world if people don’t trust each other. And that’s where we the people take the rest of the credit The meeting itself wasn’t like that from the start. The team attitude went from “we don’t need their input, we have quite enough experience with chat applications”, across “they have too much ideas, they’re hard to implement, there’s no need to listen to them every two weeks – we can do it less frequent” to even “could just the PO talk to them so they could leave us alone?”. Really worrisome.  It took some time for a team to realize that users are not scarecrows but normal people. Normal people that are truly thankful and happy when we add some new feature they’ve asked, or improve existing, and with which you can move from take-take to give-give dynamics.

Give-give?

Yes, when people don’t know each other and don’t trust each other the relationship tends to be on the take-take side. The team takes into account only feedback that is easiest to acknowledge and implement (sometimes even ignoring the rest), the users want ever more features, and the divide starts to happen. Out team wasn’t an exception in that regard. I’ve heard team members saying – with justification but rather hastily – things like “that very hard, it can’t be implemented” and therefore killing users’ ideas way too soon. We’ve talked about that on retrospectives and outside them, and since tried to adjust our language and attitudes during the meeting. If we can’t step into both of our users’ shoes, maybe we can step at least into one. I think we’ve done quite a lot in that regard, because review is the meeting in which we just collect the stories. Refinement and commitment comes afterwards. The most of what we can do at the review is: “we got it, wrote it down, now you know how we view the story from a technical and product perspective, we’ll dive in it deeper in separate sessions and we’ll see what we can do”. We cannot commit to a story during a review, and certainly not say when it will be done. The review is a meeting on which we focus on listening and understanding our users. That significantly loosened the attitude towards new ideas and opened doors for a rich and positive communication. The users quickly accepted that attitude, despite us putting them in the passenger seat.

After a few sprints – when the users really saw that we want to deliver the best possible set of features – they became truly thankful. When the team wants to deliver the best product then users want to deliver ever more useful feedback for the team. They think twice if they want to burden the team with overly complex features and those of highly questionable value, and are more likely to meet in the middle with developers.

That’s all very nice but your users must have unrealistic demands from time to time, don’t they?

Here’s an example. One of our users once wanted to make some updates to a screen for starting a new direct chat. She had a very specific idea of the screen, drew the layout, buttons, labels and everything for us all by herself. Talking about intrinsic motivation The original screen truly wasn’t the most intuitive one, the team confessed, but our app still didn’t notify the user when a new message came. Suffice to say that no one complained that that story didn’t end up at the top of the backlog. We took care of that screen in later sprints, before which we talked with users once more and gave them the opportunity to change their mind.

The other story was the one with notifications. Since we’re developing an application that connects to a chat server that’s not under our development control, we’ve hit some limitations that required us to really pull up our sleeves. It took a couple of sprints to get it done, as we had to dive deep into the server code – which by the way is built with a framework we don’t know in a language we don’t speak The same situation happened when we tried to connect to a custom authentication provider. Our Product Owner however, was very adamant with requesting that feature and team ultimately delivered it – after much hard work.

Sprint fail

Yes, we did fail a few of them. The ratio of failed vs successful ones is about 50 – 50. Does that worry me? Not at all. It’s exactly as it should be. And I already hear the questions coming: “Why not, isn’t that the goal – to deliver everything you committed to each sprint?”, “Why didn’t you work on how you do your commitments?”, “What did your sponsors say?” etc. All those questions are very important, and indeed they were important to me too. But not every one of them equally in every part of our Scrum life. Do we want to deliver on our commitments every sprint? Of course, but we first want to understand our users and their stories thoroughly. Do we want to commit more realistically? Yes we do, but we first want to jell as a team. Establish trust, have a healthy culture of conflict etc. Do we want to please our sponsors? Yes, but what we want even more is to improve our way of work, and to learn as much as possible. Doing that means that we occasionally fail a sprint.

Having a sprint succeed really is important to us. But it’s not the end of world if we fail – it’s rather an opportunity to learn something new.

In the next episode I’ll talk about the product owner role. Stay tuned…