This is a transcript of episode 186 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
We discuss why daily delivery via “elephant carpaccio”—already challenging for engineers—is doubly difficult for designers, and what to do about it.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:13
Squirrel: Welcome back to Troubleshooting Agile! Hi Jeffrey.
Jeffrey: Hi Squirrel! I was looking through your Twitter feed and I noticed a series that I thought would combine into a very interesting discussion, and I thought we might talk about the three of those in succession. How does that sound to you?
Squirrel: It sounds great. I don’t know how they’re going to fit together, but we’ll find out. Let’s go.
A Difficult Dish
Listen to this section at 00:39
Jeffrey: In this first one, you said ‘designers struggle most with delivering daily using elephant carpaccio.’ Can you tell me more about what is specifically difficult for designers in this, and maybe also remind us what elephant carpaccio is.
Squirrel: That’s probably a good place to start. Elephant carpaccio is an idea from Alistair Cockburn, who wanted to explain how he delivered every hour. I’m not worried about hourly delivery, though that would be wonderful! If somebody knows how to do that, please come and tell me. The thing that I often help organisations do is deliver daily. That means every developer finishes a new feature every single day. The feature might be extremely small; it might be ‘add button that doesn’t work.’ However, if you’re delivering value on a very regular cadence, the challenge that I was observing in the tweet was that designers get lost and left behind. It’s very, very difficult for them to move to that world. Developers actually find it easier than anticipated, but designers are always challenged by this.
Jeffrey: What are the symptoms you see of this struggle?
Squirrel: What designers often have is a psychological barrier, because their training is quite reasonably about understanding the complete architecture, the complete design, the complete steps that the user will follow, because if you have a view of the whole thing, you do better. To do otherwise would be like to design the front bumper of a car and then the steering wheel and then the roof and hope that they all fit together. It’s probably good if you have a picture of how the car will be and maybe how big it is and how much load it’s going to carry. Only later do you start getting into the details of what shape the steering wheel should be. You can make it more of a cohesive design if you do that. I observe designers who are skilled and who have this holistic view react understandably when I then ask them to blow that up completely and to operate in a completely different way and to show me exclusively partial work. Maybe they’ve only done step 3 out of 12. One and two are sketched, but the rest are not. Their Figma design is only half complete. They haven’t interviewed enough users. That’s where they are and I say, ‘Great, can you show me what you got done today?’ Or even worse, ‘Could you pair with this front-end developer and could we get a version out to users today?’ They tend to throw up their hands and say, ‘You’re nuts Squirrel! What planet did you just arrive from!?’
Jeffrey: With the project I’ve been working on for a little bit more than a year, we do have developers and designers working together. We aren’t doing elephant carpaccio to the level you are, where your goal is something in production every day, right?
Squirrel: Yeah, that’s the hardcore version. I have a client who is extremely excited because they have something new every week, and that’s a big shift for them, from many months to one week. So there are different flavours and different intensities, but the hardcore version is every developer and every designer putting real results into production every day.
Daily Transparency
Listen to this section at 04:16
Jeffrey: So we aren’t using that version, but we do have a daily demo which starts with me logging on to our production site and asking the question, ‘So what’s there to demo today?’ As you said, it can be something very small. Now, there are times when the daily demo showcases things not actually live and production. Perhaps it’s behind a feature flag or in test but hasn’t gone through the pipeline to make it to production. There are of course also days where due to meetings or other priorities, there wasn’t production work being done. Over the course of a year it is normal that there would be days where you’re doing other things like paying down technical debt, where you’re making conscious decisions of what you’re going to work on. Work you know is not appropriate for a demo. That’s fine. But most days there’s something to talk about in production. Once we’ve talked about production, we do then ask if anyone else has work to share, and that’s really open to the whole team. It could be designers showing something partially completed. ‘I’m still brainstorming this, I have three different mock-ups and I haven’t really decided which one to go with yet. I’m experimenting with three different approaches and here’s what I have.’ The emphasis for us is about making progress visible and discussable, because this often leads to early conversations, not just amongst the design team but also with myself as a product owner, the developers, and so on. There can be some collaboration and inspiration from that early work that I find really useful. I do think it was very unusual for the designers when we started it. As you’re saying it’s often surprisingly resistant from the developers. They often think it’s going to be very difficult to have this kind of daily cadence. But once they get used to it, I think people really enjoy it.
Squirrel: And they find it much easier than they think they will. It’s actually not terribly difficult once you unlearn a few habits. I think this is the same with designers, but that their habits are more ingrained and more part of their training and thinking, so there’s more to unlearn for them. That’s my sense from the outside.
Jeffrey: Well, I wonder how much of it is training. I was thinking about this in terms of nested circles of communities of practise. In the innermost circle there’s the team you’re actually part of, but then there’s the department or company that you’re in, and outside of that there’s the whole industry. As a designer if you are reading about design thinking or UX templates, checking references and Twitter and what people are doing, there’s not a lot of emphasis in that design world on daily delivery. There’s not a huge amount for developers but there’s not zero, as there seems to be in the community of designers. The idea of having regular incremental delivery has gotten fairly commonly socialised in developer world. Maybe not as daily delivery, but the idea that you’re going to deliver something on a regular, incremental cadence, is already embedded in the consciousness of developers. For designers I think in some cases they’re still working to get the value of design recognised, to have it understood that their discipline is more than just making things pretty. So maybe that’s part of the reason that it’s more of a mental leap. It’s less familiar to designers than developers. It is worth doing because when we are introducing these ideas, we’re trying to make the teams better. I know you’re very often coming in and helping teams that are very deeply stuck, and you want to start getting some amount of flow and getting things out. That was similar for me on this project. ‘We’re going to learn together what we’re doing, but we’re going to learn to get there faster if we get used to working in public and used to sharing our progress.’ That’s not always comfortable. This is the theme that I saw connecting these three tweets of yours: the idea of doing things that aren’t comfortable because you think it’ll be better. That’s what I was thinking we might take from this one to lead into our to our next episode.
Squirrel: That sounds great. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.