Dual Track Agile

Good morning, everyone. Oh good, the microphone is working. So, as I said, I work at Autodesk. Autodesk is a huge company, it's like ten thousand people. We have hundreds of products but the part of Autodesk I work in is the entertainment creation products division. And we're the part of Autodesk that makes tools for animators, people who do computer animations, special effects for movies, TV shows, simulation, anything like that. And these are some pictures by artists who use our software that they’ve published on our forums. So we make software but it's our customers who make magic with it. And I love working in this field. I just love the creativity and getting to help create tools for these people.

As I said, I'm the director of experience design right now but in my past, I've been a software engineer, I've been a UX designer, my own background is in design and software engineering, and I've been an agile coach. And this will tell you a little bit of the story of how we came up with the idea of dual track agile and how that can help you adapt your UX practice or in fact adapt anything else to work in an agile environment. So, this is what I'll be talking about today. And I want to ask, how many of you've seen that diagram before? I'm curious. Okay, yeah, a good number, so I know which of you are process wonks now. That's from a 2007 article that we wrote by Marsha who still works on my team. But I got to start off by talking about how agile ruined experience design.

Now, for those of you who are younger than me, which is probably most of you, back in the 1990s when I started-- Well, I start working in the ’80s, but all through the 90s, I was working at a company called Alias and we were doing the same kind of work. We were designing software for computer animation and we worked in a waterfall development practice like pretty much the entire industry. I worked for a woman named Lynn Miller, and Lynn and myself and my colleague Desiree were sort of this all unicorn UX team. And by unicorns I mean we did everything. We did our own research, we did our own design and we did our own usability testing and validation; that's the way we liked it. We didn't do graphic design, we hired Marsha for that. Well, we had a great practice, we had great rapport with the developers, we were doing everything right, everything was working beautifully.

And then in 2001, the Agile Manifesto happened. You should all have seen this page. Actually, this page hasn't changed since 2001, same graphic. But agile came along, this idea started, and my company were really early adopters. So one of the signatories of the Agile Manifesto, Jim Highsmith, there, was brought to our company the year after, in 2002, and he trained all of our developers. He trained all of us. We all got into a room and he did two days of training. And Jim is a great trainer, he's really smart. I think he's still doing it. He totally revolutionized our software practice, but when he was describing how agile works and the whole way it goes, UX didn't exist in it, there was no mention of UX. So they'd say: “How do you know the thing is good?” “Well, you do a cycle, and at the end of the cycle,” they said before Sprint. So at the end of the cycle, you would show your software to the customer and say: “Is this good?” And if your customer says: “Yes, this is good,” then you're done. And of course, those of us who work in UX were like: “This is terrible. You don't get the insight, you can't tell anything about learnability, you can't tell anything about usability.” It's just a really bad way of doing things, so I got into a big discussion with Jim but that's another thing.

Anyway, so we adopted agile and our engineers were happy, our practice worked really well. A few bumps along the way but it was great for our engineering teams, they loved it. Suddenly they were in control. They used to kind of be controlled from above; now they were driving the train and they could make things happen the way they were. But that was the engineering team. The design team, we had had a really good life and suddenly we were at ends. We couldn't fit into their process anymore. We would do things, like we would do a usability study, but by the time we were done, development would be three phases off, or we’d be designing something and they'd have changed direction in one of their agile sprints. We couldn't give them feedback when they needed it and we kind of got disconnected, it was horrible. And the funny thing is, we were going to other design conferences and seeing the same problem among other people, and these are some quotes that people from other companies said to me. I wrote them down at the time because I thought they were kind of funny. They think: “Well, I'm just going to keep doing things the way I've always done them and they'll come back begging to me,” from someone whom I assume has never met a developer.

Anyway, so this led us to our first revelation of the three revelations I'm going to talk about today, and our first revelation was that to serve agile, design had to become agile. And we thought about what that meant, so I went back to the agile principle. Not me, me and Desiree and Lynn, the three of us always worked together, went back to the principles of agile. We looked at the things in the manifesto and we thought about what it is that makes agile work. And what's really happening in agile is you have this loop, you've all seen this a thousand times, the build, measure, learn loop, and you've brought this into development. But this is the basic idea in usability that usability testing and that has this loop so we should be compatible. Why aren't we compatible if we have the same kind of loop? So we had to look a bit more into agile practices and what makes them agile.

There’s different attributes but here's a few I've picked out that makes agile practices actually agile: They're more conversational, they're more about talking to people than writing documents. They're collaborative, you're working together. But incremental and iterative is super important. An agile process is something that you should be able to do over and over again continuously. You don't do a big, big scary thing at the end of your release cycle then everyone collapses. No, you should be able to steadily go along and produce stuff and incrementally add value. And of course, things are time-boxed, you're working for a specific amount of time on a specific thing and then you stop and everyone's working together. And we realized this is part of our problem because as designers, we're not working on the same thing the developers are working on at the same time. We're supposed to be in front of the train, we're laying track, we're clearing bushes, making way for the train to go, and we're supposed to be behind the train validating things, making sure everything went the way it was supposed to go. So this is the kind of timebox we needed. We needed to be desynchronized from development, and this brought us to the dual track model which we developed on Lynn's whiteboard back about 2003.

So here's the basic idea. At the beginning of a project you're in your Sprint 0, and at this time, you're working out, figuring out what you're going to do, you're chartering, and at this point, what you’d look for is code that needs to be written that doesn't have any UI attached to it because there's always something. There's always something in the back end or some technical debt that the developers can work on that doesn't need UI help. And then once you've finished your Sprint 0, your work divides into two different tracks: a designer track and a development track. So in the first sprint, the developers are doing that stuff you've identified, stuff that didn't need design work. No problem. And while they're doing that, design has a bit of time to look ahead. What's the next thing? And the designers can be getting it ready, they can be validating it, making designs, usability testing for paper prototypes. And at the end of the sprint, anything that's been validated can be passed back to development to work on in the next sprint. So design is always working one or two sprints ahead.

They can also start researching for further forward stuff, so the design team can be saying: “Oh well, we see a few more things that are coming down the pipe so we can start researching that.” And you can just repeat this cycle over and over again. Then it’s Sprint 2, we're working on Sprint 3 stuff but we're also validating what went into the code in Sprint 1. I think this whole slide thing is going to be on SlideShare afterwards too so you should be able to get that. That's the model that we came up with about 2003. But the one thing that wasn't really in our first diagram that Marsha did for us was this, because we left people with a false impression that we were handing things off between sprints and that's not really true. There's constant communication that has to go on all the time. So I want to be really clear about this because this model, the dual track agile model has been written about all over the place. If you Google it, you'll find dozens of articles about it by different people, and a lot of people get the same things wrong when they talk about it.

So number one, be really clear, it's not two teams, it's two tracks. The same team is doing two different tracks of work which are tracked differently. And that is really important because we made a whole lot of mistakes when we started out. For example, one of the first adaptations we tried was we would just put design work in the backlog and treat it like development work, but that doesn't work in agile, it violates the agile principle of working software as the only measure of success and it screws up your velocity in your calculations. We tried doing complete designs. We designed the whole thing, and at the end of every sprint, we would redesign for the end product over and over again, and that killed our designers, they just got so far behind. But anyway, sorry, back to this.

So, things people get wrong. Number one, so a dozen designers are on the same team, that is correct. Insight is shared. We're not throwing design over the wall. We're not saying: “We've done the design, now we're throwing it to development,” that's not how it works. We work together on it. Developers have to be involved in design because they're the ones who can determine the feasibility of building it. The designers can say: “We want to do X,” so developers have to be involved. Similarly, while the developers are building the actual features, designers need to be involved because the developers are going to learn things: “Oh that code is too hard, the API doesn't support that,” and there will have to be modifications. So everyone's working together - one team, but doing two different tracks of work.

Okay, that wasn't quite enough, though, because we had to change the way we did our UX practice. And if you go back to that list, agile practices have these attributes and you can find that you can pretty much adapt to any practice to be agile by making sure it's that way. I'll give you an example of how we did it. So take for example usability testing. This is the way people did usability testing and maybe some of you still do it that way. You wait until you have something to test and then you create your prototype and then you plan a test, your protocol and you recruit users and you bring them in and you run the test and you write this big ass report at the end that lists a hundred things that went wrong and you hand it back and you've taken three weeks to do it. That's not agile. It's not time-boxed how long it's going to take. You can do it iteratively. Is that collaborative? Is it conversational? Is it just in time? It doesn't really fit all that well, especially time-boxed. So what we did is we changed our practice. Instead of waiting until we had something to test, we planned the tests first. We said: “Every two weeks we're going to have a usability test.” We don't know what we're going to test. We built a pool of users that our recruiter could just pull from that pool of about 40 people. They'd pull five people in every two weeks that we could test with. And when the tests came up we had: “Well, what do we have?” We've got this paper prototype from the designers, we've got this bit of code that just went in from the developers, and we would just test whatever was ready. And we'd invite the team to watch so that everyone could see. So we had effectively just done this. We've now made this practice hit all of these agile attributes.

The other thing is, at the end of it we'd say: “Okay, here's the three issues we're going to fix.” Maybe we have a list of 30 issues but there is no point in writing a big report with 30 issues because the fact is, when you fix the top three or five things, which is all you'll have time for in the next sprint, it's going to change people's behavior and the rest of the issues may disappear or new ones will show up and be more important. So you don't really need the rest of the list. You're going to have some completist designer who can't not write it down, so let them write it down, but it's not what you need to report.

Look at the way we used to do user research. User research in waterfall, you go in at the beginning of a project and you'd talk to hundreds of users, and you'd interview them and you'd build all of these artifacts, these big test reports and personas and reports and use cases and whatever else - I don't think we were doing journey maps back then - and you’d deliver that to the team. That would take like three months before you'd start building anything. And that, of course, is not agile at all. You're making a bet there on the next two years of development, and that's just not a good way to work. So to be agile, we had to find a way to make this iterative and incremental, so we talked to users regularly in different ways, at our usability testing that was regularly scheduled; we’d go visit people, and we'd kind of focus on what was the next thing we needed. What’s the next piece of information? But we're also always updating our big documents. We have a persona document and you can update it as you learn more, as you gain insight. We can update our journey maps or whatever it is we're building. So the idea is, those are tough stay around but they're living documents that you're always touching and redoing. And continuously, as you’re visiting customers or as you’re gathering more research, you want a conversation in your scrums. In your daily scrums, say: “Hey, we talked to some people and we got this new insight,” so that insights are shared throughout the team as well.

We have all different ways of touching users and we're not afraid to mix methods, so sometimes if we have someone in for a usability test, at the end of it we'll say: “Hey, we want to interview you for some upcoming stuff,” or “Can we run the usability test at your place? And while we're there, we're going to do some contextual inquiry.” We just put everything together and we cut it into little bite-sized pieces that's focused on our immediate needs coming up.

Design specs. Those of you who came from the waterfall world may remember the 60-page design spec with every detail written down. And there's this law I realized that the longer your design spec, the less likely a developer was to actually read it. So the way we do designs now typically is just a couple of pages – pictures, call-outs, and a conversation where you sit down with people you talk through the design. It takes so much less time and it is so much more effective, and of course, it's agile. So we had that, we figured out how to adapt our process, we figured out how to time it all and we got it working. It worked for our team. 2003, we got this stuff going down, and we started to publish on it. This is Lynn and Desiree and I in 2006. Lynn did a paper. Actually, it was funny, she wrote a paper for UPA 2004, I think, on this whole topic, and the paper was rejected by the conference because they said, and I quote: “Agile is a niche thing of interest to few people.” So she ended up presenting it at Agile 2005. I did a paper on some of our adaptations at UPA 2006. And in 2007, Desiree put together all of our work and wrote an article for the Journal of Usability Studies, which for, I think the next five or six years at least, was the most cited article in the journal ever. So that's when this started to get spread around a lot. But we weren’t the only people working on this, I don't want to take for that. A lot of people were working on this problem at the same time and coming to kind of similar conclusions.

Now, one thing we didn't do and we should have done is we should have come up with a great name for our method. We did not. We were calling it “Parallel Track.” But because we didn't have a really good name, we thought other people were writing about it and calling it something else, so you may hear this referred to as “Staggered Sprints” or “Dual Track,” which is what I'm calling it today, but it's all the same thing. Anyway, we finished this, and suddenly, we learned that we love agile. When agile arrived at alias, I hated it. Oh, I hated it so much. But we learned to really love it, we loved working this way. And our experience wasn't alone.

This is Jeff Patton who you may know as the story mapping guy, this is a quote from him. He had the same experience when agile was really bad, he interviewed us back then to see how we had been fixing that, but again, we love it. But then, in 2006 my company was acquired by Autodesk, and at that time, Autodesk was not agile and they crushed our agile development practice, just like: “Nope, back to waterfall, back to the 60-page design documents.” And I got to say, you don't realize how good you have it in an agile development environment until you lose it and you go back. Oh, it was just awful. I felt like I was running at like one-third speed, slow motion. But luckily, Autodesk was catching up with the rest of the industry and they decided to go agile as well. And because I was complaining a lot, I was put in charge of the agile transformation for our division. I was the lead agile coach for that transformation. I made lots of mistakes, which I'll tell you some of, but one of the things I realized when we were doing this and we came to my second revelation, is that there is always friction between the parts of the company that are agile and parts of the company that aren't agile.

So, for example, when development when agile, we would subscribe to the kind of friction that design was having with them at the time. But frankly, there was friction with every other part of the company too because marketing would say: “Well, we need to know which features you're putting in by the end of the year before we do the big release so we can write marketing materials. And the same thing, the documentation people would be like: “You have to freeze the UIs four months beforehand so we can write all the documentation. And the localization people: “We have to translate this, so you need to freeze everything.” But the development team was saying: “Well we're working agile, we don't know what features are going to be in. We're changing direction, we're learning as we go along,” and that caused a huge amount of friction and fighting. Now, of course, once we got Dual Track working, we were able to move ourselves over, and suddenly, we no longer had friction with development but we were having friction with everyone else as well, which takes us to 2011 and the publication of The Lean Startup.

Now, I hadn't heard of this book. Desiree, my colleague, says: “John, you got to read The Lean Startup.” And I said: “What is it?” and she goes: “It's agile for product management.” And that's really what it is because if you look at The Lean Startup, which is of course, a way of doing business discovery and figuring out how to build a new idea, product or service, but it does it in a way that hits all of these agile attributes. It does it time-boxed experiments with hypotheses, incrementally, collaboratively; it's agile for product management. So product management could move to the other side of the friction boundary, and that's kind of where we want to be now with these three things going on, that's what this conference is about.

As it turns out, there are ways of moving everyone over here. And right now, we actually have our localization team can work agile with incremental translation and we've worked out other ways of doing this stuff. So since we came up with this process and it's been spread around, there's been a lot of improvements of course that people have done. Originally, we called them the “Interaction Design Track” and the “Development Track,” but somebody, we think it's David Hussman, came up with the name “Discovery Track” and “Delivery Track” and I think that's way better. You have one track of work which is you try to discover what it is you need to do, and the other track where you're actually building and delivering it. I think that is a way better way of thinking about it. Marty Cagan made this generalized model of it which he's published, and again, this isn't a particular methodology, it's just a model that sort of fits a lot of different things like this. And he points out something really important, which I didn't mention, is that not everything makes it from the first track to the second track. Part of discovery is learning what you shouldn't do, and that's a key thing as well.

Carol Smith, Thyra Rauch and Hannah Moyers just did a paper this year expanding dual track into triple track. They are postulating that you should have another track which is just research, which is sort of just knowledge stuff, that feeds into the problem-solving track which then leads to the actual delivery track. It's an interesting paper. I'm not sure I would do it this way but Carol and Thyra are super smart. I don't know Hannah personally, but probably worth looking at. And Jeff Gothelf just today actually, tweeted a high-res version of his model that matches UX and agile, his way of seeing it, which is a variation on that going on. I don't have a slide of that because he just tweeted it today but if you follow Jeff Gothelf you can look at that.

And I was looking at, of course, the UXDX model, I pulled this up and I was considering what you have here is, again, the same, build, measure learn loop but you have it for product, you have it for development and you have it for deployment. We work in a packaged software thing so we don't have deployment the same way those of you who have web services do, but it's the same build, measure, learn loop and it's all synchronized. So it's sort of the same idea kind of brought out to a larger scale. My chief architect saw this image and said: “Leave it to an Irish design conference to have a shamrock-shaped model.” But before I finish up here, I want to talk about my last revelation and this has to do with when we deployed it.

When I was the chief agile coach for the division, the way we chose to do this is we said: “Okay, we're going to come up with a process, we're going to teach everyone the process and impose it on the whole division.” Bang! And what we learned is, for some teams it worked beautifully. Some teams ran with agile, they did great, and other teams, they just seemed to hit the walls and it didn't work well, and I had to really come to understand that. So that was basically a mistake I made, or not, we made. I'll take my part of the blame for it. But what I learned out of that is just this: our third revelation is that you can have a good process but culture eats process for breakfast. If you try and put a process where the culture doesn't match, culture wins every time. You can't fix culture with process so you kind of have to do that.

So, just to end with a few points which I think are useful on that one. So I think the right way to do this is process growth in fertile soil. You want to find a place where people want to pick up a new practice. Imposing a practice from outside can cause a reaction where people don't want to. “Don't tell me what to do. I want to work the way I'm used to working.” So you need to find someone who's keen on doing it, and instead of imposing it, you want to find people who are changing, people who will champion a new process. You want to find a team of people who are like: “You want to work agile? You want to work this way? Let's do it,” and you let them be successful with it and then other teams will want to copy them. So it's these find champions, then clone this out.

Beware of heroes. Agile is fundamentally an anti-heroic thing. The team is the hero, people work together. If you have that one person, especially the one person who draws a lot of their social standing from being a hero on the team, you know, “Oh, Bill worked really late and wrote this magic code and that,” that could be poisonous for an agile team, honestly. It has to really be teamwork, it has to be collaborative. If someone is used to getting their social standing that way, they may deliberately undermine the process or undermine processes like that, and that's what you don't want to happen. You want people to draw their strength from the team. So you always have to be careful. Anytime you're imposing a new process, you're changing the power balance and that could be threatening to some people. I've seen teams that have a strong development background where developers always had all the power and everyone else was serving them. There were other places I've talked to where it's the other way around, where design is driving everything and developers are just there to write whatever the designers come up with. And both of those things are unhealthy. You need a balance of inputs on the team to come up with the best decisions and make the best choices.

You have to watch your incentives. A lot of companies incentivize one-off work or individuals’ work rather than teamwork. And you can actually, again, undermine teamwork if people are like: “Oh, there's so much of a bonus and we're dividing it between members of the team, then why would I help my team succeed if I can make myself look good?” So your incentives have to line up with everything you know you want to line up.

And inclusion is super important in any of this stuff. The reason these things work well, these processes or product and development and design work together is because all three of those groups bring a different perspective. And a lot of people don't understand diversity and inclusion, a lot of people think it's: “Oh yeah, that just means we have different cultures and that all at the same table,” and that's not the point of it. The point of it is about making better decisions for your business, and there's a lot of research about this. And here's the thing, so if you bring different people with different perspectives and different knowledge into a room and you sit them down and you get them talking together, naturally human beings will gravitate towards talking about the knowledge that everyone has in common. And that turns out that's not very useful because everyone has the knowledge that they have in common, that doesn't help you make better decisions. So inclusion is about practices you can do to make sure that diverse people, that diverse opinions get heard. And it turns out the research shows there’s a few things that make this work.

Number one is different meeting practices that get people to share their opinions individually before a group discussion starts. So you can do things like get people to write their thoughts down on Post-it Notes so everything gets posted, and that will get the different opinions out. But it also turns out there's necessary conditions. One of the conditions is that everyone in the room has to respect that other people have information that they don't have. And if you come from a culture, again, where somebody thinks: “Oh, product management knows everything, then they don't respect the opinions of others,” then your diversity will have no effect. If you come from a culture where everyone's like: “I know my bit, but I understand that designers know things I don't know, developers know things I don't know,” and you all work to get that unknown stuff on the table, then you will have good decisions. And that's the difference. Diversity is having the right people in the room, inclusion is your practices so that they can all contribute fully, and that will lead you to better business outcomes.

My last point is to choose your scrum masters wisely because we've had problems before where, at the beginning, usually, when your people are doing an agile practice, they don't want to have full-time scrum masters so the development manager will be the scrum master or whatever. But the scrum masters are the ones who own the heart of the process and they're the ones who have to care about all this stuff, so that's the important thing. When you are choosing scrum masters for your team, choose people who really, really care about making it work. Who are the scrum masters out there? You guys are heroes if you're doing it right. That's all I have to share with you today. Again, that's me and I'm happy to take questions. I think we have a few minutes left.