 Welcome to Agile Roots 2010, sponsored by version 1, Rally Software, Virio, Amirisys, Agile Alliance, and Xmission Internet. The view from here, Reconciling User Experience, Product Management and Agile Development by Ray Dow, Nicole DeVry, and Francine Goetz. Hello, good morning. Thanks for attending our session. My name is Francine, Ray and Nicole. We are from Aaron P. Laboratories, and we're here to present to you today an experience we have with introducing very new roles to a somewhat new Agile environment in a vastly quickly growing organization. So just to give you a quick overview on the interest of time, I'm just just writing here. Aaron P. is what's called the National Reference Laboratory. What that means is if a physician, say in California, wants to run a particular test on someone, that is either not available in their local area or too expensive to process there, they'll send it to us if they're one of our clients. So we get samples from all over the nation. Any type of body fluid or part, they'll send it to us. We also offer blood services, blood donation, as well as blood product distribution to local facilities in the valley. We're very closely associated with the University of Utah. That's kind of how we got our start. A bunch of pathologists got together and did an offshoot 25 years ago, and now we are where we are, and we're growing very, very quickly. So one other thing about the University of Utah is we do have academia wrapped up into our business model quite tightly, just as an aside. We are experiencing existential growth. What growth comes a lot of change and hopefully a lot of insight. So how we came to be at ARDP, I was talking about two years ago as a product manager. Our executives realized that they needed to bring in skill sets that weren't necessarily available in the organization. So luckily they had that idea. They brought in UI and a product management. And part of that is inner two-year roles in struggling with organizational changes, full-time, and presentation. Also of note, software is not our core business. Testing is. Our software application products are kind of an additional service we provide to our clients, as we interpret their tests, deliver their tests, and potentially recommend additional tests to be ordered. Just to give you a rundown of the IT world at ARDP is we're fairly new to Agile, about two to three years. And I want to emphasize that it's not enterprise-wide. IT has adopted it, but the rest of the company is slowly getting on the back of it. Okay, prior to adopting Agile, we had a mixture of ad hoc development with some waterfall. And like Francina lived or two, it were used to like a small company. If anybody wanted anything done, they'd go corner one of the programmers and say, I want this done. And we're slowly trying to get away from that. We were traditionally using the Delphi. We're moving to more of a dot-med environment right now. Our IT department is comprised of 27 developers, 17 software testers, and six scrummasters. The scrummasters also operate as business analysts, so you'll have their business analysts slash scrummasters. On average, there are eight to ten software development programs. I mean, excuse me, software projects going on at one time. And historically, IT has kind of had full reign, if you want to call that. We haven't had really any involvement from product management, and really no UX involvement either. So that is how the IT, that's kind of the IT world right now at AREP. So as I mentioned earlier, I'm a product manager. I came to be in this role. I was a nurse for a number of years, went back to school, got an informatics degree, and got into computer software development design. Started as an analyst and then grew into a product manager role. So what is product management? I bet if I asked any one of you, you'd have ten different definitions of what it is. And I was joking, laughing about the presentation yesterday. I think we're product management butt at AREP. So my definition that I put up here is kind of what I'm working with, what I brought to the table, and then how I'm adapting to AREP's definition. So again, I remember product management was very new. I came from several different organizations that ranged from size from very small to very large and had with me a very traditional idea of what product management was. I also had experience working with usability and user interaction design, so I was very familiar with that, and different types of development. So my idea of what product management is, as I see it right now, is I'm kind of a dot connector. I can work at the tactical level in the leaves, but I can also go up to the strategic level and see the forest. And I'm trying to connect the dots between the products and as well as balance the customer needs, the market needs, and our business needs, which isn't always easy to do. What I like to see myself as doing is identifying opportunities for reuse. So I'm involved in a lot of different projects at a lot of different levels. And what I'm looking for are ways to reuse things or standardize branding across the board, ensuring that our customers are having a similar experience across all of the applications. So some of the challenges I'm experiencing or have experienced as I mentioned, I came with me, brought with me a traditional product management definition. And AARP's kind of adapted to that role. It's very new, trying to figure out what we do with this person. agile is very new as well in the organization. agile was new to me, so I adapted to that. And luckily UI was not new to me, so I was able to adapt to that pretty easily. Some of our roles were not clearly defined or understood, so there were some resistance there. And let's face it, change is difficult for everyone. Our organization is changing, our roles are changing. And people who have been there for a very long time, their roles are changing as well as we bring in new skill sets into the organization. My name is Ray, as was mentioned, and I come into AARP most recently as far as our trio is concerned. I started with the company less than a year ago. I come out of a web design and interface development background. I've had 15 years in that particular trade and came to AARP being tasked now specifically doing user experience and user interface design instead of the broader set of web design and development. So for me, this was a refining in my focus, but one that I was real pleased to be able to tackle. But again, as has been mentioned, for me, new to Agile. I worked in shops that were more ad hoc, kind of take a project by project, probably closer to waterfall and anything. And coming into AARP has proven to be interesting and challenging and at times frustrating, but it's given me a chance to learn how to work with Agile and to adapt my practices as an interface designer and user experience designer to more of this kind of Agile mindset. And part of our presentation today is talking about how the roles that Francine and I specifically have are being tied in real closely with the development of a particular product and how the integration of these different roles has proven to be very successful for this particular project. For me, the biggest challenge that I face is bringing together software development, that very logical, very practical, very precise practice of creating something and merging it with the very often impractical, irrational, emotional sets of human behaviors coupled with the fact that in general we tend to be kind of lazy and we like things to be simple. So as I introduced myself to AARP, the very first meeting I had with the company was basically I'm here to try to make things simple, both for the company but more importantly for our users, the folks that are on the other end of whatever interfaces we deploy. So with that, this project has been kind of fun because we've been able to work together on this and see some fun and some success in the process to refine your role. Okay, and most of you are not new to Agile and so I will go into the really nitty-gritty of what Scrum Master does. I think everyone's pretty familiar with that. Like I alluded to earlier, there's more of a business analyst role in this. That's my background, about ten years as a business analyst. So coming into the Agile over the last year at AARP was a very new function for me and I think it kind of echoes what we're right in front of seats that we're kind of all new to the Agile world and trying to find our bearings and how we're going to make new projects work. Let's all review the project goals. The project that we're talking about today that we had our experience with is called BARA. It stands for Business Analytics and Reporting Application. This project was initiated as a way to replace an existing antiquated system that was written in Delphi and we were moving towards .NET. So we didn't want to just replace the existing, we wanted to replace and improve upon that. This is an application that would be used by internal users, so our business people as well as external users are clients. And it's an analytics and statistics running reporting tool to kind of see what were the test ordering patterns, what volume of testing am I sending in, and what is AARP doing to turn around time? How quickly do we get these back? And so it just helps with doing some business analysis on both ends of the equation, both for us and our clients. Okay, just a quick snapshot. This project began in November of 2009. It was approved as a development project. All of our projects have to go through a formal approval process by a committee at AARP. The user stories were compiled and translated into product backlog items. The completion time, we were speculating based on kind of the story points and velocity. We were speculating completion on January 1st of 2011. The development time was about 13 months on that. The product management at this point, we were ready, we were set to go. The development team was ready to go. We had our SQA. And our executive sponsor introduced Francine. We've got this new role. We would really like her to be involved in the project. So at that point, we brought Francine into the project as more of, I think, just kind of a consultant. What do you think? And then the preliminary screen design was created. So we just did a really, the developers and I sat down. We just kind of mapped out, okay, this is what we're going to, this is what we're going to build. This was the first, this was going to be our blueprints, in a sense. We had noticed all the tabs across the top, and all the different options going down. But this is what we were going to go forward to. This is what we were going to build. And as of November 2009, we had our product backlog. We were ready to start with our sprints. And this is what we were going to build. Then in December of 2009 is when we, it was also recommended Francine, Ray, which is Pirate, she says, I really would like Ray to jump into the picture. So I'm going to turn over to Ray. And this is kind of his perspective as of December 2009. So about a month later into the project. So I was invited to sit down with the developers with Francine and with Nicole. And they showed me that previous slide and had given me some background on the product. And I was like, this is kind of messy. My initial reaction was, OK, let's try to make this nice. Both because I was new to the company. I wanted to try and make a good first impression, if you will. But it came down to, in just looking at it from a usability person's perspective, the ideas that they were trying to package together in this interface just seemed to be very clunky. They had basically a lot of the systems level kind of interaction right up on the surface. Things that our users really didn't need to deal with. And so I basically went back to Nicole and I said, can you give me a couple weeks to really get my head around this project, find out a little bit more about how our customers use this and come up with some refinements on this interface. I will tell you that I received a little bit of pushback as far as the developers were concerned. They were ready to go. They knew exactly what they wanted to develop. They knew how they were going to go about doing it. It's just that I really had a strong conviction that what they were planning on building was not necessarily going to be an improvement over what was there already. And so it took a little bit of selling and a great deal of support from part of these two ladies to convince everybody to stop down for just a couple of weeks so I could come up with some refinements and work through the project. So I came back with a revised interface using some wire framing tools that I was able to in this three-week period go through, do analysis on the entire project, go out, visit with our internal users, make sure that what we were talking about developing was going to work with their business flow, work through paper prototyping types of exercises with them, and came back with a great deal of feedback. In fact, the feedback that we got asked for changes even to this interface so where we had been able to tidy things up and refine things, kind of eliminate a handful of choices. Our users ultimately came back and said, there's a lot of stuff there that we still don't need. It's confusing to us, and it would be really cool if you could make it go away. So we took another stab at it and tidied things up a little bit further. We came up with an interface that looks a little bit more like this. In fact, this is a release that said we're going to go down or to a certain length. This is actually release one, and release three, which is more enhanced features, will probably be going to certification probably first week of July. So we've been moving along with this project real rapidly. This is, let's say, a functioning piece of code that's the screen capture, and we went out and did usability testing with our in-house users throughout this process. And again, as they saw a higher fidelity prototype to be able to refine and tighten this interface and interaction set to the point that now when it came time to start training on our first release, everybody was just like, yeah, we get it, we understand it, it makes sense. Let's go. Okay, and as Ray kind of made reference to is that at first there was some resistance, and at first I felt like our role trying to integrate Ray into our day-to-day activities was a bit of a challenge at first, but at the end of the day, he was just a member of the team, he came to our daily stand-up meetings, he was constantly given the feedback. Whenever we had a new release, he was going out to the users, he was coming back, we had that immediate feedback, and actually I want to make references back to that he did work very closely with our product owner. So he and our product owner were very proactive in getting feedback from our customers, from our end users. But development began on the revised screen mocks and derived from Sprint Zero, and so Ray mentioned that there was, he asked for just about a couple weeks. We did that Sprint Zero, we pretty much halted everything, we did kind of a Sprint Zero where it was, we just revised some of our product backlog items, we redid the screen prints, we did kind of a Sprint Zero, which was about two and a half weeks, and kind of revamped some things. Okay, and the frequent releases that they've occurred, they've been ongoing, and no negative impact on the Sprint outcomes. If you look, these are just a couple of samples of our burn down charts. Integrated UX, even though at first we kind of felt like we kind of tripped a little bit over ourselves trying to figure out how we were going to make it work, but just once we got into the routines of the daily stand-ups, handed off to Ray, he brings it back to us. We did not notice any difference having UX involved in product management in any of our burn downs or any of our Sprints. Who is the product owner? The product owner, because this touches so many different areas, and we kind of broke, if you will, kind of, I guess, the agile, because the agile is supposed to be the content, kind of the content knowledge expert. It was for an individual from our product, we have a project management office that handles our projects through AREP. Because this touched business development, it touched the client, it touched all the technical laboratory sections to have that many different product donors, we didn't want to go down that road, we had an independent person who was knowledgeable about the business from our project management office, and he has been serving as our product manager. He's done fantastic. Okay, so as I alluded to, there's been no negative impact, and really even it kind of took, once again, going back to trust, trust seemed to be kind of a common theme of this conference. Really, now, we went from the developers who were, you know, we don't have time to deal with him, but we'll be able to now, when we're contemplating maybe some of the things and some of the layout, the automatic thing is talked to right. And they are very much supportive of him. In fact, we're starting to look at doing some different things on another project, and the first thing was, let's get very involved. So it has been almost second nature now that Ray is just kind of part of the team, and his experience and his input is extremely valuable. All right, currently the BAR project is within the allocated budget, so not only after we, he came to us with a new screen sign, we modified our product backlog items, took us down an additional three months, so three months development time. We're also even head scheduled right now, and so we went from January of 2011, I think there's other factors, but where he just really cleaned in and made it very, more of a clear cut goal, I felt, for us, we're probably looking at completion around October 1, and then UX involvement with constant end user feedbacks. At the end of the day, we just want what the users are going to be happy with, and I feel I have a higher degree of confidence that we're going to deliver what the users want. So from my perspective, being the new guy on the team, being new to Agile, this project has been a lot of fun to be able to see things coming together and working well, and as was mentioned, up front, I think there was a little bit of skepticism. Our developers were, I think, honestly, very perplexed when I said, please don't do anything yet. Let me just get my own head around this project because I'm the new guy. Let me go out and test your ideas and my ideas with our users. Let's get some of that feedback so we can make sure we're on the right track. Ultimately, I had to adjust my processes because instead of being able to kind of say, hey, we've got this period where we're going to be gathering requirements and doing all sorts of mock-ups and analysis and big volumes of documentation and things, it was literally, I was granted three weeks. I was given a sprint to be able to go and work through this process and it meant really quickly coming together with interfaces, user meetings, meeting with the development team, with product management team to make sure that we understood how things were fitting together and to be able to give that information back to the developers, the changes that were coming in, so that when it came time to start coding that they already had everything all lined up so that things were ready to go and clear. The thing that I think made a huge difference for me was, as Nicole mentioned, being part of the team. So instead of being brought in as kind of a consultant where I'd say, hey, Ray, what do you think? It was a initially bad, but then the invitation to participate in that daily basis and throughout the project allowed for me to build rapport with the developers. So when we came off against Snags where I was coming back with here's where our users are having difficulty, this is not working, guys, to be able to have bootcandid open discussion with all of the developers and be able to work through those things as a member of the team instead of being that outside consultant UI guy. So for me, one of the biggest things that I learned is that it's really important to work side by side with the folks that are building the project instead of just working with the marketing and business analysts and things like that. And so lastly, from a product management perspective the first bullet up here really was the easiest thing to adapt to. We've written numerous articles on product management organizations saying oh my god, our organization is going at it blah blah blah, it makes so much sense because as a product manager you're constantly revising your roadmap to meet your business, customer, and market needs. So that was easy. As a product management organization that's an ongoing process of understanding roles and boundaries and responsibilities and just defining our roles as our organization changes. That was a lot of defining my roles. I almost wanted to put a quote on what a product manager is to be my salutation on all of my emails but I didn't. So for me, my takeaway from being involved in this project was as I mentioned earlier the paradigm that was used in the Barra project was so effective and I saw opportunity where this could be leveraged across other products that use reporting paradigms and features and I'd like to see us adopt the Barra way of doing those reports. And lastly, as we've all mentioned we're relatively new softwares on our core business. We didn't have style guides until Ray came along and so now with Barra a style guide was developed granted it's just the beginning of this again across all of our products so that all the products are branded correctly and have the same standards across the board. That's pretty much our takeaway. Do we have time for questions? So any questions? How did you grow about attracting your users? How did you track that? In terms of like hours? Well, let me put it this way. The developers, they have stories they can estimate those stories that's trackable, people know what's going on. How do developers know what was going on with you? I think that honestly comes down to being part of the data standards and the spirit planning and spirit management perspectives because I can come in and say here's and I would do both wireframes as well as interaction diagrams. So I can say, okay, here's what the basic interaction flow is going to be like with this report and that report. This is where we need to have, it's logical to have these controls in this order, here's what the screen looks like but here's what a user is going to do, what their needs are and having done interviews and observations, I understood what their workflows were so basically like an interaction diagram, a handful of wireframes and that was documentation that we would discuss in our spring meetings and that I handed over to Nicole and her team. Did you store that anywhere specifically? I've got my own network space that I've got all of those things shared but then as I would package up sets of information I would distribute that to everyone on the team. And we use that TMS and so we have a document repository that we store all of that information as well. And one thing too that I will know is that for each spread we had tasks and hours allocated to Ray that were associated with Ray only and you know I do I want to sell the idea that this worked because I think this team really collaborated well. I could have said okay Ray did you get this done and how many hours did you get done and why did you get it done and he could have said you're not like also not accountable to but he didn't. He was accountable just like the rest of the team that it was on our daily stand-ups okay Ray, we're using these tasks how many hours did you burn down and that worked really well but Ray like I said just another member of the team he has responsibilities in those hours We've got to wrap things up Can we take one more question? One more question Okay, you guys get to wrap things up I was just going to maybe just make an observation I've been part of project teams where the user experienced people, the designers and the developers that relationship was very strained or really bad and part of it was because of the turf wars over people over stitching their bounds sometimes I can see that the developers at first were hesitant to give up control of what it looks like but then it seems like you had a clear boundary of okay you own what it looks like the developers own how it's built and how it works and having those clear delineations of responsibility and roles seems like the difference between your positive experience and other negative experiences that I've had in the past She had a lot to do with it She was very encouraging of bringing in new people into the team and really one targeted team to see the value in our roles and push for that Your use of low fidelity wire frames and things like that I think was a big plus as well as opposed to creating high fidelity you know spending a lot of time up front working out very well put together and polish user interfaces right up front because then you kind of get locked into that and you don't have that sort of flexibility going forward I think that was key We experienced quite the opposite where folks saw the wire frames they had never worked with wire frames before and they said this is too simplistic it's boring this won't even go with our clients we had to explain to them that it's just prototype I will say that I have had some background of course with coding through middleware and things like that and I make a conscious effort not to tell anybody on the development side of the project how to code it I just wanted to make sure the interface is good but we do have a lot of dialogue about how to accomplish them Thank you very much