Design in Agile Software Development with William Price III
The Agile Weekly Crew and William Price III discuss design in Agile software development.
Clayton Lengel-Zigich, Jade Meskill, Derek Neighbors and William Price III sit down to discuss design in agile software development.
Challenges of design in iterative development
Pace and lead time
Everyone’s a designer
Design tools suck
Ship early and often
Light weight wireframes
Thoughtbot article on Everyone’s a Designer
The Mike Cohn’s “I’m always right card” is a joke from a training session with Mike.
Derek Neighbors: Welcome to another episode of ScrumCast. I’m Derek Neighbors.
Jade Meskill: I’m Jade Meskill.
Clayton Lengel‑Zigich: I’m Clayton Lengel‑Zigich.
William Price III: And I’m William Price.
Derek: Today we want to talk about…
Jade: The third.
William: The third.
Derek: Design in Agile Software Development. I just want to start an open dialog on, what are some of the challenges, of implementing design in an iterative methodology.
Jade: We are talking web design specifically.
Derek: Lets start with web design and if you want to go beyond that we can. But lets start there.
Jade: It sucks.
William: I think my experience with design for a website or whatever is that a designer comes up with some idea of something. It’ like a waterfall. Everyone’s used to the designer comes up with something and makes this nice pretty PSD. Somebody else slices the PSD up and it turns it into HTML and CSS at some point in time, and then that becomes your web app.
I think that’s probably like 90 percent of the people out there, their experience with doing design. When you take than and try to put that into Agile, it makes it really difficult to say, “Well, this week we’re working on this set of features, and we need to design for that now or soon or whatever,” because I don’t think that’s how most traditional designers work. They need more lead time than that.
Clayton: Yeah, I think from a designer’s perspective the lead time is typically considered the biggest challenge, just the pace. I think a bigger challenge is knowledge and appreciation that overlaps as much as possible between developer and designer.
You often hear people say, “Everyone is a designer.” That makes me kind of uneasy, because I think design is a craft. It’s a skill that you have to hone over time. Anyone can hone it. Anyone can learn it. Anyone can learn to draw. Anyone can learn to think well and design. The thing that makes me uneasy about everyone is a designer is that when you say that it’s like, “Oh, so now I’m a designer today, instantly.”
As a designer that makes me uneasy, but what I need to do is develop relationships with developers and with product owners where I can appreciate their input and work with them as fully as possible. As a developer, being involved in that process and considering it meaningful I think is often missing.
There are some developers that will say, “Oh, yeah. I think that’s important.” But do you spend time learning the fundamentals of design and things like that? Or do you just go by what you think looks good?
Then as a designer, appreciating the developer’s input and not just thinking, “Whatever sexy pretty thing I come up with, is the best solution” because it may not be the best solution for the process.
It may be a huge nightmare for everyone involved. It may be far more expensive than it’s worth. You might be developing something that looks great, feels great, to the product owner but gets torn out a month later because users don’t use it. Working together and having a tight relationship, that’s the biggest challenge in my opinion.
Jade: Well, I think to address something you said. You’re talking about everyone is a designer. Some of that came from a Thoughtbot article that we read as a team and had some discussion about. What I think he’s…
Clayton: Or is it, Derek who said as a team like three years ago?
Jade: Yeah, yeah, yeah. Where’s your Mike Cohen I‑know‑everything card? Can you pull that out right now?
Jade: Now I just lost my train of thought. Thanks.
Jade: Yes, Thoughtbot. So I think what they’re trying to drive at is not that everyone is a professional designer in the sense that we think but that everyone plays a role and should be conscientious of design, right? It’s not acceptable for developers to just say, “Well, I don’t know anything about that because I just write code” and crank out some really crappy‑looking interface.
We should be at least conscientious of the basics of what we’re doing and that it should be professional and not, like I said, some hack job that you know a developer put together because you can just tell. I think that’s what they’re driving at.
Clayton: Yeah, so I think an analogy would be I wouldn’t be able to figure out a good color scheme and whatnot for, say, my house. I’d probably paint the walls white and leave them some stupid color, and I wouldn’t bother decorating. But when it came to arranging the furniture, I wouldn’t put the couch in the middle of the room facing away from the TV or something stupid.
So I think there’s something to be said for maybe you’re not very good with the design theory or color theory or some of the things that may be more traditional design when you think of design are. But in terms of maybe the user interface or how things flow or just sensible decisions, I think that’s the kind of designer that everyone could be. Just take a step back and say, “Does this make sense? Yes or no.”
Derek: Analogy wise maybe it’s similar to, I expect most adults to be able to drive a car. I don’t necessarily expect most adults to be able to race formula one, or race NASCAR, or race the Baja 500.
I think that there’s definitely a difference of level of, and I think there should be expectation of people who are developing software to understand, like you said Clayto, to not put the couch facing the opposite direction of the TV in a functional living room space where 90 percent of the time people will be watching TV.
I think we see developers do that every single day, do things that make absolute no sense. I think to me I’ve got two additional questions on a design in iterative fashion.
One is we start to see iterations become shorter and shorter. I know one time in a Scrum that was pretty much a given that a sprint was a 30 day or month long function or iteration, and now we’re seeing sprints down to, a week are pretty normal. Two weeks are probably now the standard.
In some days we’re pushing more towards Kanban where it really is a sprint might be, an iteration might be, in a day, or less than a day. How’s it feasible to, not even talking about coming up with the design, but how’s it even functional to implement the design in that quick of a time frame.
What are some of the challenges? We’re starting a sprint on Monday, we’re ending a sprint on Friday and we’ve got to go from design implantation in five days. What are some of the challenges around that?
William: I think one of the challenges is the tools. Just to make an excuse for designers, that I think is legitimate, is that the tools suck. There’s been a push to do all your design and development in the browser. Then there’s this push to handle it all CSS3.
Do everything you possibly can CSS3. Granted the great designers out there are able to be really involved in the front end development and do minimal stuff in Photoshop. In general to work fast is difficult with the tools that we have. I would love to see that improved.
One thing I’ve been trying to get in a project that we would do here from a designer is to as much as possible think on a feature oriented level, instead of a site wide level. To design just for what needs to be designed, you don’t need to design a whole page.
If you’re developing a feature and it’s a widget in the corner of a page, the whole page could be a wire‑frame and that widget could be designed. The challenge there is to be consistent throughout, to have a good vision of where you’re going.
I think a designer that has good skills should be able to do that, should be able to stay consistent throughout, to keep going within the same vein of things. To keep the look and feel going but be able to turn around a widget fairly quickly and not to get so concerned about the whole page.
I’d be really interested to see a project go from conception to launch with that whole process. So far it’s been a challenge to see that. I think that could be a potential solution.
Jade: That’s one of the complaints that I’ve heard from a lot of designers. I need to understand the big picture. I need to understand the world before we can start implementing some of these designs. If we start on sprint one, let’s just say with no design in place, we didn’t do a design iteration or anything like that.
How do you see that developing? How do you maintain that vision of the bigger picture and the bigger idea when you’re doing it week long sprints?
William: That’s not a rhetorical question? You want me to actually answer that?
Jade: No I want you to.
William: [laughs] That’s a difficult thing to ask. I think there’s different scenarios. Are we talking about sprint one is a true sprint one and there isn’t this backlog of things that have been predetermined. I think that’s one thing that weighs designers down is when there’s already a whole bunch of stuff predetermined, and they&