I'm Tired Of Arguing Over Product Development Methodologies

Jussi Ahola at UXDX Community: Helsinki. Video: https://www.youtube.com/watch?v=JGjkyYae6Bk

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.

Undermining trust in methodologies

[00:00:09] The name is Jussi. I self-identify as a designer. For the past years I've been doing most of my work at Vincit, where I consult clients. Also, a couple of years back I founded a side hustle called Deaf Division [?], which is a prototype [?] hacking boutique. And actually, just last week I founded a new company where we're trying to fight back against global warming, so wish us luck there. But that's not what I'm going to talk about today. I'm a bit afraid, or scared, that you might be upset with my talk, or that you're going to hate me at the end of it. That's the risk that I'm going to take, because I'm going to undermine something that many of you have probably learned to trust: something that they taught you at school, something that you've probably read a few books on, something that's really explicit. I'm going to replace it with something much less explicit, something that's perhaps much harder. But I think at the end of the day it pays off, and you're going to be a better designer, a better developer, a better product person because of it. The thing that I'm going to undermine is unwarranted trust in product development methodologies, because, as I said, I'm sick and tired of arguing over them.

The six-minute daily

[00:01:40] Let me start off with a story. A friend of mine recently started in a new job. It's a big company, so the first few weeks are just her settling down, but after that she of course starts the real work, and she's handed a project. She works in a product owner/designer hybrid role. She meets all the developers, the other designer in the team, the architect, the key stakeholders, does some research and so on. She's really on a roll, and there's a deadline looming, as there always is. It's not that far away. So, being a good product owner, she sets up some routines, and the daily stand-up meeting is one of them. You all know what a daily is. I heard it's the six-minute daily stand-up, not a five-minute but a six-minute daily stand-up, in some traditions. I think this is a tradition from the Scrum books, or the Scrum culture; that doesn't really matter here.

[00:02:48] They start off with the dailies, and the first few weeks go by nicely. The dailies are short: six-minute, eight-minute, 10-minute dailies. Okay, everyone is happy. Then a few weeks onwards, while she's still new in the job, some of the developers are working on this one corner of the product that isn't really that well defined. It's still high level, and they really have to discuss the nuances of it. They have to define this corner of the product; they have to understand what they are building and why they're building it. At the daily meeting this takes some time. It takes 30 minutes, it takes 45 minutes. The developers are involved, they're actually enjoying this, everything is beautiful, and they make good progress during that meeting. It's not a six-minute daily; it's a 45-minute daily.

[00:03:45] That's when the architect pulls my friend aside and scolds her: that's not how we do dailies. A daily is a six-minute stand-up, and you shouldn't confuse the developers with all this pondering over product decisions. The developers need to be given well-defined tickets that they can just turn out, one after another after another. I can see where the architect comes from. He's probably read several Scrum books, and he wants to be a good architect. He wants to do good product development. There's a rule that he adheres to, a rule that is an important one for him. But what's wrong here? Does this feel wrong to any of you? Because it sure feels wrong to me.

[00:04:38] I think it's against a lot of what I understand about human motivation, about how top professionals like developers, who really are highly skilled people, are motivated and how they want to work. I've found that the best developers really want to understand the thing that they're building. They want to understand the needs behind it. They're not happy just churning out ticket after ticket after ticket. So it's in total contradiction to what I know about human motivation. Also, there's this really important thing that I'm going to talk about later on, about having a shared understanding. The developer needs to make all these micro decisions down the line. Even a well-defined ticket won't have all the nuances in it. If the developer doesn't understand why we're doing this, for whom we're doing this and what we are actually building, the chances are that those micro decisions are going to be bad news.

Methods versus principles

[00:05:44] The field that I work in, let's call it the digital development world, is of course full of this stuff. Any familiar ones there? Yeah. All of these have their fanboys and fangirls, their adherents and so on. If you want to pick a fight during a coffee break with a senior colleague, you can take a topic from here. If you want to spend some time online, not that well spent, you can just start a fight there and mock a methodology, and you're probably going to have people fighting back. It's a good pastime for you. And I have nothing against using methods. I think they're intended to be systematic ways of succeeding, of getting something out of the pipeline, if that's what you want to call success. The thing that comes out of the pipeline might not be the thing that you should have made in the first place, but something comes out.

[00:06:48] Methods are also nice to write books on. They're nice to sell stuff on. They're nice to organize conferences on, which is okay; nothing is going to stop that. But I think they shouldn't become these gods, these spirits, the shrines that you worship. I don't think methods are wrong, but don't use them that way. There are probably some bad methods out there, maybe some of these; I don't know all of them in a detailed way. But I'm sure that there are a lot of good methods out there. And here's the secret: a good team adhering to some other things will make good products using any of the good methods. The method isn't really the showstopper. It's always something else. To me, there's something that should always transcend a method, something that's more important, more sacred, and that's what I like to call principles.

[00:07:54] Going back to the six-minute daily example, I had a similar experience myself when I was in a product owner role in one project. We had the dailies, and they were short in the beginning. Then we had these almost philosophical discussions on our product, making really hard product decisions that even had ethical implications, and the dailies started taking a long time, 30 minutes instead of five minutes. I felt bad, because being a good product owner myself, and I haven't read many Scrum books or anything, but I know about the six-minute daily, I felt that I was taking too much time, that I was creating waste. I felt bad, but then I realized that the rule, the method of the six-minute daily, isn't that important. What's more important to me is a very specific principle, which I'm going to talk about a bit later.

[00:08:49] I tried to visualize it in this way. I'm not sure if it's a good visualization for this or not. The balls are different teams building different products using different methodologies. They're all good methodologies, not any of the bad methodologies; they're cute methodologies. The walls of the funnel are principles that keep pushing the thing in the right direction, that keep nudging the behavior in the team in the right direction. You can start with any of the cute methodologies and end up with a good product if you have the right principles in place. But if you don't have the right principles in place, it doesn't matter which one of the cute methodologies you choose; you're going to fail anyway. The colors are just nice colors that I like to have there. I've never heard of a team that failed because they chose the wrong methodology, but I sure as hell have seen some teams who struggled because they don't have the right principles in place. They don't have anything to move them forward, something that will transcend the methodology, the rules that they're playing by. So what I'm suggesting is: always choose principles over methodologies.

Principle one: shared understanding

[00:10:25] To give you a taste, a feel, for what I mean by a principle, I'm just going to list three of mine. It's not a full list, it's not an exhaustive list. I don't have an exhaustive list. I just started thinking about this a few weeks ago, when I started preparing for this talk. But I think I've got a few principles nailed down that I like to adhere to. These are quite personal, actually. Back to the six-minute daily example. Had I decided to stop the dailies at the six-minute mark and told everyone to go design their stuff or code their stuff, and let's not go on with this anymore, I would have adhered to the method. But the thing that transcends the method for me is a principle: I want to achieve shared understanding. I want there to be a shared vision in the team, because people who share a vision, who share understanding, will fly at great speeds, and they will fly in the same direction, which is great.

[00:11:34] How do you cultivate shared understanding, or shared vision? I think there are a lot of ways to do that. The extended daily that I just mentioned is one of them. Also, in most cases when I do user research or usability testing with test people, I take a developer with me. You can't escape that; you have to come at least once every six months or something like that. That's a hard rule, and I like to explain to developers that this is why we're doing it: I want you to share the pain, I want you to share the understanding, I want you to share the vision, because we'll go far when we do that. So involve people. It's a funny situation that many of the developers out there never actually see the real people using the product. What's up with that? How wrong could that be?

Principle two: start off right

[00:12:36] Another principle: start off right. Beginnings are extremely important. If a person is put into a pitch-black room and there's a pinpoint of light somewhere on the wall, there's this illusion that the pinpoint of light starts moving. I think this is called the autokinetic effect. In some research settings, people are asked how far the light moved. The answer doesn't really matter, because any answer is going to be wrong, of course; the light didn't move. It gets interesting when you place groups of people into this room and tell them to say their estimate of the distance out loud. The group starts to converge on the number that the first people said out loud. So group A says it moved three units, centimeters, whatever; group B says it moved 20 centimeters, the units don't matter; and the groups converge. They are of a similar opinion. And if you bring the same people back in a year's time, they will still converge. It's funny.

[00:13:59] Where it gets even more interesting is when you start changing people in the group, people leaving, new people coming in. They still converge. It's in the group's DNA, almost. It's part of the tradition. Even when all the people that were in the group in the beginning have left and all the people in the group are new, they still converge on the same numbers. So what does this tell us about starting off right in projects? I think it's massively important. Sometimes I've been asked to help teams that are struggling with some product development issues, with how the team functions, and sometimes it even feels like a lost cause. The bad tradition in the group is so strong that it's really, really hard to change. I'm not saying that you shouldn't try, but it's really hard. So starting off right is an important principle.

Principle three: care

[00:15:09] The last of the principles I'm going to share today is a really important one: care. Care about the problem you're solving. Care about the people, the planet, the animals, the causes you're solving it for. If you don't, you have to ask yourself: am I the right person to solve this thing? Care about the people who are solving the problem with you. And if you see suboptimal work, care enough to point to it and say, "Is there a way that we could improve this?" So care, care and care again. That's a really important one.

[00:15:56] These were some of my principles, just three of them. Not a full list, not an exhaustive list, but something that has really helped me in my day-to-day work and in life in general. As opposed to rules that I worship, these are the spirits that I try to keep happy, and if I keep the spirits happy, they will keep me happy. They'll have my back, and I'm good going forward. I don't think you can carbon-copy my principles. I hope you can be inspired by them, but don't copy them. I think you're going to have to arrive at your own principles. People in the team that you work in have different principles, and you're going to have to understand those principles on a deep level and accommodate them, and agree as a team: what are our principles? I might have some that you don't share, and we're going to have to find common ground on that to be able to move forward.

[00:17:03] I'd like to leave you with a quote. I think it's often misattributed to the American 19th-century poet Ralph Waldo Emerson. I think it was probably actually said by another Emerson: Harrington Emerson was a prominent management consultant in the early 20th century. He said this: "As to methods, there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble." I couldn't agree more. So always choose principles over methods. That's everything I have for you today, so thanks.

Q&A

[00:18:02] Host: Thank you so much, Jussi, that was great. Are there any questions in the audience? Something you would like to ask regarding this, maybe how you can move forward with your team incorporating something like this? Okay, if there are no questions, I would like to ask you. You touched briefly on the idea that we need to learn about the people that we work with and their principles. What is your general way of going about that?

[00:18:24] Jussi: I think teams work best when they are tight, when they operate like a rock band, when they smell each other backstage. That's when you start learning about people. There's no easy way of doing that. As I said, doing this thing is hard. It's easier to write a book on a method that describes your rules and your to-do lists. This is a harder approach, but I think it's the right approach. Be tight, have some open discussions, maybe have a glass of wine sometimes. Just get to know them.

[00:19:05] Host: Yeah, the old-school way, basically, and how they work. Okay, has anyone thought of something?

[00:19:11] Audience: Thank you for the presentation. My question is: how do you think principles can be scaled in large organizations?

[00:19:23] Jussi: Yes, this is also quite challenging. The organizations I've been working in have not been huge; smaller ones, medium-sized. So I haven't really thought about it, and I haven't got an answer for you. I think organizations try to do that. They have their values page, "we have these values," and they're often really lame. But I think that's what they're trying to aim at with those value statements: transparency and stuff like that, equality, which of course is good. You need to have those things, but sometimes it feels a bit lame to me. So I don't know. Communication, internal and external: if you're going to make a statement about your product in an ad campaign, I think you can implicitly state your principles in the video. "Never settle," I think it's a principle; I think it's an app as well.

[00:20:16] Jussi: Yeah, you're probably referring to something, I guess. This puts me in a spot. I think the values in a big consulting company aren't that clear to me either. That's all I can say about that, I'm sorry.

[00:20:50] Host: Anyone else?

[00:20:58] Audience: Have you measured a project without them, principles and methods? What's the difference if you totally remove all the methods?

[00:21:14] Jussi: I'm not saying that methods are bad or that you should remove all of them. If you have to think everything through every time you're doing it, again and again, it's not good efficiency-wise. So there's nothing wrong with having methods, and traditions, all the things that you do on a daily or weekly or monthly basis. By all means do those. But I think you shouldn't go by the book if it just doesn't feel right. You should have something above the methods as well, which I like to call principles.

[00:22:02] Audience: About the importance of starting off, or kicking off: do you have an example of where the start was exceptionally good, or close to your own principles?

[00:22:13] Jussi: There are some tricks that you can do. I'm just giving some examples. Make some team artifacts that aren't necessarily the product that you're going to build, but make something else, like a team-internal hackfest or whatever. Hack something together. You can learn something about how you work together, how you work, how I work, what sort of issues there might be that we need to address, and so on. So make team artifacts. Go to a weekend off-site at a cabin somewhere; that is good. These are just really basic human things. I don't think there are any maneuvers needed there. Just be a good person.