Aligning Autonomous Teams

Pedro Couto, Chloë Humby, Wilson Mália, Marcelo Knakiewicz at UXDX Community: Europe South. Video: https://www.youtube.com/watch?v=MmgIcy5x9zg

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introducing team Eagle

[00:00:00] Noemi: I would like to welcome Wilson, Chloë, Marcelo and Pedro from Volkswagen Digital Solutions. They will work through how they build autonomous teams, the process, the direction, the approach. To introduce the team, I will actually pass it on to Catherine Madden, our UXDX co-founder. So welcome everyone.

[00:00:25] Catherine: Hi all, and thanks Noemi. I wanted to set the scene of this talk today, because we have done a lot of things at UXDX, from debates on stage right through to a national beatboxing champion beatboxing his way through a QA talk, and the Volkswagen Digital Solutions team today have risen to the challenge. What we wanted to do with this conversation was to remove the moderator and have a more fluid conversation between a cross-functional team, being Volkswagen Digital Solutions, to talk about their everyday tasks, and give them no specific parameters. They know their product best. We've given them some specific criteria in four different areas. We do not know how this conversation will go, but we encourage you all to ask them the questions that you want to know, that works within your team, based on how the conversation is going. We hope you enjoy this, and I am going to hand you over to Pedro, Marcelo, Wilson and Chloë. Good luck, guys.

[00:01:35] Pedro: Hello everybody, hope you all can hear me. My name is Pedro, I'm a product manager at Volkswagen Digital Solutions. I have here today Marcelo, also a PM, Chloë, a designer, and Wilson, an engineer, and we are team Eagle. We have a cool name, but we also have a cool product, and we're basically an autonomous team. I think that by saying that we are an autonomous team, we may already have some questions, like what is an autonomous team, what are the boundaries around that. Marcelo?

What an autonomous team means

[00:02:11] Marcelo: Yeah, maybe this is a good way to start, right, Britto[?]? What are your thoughts about being autonomous? What are your considerations on that? What do you think that autonomous teams mean?

[00:02:23] Pedro: We were discussing this before, and I think that I don't know if everybody has a clear picture of what an autonomous team is, but from our perspective an autonomous team is a team that is empowered. By empowered we mean empowered to make questions. We should always be making questions, always trying to understand the why of things and trying to reason and make sense out of them. By that, as a PM, I mean to feel empowered to build the right thing, to know why I'm doing what I'm doing. For a developer I think it's to build the thing right, it's to choose the specific tech stack, to test it the way that it should be tested, to scale it the way it should be. And from a design perspective, maybe to make it sexy, to make it desirable, to make it functional, to make something that the users actually love. We can only do that by being autonomous, by being authentic, living our virtues, and having the possibility to actually make questions in this product that we are working on. Go ahead, Marcelo, sorry.

[00:03:30] Marcelo: No, I was just going to say that with the idea of being autonomous, of course, it's quite easy to lose track. How do you make sure that you are on the right direction? Who sets the direction? What do you do to be sure when you are on the right direction?

The car tracker problem and who sets the direction

[00:03:52] Pedro: Before we start diving into that, we don't want to go around the topic, we actually want to go through it, and by that I mean tackling the problem that we are currently solving. What we're building is a car tracker. The name and the product speaks for itself. We're working at Volkswagen, and the group and all its brands and the dealerships, sales people, they have the problem, the challenge, to tackle and to track the vehicles. Usually they're selling 20 cars per month. A car usually takes three months to arrive. After three months, when they're arriving, you have there 60 cars, you're selling another 20, and this can be a challenge, this could be overwhelming. You have a lot of people calling you, where's my car? You have to call people, you're bonding, it's a trust relationship, there's money involved, so there's a lot going on there. And now, who sets the direction? I think Chloë can answer that in a clearer way.

[00:04:52] Chloë: I can answer that for you, Pedro. In terms of who has the direction for our product, I'd say it is definitely the user. The user is at the center of the problem that we're trying to solve, because we're not the user. We're solving a problem for them. So we put them at the center of our process, and by that I mean we follow a user-centered design approach to tackle the problem. As Pedro said, it was very specific. We had this hypothesis that we had discovered that dealers, specifically the car sales people, were having trouble tracking orders when they're placed in the factory. So what we did, we followed basically a design research: we did analysis, prototyping, testing, to really unpack the problem and to deep dive into it.

[00:05:41] Chloë: We had the hypothesis, which was basically our overriding research question, before we went into deep dive research, which was basically conducting user interviews. In the age of pandemic we were doing it all online, and that was quite a challenge, but it was also an advantage in that it gave us access to users in different countries. So we spoke to many different car sales people in different countries and got various different insights and key findings, which we then brought back to our office, which is basically our Miro board, which we love to use and collaborate on as a team. We affinity mapped the key findings, got some golden threads, which were some really interesting insights and quotes from our users, which we then prioritized in terms of what was key.

[00:06:29] Chloë: And then we went into ideation together as a team, and by the team I mean developers, PMs, together, ideating to try and tackle the problem. We started with Crazy Eights and getting all our ideas out of our heads onto paper before going into wireframing. Wireframing was low fidelity, we sketched out the wireframes before going into prototyping, which we then tested also remotely with the same users. We did usability tests, got interesting insights in terms of task failure and pass rates and SUS ratings from the users, which we're now using to drive our MVP for this product. So to answer the question, just to sum up, the user is basically who sets the direction for the product. Is something to add?[?]

Where the developer fits

[00:07:21] Marcelo: Yeah, and you can see by what Chloë is saying, basically this is something that we support a lot here in Volkswagen Digital Solutions. We want to validate every single step that we can make. We want to validate stuff. So in Chloë's answer you can see that in the very beginning they are validating the problem with the research we are going to, understanding what is going on, if the ideas that they have, the problem that they are thinking, is actually a problem. And once they come up with the idea, then they validate the idea with the prototyping. This is quite good. I'm wondering about you, Wilson, how do you see it as a developer in this whole process? Were you part of this research, and how valuable do you think that your presence there was?

[00:08:10] Wilson: Sorry, seems I was muted. This is the lovely part of having a team that we have, bound to every role, bound to each other, because what happens is that the developer, I know it's known for writing code, but it's way more than that in an autonomous team, because we are part of it from day zero. We go to do the interviews, we take notes, we discuss ideas. So it's more than just being a developer, it reaches many, it has a larger reach. That helps a lot. The fact that I have a bigger perspective of what the user wants actually makes me care more about what I'm developing, so it actually helps me a lot on my day-to-day basis, and that's a really important thing to have in mind all the time.

Over-communicating, inceptions and anti-goals

[00:09:14] Marcelo: I can understand from what you're saying, basically this helps you and maybe the whole team to work towards the same goal. Pedro, maybe you can answer that. I believe being over-transparent, or maybe over-communicating, is a good way to be sure about that.

[00:09:33] Pedro: Yes, absolutely. And also not only that, I think that one thing that we're also here to talk about is the challenges that we have and the lessons learned that we have during this process, contacting dealers. We all talk a lot about talking to your users, listening to your users, but sometimes this could be very tough. For us it's the same pain: we act like a startup, we talk like a startup, we behave like a startup, but we are not a startup, we are Volkswagen, a very old-school company that is very accustomed to working with certainty, to have everything in a waterfall-ish way, and now we're having things that are going a different way. People before said a lot about stakeholder buy-in, actually believing, because once you have everybody seeing those problems arising, they start to advocate and trust the product and also own the product, the problem that we are trying to solve, and this helps us to get closer to the user.

[00:10:37] Pedro: In terms of how we make sure that everybody is towards the same goal, being over-transparent and over-communicative, I think now that we are distant and remote, even more, because we have to be aware of what's going on in all the ends of the product, and everyone needs each other. We cannot build stuff and write stuff and throw it over the fence. Things have to happen in an organic way, and we do it on our standups, on our retro, and also in an inception. So after scoping a problem, having an idea of what we are trying to solve, where we're looking at, and after doing the discovery, framing, like Chloë mentioned, so coming up with a lot of problems, then prioritizing the problems, and then coming up with a lot of possible solutions to those problems, and then closing it to a few feasible solutions.

[00:11:33] Pedro: In the inception we have this clarity of what is the goal that we are trying to achieve, what is not a goal for this first cycle, and what is a non-goal or an anti-goal, something that can be a threat if we try to pursue it. By having that, everybody is focused on the outcome. This is what we expect to happen, this is what we're trying to move. Now, how do we make something that works, that's sexy, and we can build and we can iterate, and the rest is just build, measure and learn. We have to throw a beacon that will be enough to satisfy our user and allow us to learn and build something better. I think that by doing this we're all together in this journey of what is our objective, which is to make something that is helpful and to learn, and everything that we do is towards that goal. So it's open-ended. This is how we go in terms of having a goal, and that's why I started with questioning and asking why.

Pairing, and how we know the work is good

[00:12:37] Marcelo: Yeah, just a bit of context before I say what I'm going to say: I'm not a PM of the same product that Pedro is talking about. One of the things that Pedro said reminds me of one of my last inceptions here. We work very closely with stakeholders from the business, and I remember, once we started the inception, the stakeholder had a completely different idea, and once we reached out, the situation about the anti-goals, non-goals and goals, it was clear that the whole team was walking in one direction but the main stakeholder was walking in the other direction. So the inception itself helped us a lot to align ourselves with the stakeholder and the team itself, and find a common ground that we could walk through. That also makes me question, maybe Chloë, how are you sure that whatever you are working on, you are reaching a good result, you're reaching some excellence on your work?

[00:13:41] Chloë: Yeah, so one thing I really like about the way we work, and it's the first time I've ever worked in an environment where we pair, so designers pair, and so do developers, and PMs on certain projects also pair. That means that there's two sets of eyes, two brains, tackling one problem at the same time. So it's highly collaborative, lots of fun, and we're tackling something together. It's kind of like a ping pong game. My design lead and I always challenge each other and try to basically make the design better through that. But then also, as a part of the process, we try to test and validate ideas. If we don't have access to users at the time, we validate it with the team in terms of doing design critiques, so we try to do that quite often. And then also, in terms of excellence, it's doing usability testing and validating what you're building with users.

[00:14:42] Marcelo: Yeah. And maybe, Wilson, does the pairing also create the same scenario for you?

[00:14:47] Wilson: For sure. I'm going to repeat what Chloë said: pairing is like the key word of all of this. We live by the Extreme Programming mantra, the methodology. We work in pairs, we do test-driven development, and all of these sum up to make us comfortable with what we deliver at the end of the day, because we have two people working at the same thing. And like Chloë mentioned, the ping pong is also a way of working in the developers, where someone is writing tests, someone is writing the code, and you ping pong, and at the end you should only implement what is needed to achieve what you want. Because sometimes, if you are not restricted and you don't have a specific thing that you want to come up with, that's normally the part that Pedro ends up doing, grooming the stories beautifully, so when we pick one we know exactly what we need to do. Doing exactly what we need to do to achieve that goal is the best thing that we can do.

[00:16:04] Wilson: Because at the end of the day, if we finish a story we push it and the user will have that as soon as the pipeline runs through. And since we work with the base of testing as much as possible and making sure we are safe, we can actually do trunk-based development, and that means, in rough terms, that if we do a push, yes, the user will see that happening as soon as possible, as I mentioned before. And also, it's very cool that the team is all together, in a sense, because even today we had some questions about design, and since we are so close we could actually say, Chloë, can you come and pair a little bit with us? And we were discussing ideas. So this creates a great dynamic where developers are not just code monkeys, they're a little bit more than that. And in itself, because we are a small family at work, an autonomous family in a way.

The sorting example, and the shift away from waterfall

[00:17:12] Pedro: I think we have a good example for everybody out there listening, to understand what we're talking about. We had this prototype where we're showing people the customer name, the vehicle, the ETA, the status, all that, and we're trying to make a good experience. We know how he deals with it, but we don't know everything. We're not selling cars ourselves. So we showed them the prototype, and we were designing some ways to make it easier to find stuff, so search bars, filters, filters by name, and this and that. Once we showed that to the users and we're trying to identify if they actually would be able to use that and how they would feel about that, what most of them did was click on the labels, on the headers. So on customer name, they were clicking there on customer name; on vehicle, they went there and clicked on that. The reason why is because they're used to working with Excel spreadsheets, and they sort things by clicking on the headers.

[00:18:11] Pedro: So we were not aware of it, we didn't design this experience, but having in mind that our users expect this kind of behavior and that this will be helpful for them, for us it's a low-hanging fruit. Wilson as an engineer can say, yes, I can make it work, I can make it visible. Chloë can say, yes, I can make some good designs and good ways so he can understand what's going on. And we go, okay, it makes sense, this is what you should do, and this is why you're empowered to build the right thing. So if someone goes there and sees, hey, why did you do that? It's not because Wilson wants it, or I want it, or Chloë wants it, or because the stakeholder showed the PowerPoint saying that he wants it. It's because it makes sense.

[00:18:51] Pedro: This also goes together with a question that we received here from the audience: how long did it take to transform from waterfall to agile? We didn't transform yet at all. I think that we're still ongoing. Agile is like a virus that is inseminated inside a company and is kind of spreading, and this is the idea. When we run this kind of experiments, we get to tell business about it, and they get proud, they actually go, this makes sense, I'm not spending money on things that I shouldn't, I'm doing things that work, I'm doing something that the user actually wants. And they take it inside and share it with everybody else, and this is how the transformation is going.

[00:19:39] Pedro: It's a different mindset, it's a shift, but it's a very organic thing that we are happy to be part of, because at the end of the day we get to learn a little bit with them, with the knowledge that they have on the business, and at the same time we can teach them new ways to solve problems when you have to deal with a lot of uncertainty. Remember, Volkswagen: if you are building a car, you know the exact steps that you have to follow. It's like a recipe, you have the product line, it's there. About building software, it's not like that, it's very emergent, and we have to make decisions based on what we face and what we know. So yeah, it's pretty cool.

Ceremonies, critiques and falling in love with the problem

[00:20:21] Marcelo: You can see from Pedro speaking that he loves what he does. His eyes are shining. This is also one thing that I love since day one, the freedom that we have together. Doesn't matter the team, the freedom that we have to take decisions and to guide us, to guide the team itself to the right direction. But even with this freedom, we always need to create some kind of tools or mechanisms to support the routine. I'm wondering what kind of ceremonies, or what kind of routines, do you guys have as a team that helps you to be sure that you are doing things on the right track?

[00:21:10] Pedro: I think that we are showing things to each other and discussing it. For designs, for example, Chloë builds stuff and then she lets us critique it, and takes us to a design critique to co-create that. Also, an experiment that we did, the Crazy Eights: we folded, Chloë taught us to fold the paper into eight parts and then draw eight screens that we were kind of expecting and envisioning for the product. Based on that we could see, okay, if our minds are creating something that goes in the same direction, since we are all exposed to those same things. And we're always questioning each other when we're building stuff.

[00:21:53] Pedro: I remember, for the research, I remember asking Chloë that I feared that I might fall in love with the solution, and I was like, we have to fall in love with the problem, please make sure that everything that we are following here is following the problem. And then we break down the hypothesis that we have into the questions that we want to make. So the hypothesis that we had back then was that the dealer, the salesperson, wants to know where the car is; the salesperson wants to be updated; and the salesperson wants to share, after he is aware and updated of things, he shares. And we're trying to push things and uncover and unpack things in that direction.

[00:22:34] Wilson: Pedro, just to add to that, I think it's important also to take notice of one thing. You can love your product, there's no problem at all in that, but in the end you're not the user of your product. So it's always important to step aside and know that you're not doing the things for you, you're doing them for someone else, you're helping someone else gain time or just make his life easier. I think that's the satisfaction that we get in the end. It's not the product itself, because that's for them, it's the joy on the face of the users that are using what we've built. And we got a glimpse of that on the usability testing. They were very, very interested with the solution that we proposed and seemed very happy, so it's a nice quick dog crow[?].

Backing decisions with data

[00:23:33] Marcelo: Yeah, it's very cool. And just because I know especially Pedro is a very data-driven person, I'm wondering if you support your decisions and maybe data is something very important for you to take decisions. Maybe, Pedro, if you want to share something.

[00:23:51] Pedro: Absolutely. I believe that in God we trust, everyone else must bring data. This is how we're going to rely our decisions. It's good to say that I think that everybody has opinions, but at the end of the day, if you're making a decision on a table based on my opinion, or Marcelo's opinion, or someone else's opinion, that might not be the best way or the best opinion that we have there. So we try to do things based on data. Some PMs think that collecting data only starts after you throw the product out there, but like we're saying, the prototypes and the usability tests, they generate a score. So you have a system usability score, and then we have the tests that we want the users to perform, and we see, okay, this test passed, this test didn't pass. So we're seeing how useful and usable the product actually is, and this already gives us some kind of idea where we're going with our solution.

[00:24:52] Pedro: In our case we got 85 percent, 85 out of 100. It is very good. It means that in this kind of uncertainty, when there's a lot of things that we don't know, we think that we got the problem right, we think that we got the solution right, we throw it out there, and we scored at 85. This is great. If we score 100, or 90, or 95, usually you took too long to put it out there, you're holding it to yourself, and this is the idea of fail fast too. So 85 is good for us, because we didn't expect to get 100. We actually want just to throw it out there to learn. And based on that, for example, we still got time to put the sorting methods that the users intended to use into our product, and shrink down the MVP scope that we have on visions.

[00:25:40] Pedro: So these were data-driven decisions. Why did we take out the cards and only kept the list? Because data, the users showing that. We collected their inputs, quantitative and qualitative, and it doesn't make sense for the MVP. And the method, for example the sorting method, why did you put that? Because data backed us up. The customer will give us that, and the user research that we do, it's this conversation, to try to get this data. And even sometimes when you have a product out there, you have your KPIs, revenue, engagement, all that, sometimes it's hard to make sense out of them too. Sometimes we have to kind of torture data to make it speak to you. But after a while, if you really try to make sense and understand the context, you can actually take good decisions. And always sharing with everybody, everybody feels much more comfortable, I guess, and more autonomous, when following something that makes sense, that is straightforward, it's out there. You don't have to believe me, you only have to look at what we're doing in terms of data, and then things go organically.

[00:26:52] Marcelo: Data is also a good way, just going back to the question that Gary made, whether this process should become agile. Data is also a way to support agile. It's a good approach, because you can show numbers to your stakeholders, to whoever you need to show numbers to, to tell them, look, it's not because I have everything planned that I will have a good result at the end. But actually, if I just cut it in very small pieces and deliver value, you can see the data flowing and the results becoming better. So again, it's a good way to support agile, of course.

Key takeaways

[00:27:37] Pedro: Yeah, summing it up. Go ahead.

[00:27:41] Wilson: No, I was just saying, the more you delay to deliver something to the final user, the more risk you're going to take. That's a good thing of doing quick iterations, or short iterations, and seeing how it stands and then iterating. I think that's a little bit of the beauty of agile on this: we don't need to provide you with the best application on day zero, because that might take years. If we provide a minimum livable product after a few months, we are starting the ball rolling, and we can actually make something that will be exactly what is needed in the end. And that's cool.

[00:28:27] Pedro: Yeah, I think that a key takeaway from all that is: try to place good questions, and don't be afraid to ask questions inside your team, outside your team, to your stakeholders. Don't be afraid of questions. Questions will help you. We've been accustomed to be rewarded for right answers, but now we also should go for the questions that will get us to those answers. This will help everybody in the team to place accurate paths. This is what we're having, it's bets. We bet that this thing will work and this will be useful, and this is enough to test this hypothesis that you have in hand.

[00:29:10] Pedro: And always remember that balance. We always talk about balance, balanced teams, we have to be balanced in our lives and all that. But balance is not actually something that you find. You don't find balance, you create balance, and this is what you should try to do in every product and every development team: try to keep the balance between what we're doing, why we're doing it, how we're doing it, and have it open for questioning for the team. Sharing is caring, remember that always. Every opportunity that you have to show your product or something like that, show it. I would love to show it, I bet Chloë would love to show the designs, and Wilson would also love to run everybody here through the code. Unfortunately we're not allowed to do it. But yeah, these are the key takeaways from my side. Anything else?

[00:30:02] Marcelo: I think that we've reached our time, so I'm handing back to Noemi. Thank you very much everyone, and hope you enjoyed. Thank you all.

[00:30:17] Noemi: No, I would like to thank you, because this conversation was extremely insightful, and I'm so happy to see your synergy. It's really something that is precious to work with.