Agile Product Development at Xerox

Agile Product Development at Xerox Guests were Helen DeNero and Patrick Waara

Business901 Podcast Transcript

Helen DeNero: Helen is the Program Manager for Design for Lean Six Sigma for Software at Xerox Corporation and is responsible for the training of Lean/Agile tools and methods across the corporation.

She has a BS in computer science from Rochester Institute of Technology, and has been with Xerox for 30 years. While at Xerox, Helen has held numerous positions within product development, including software development on the DocuTech products, Product Integration Management on FreeFlow Print Server, and Manager of Customer and Service Support for the Production Systems Group products. She is also a Lean Six Sigma Black Belt Candidate Patrick Waara: Pat has been with Xerox for nearly 25 years. He has both a BS and an MS in computer science from Michigan Technological University. He has held a variety of jobs at Xerox, including developing user interface systems for Xerox's DocuTech and Systems Architect for Xerox's iGen3, all dealing with software development and systems. Pat also works at St. Joseph's Neighborhood Center, which provides medical, counseling, dental, and social services to the uninsured, where he utilizes his software and Lean Six Sigma skills to support their IT and process infrastructure that he installed during a Xerox sponsored leave of absence. He is currently a Software Design for Lean Six Sigma Master Black Belt Candidate and a Lean Six Sigma Black Belt Candidate where he is teaching Lean, Six Sigma, and Agile techniques to Xerox's software development community improving software development capability.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Joe Dager: Thanks everyone for joining us. This is Joe Dager, the host of Business901 podcast. Participating in the program today is two Xerox people; Patrick Waara and Helen DeNero. Helen is the program manager for Design for Lean Six Sigma Software at Xerox Corporation. Patrick is currently teaching Lean, Six Sigma, and Agile techniques to Xerox's software development community. Patrick, could you explain to me your role at Xerox?

Patrick Waara: Sure. My main responsibility is primarily for teaching our classes, and for doing our internal coaching. So, all the Software Design for Lean Six Sigma that we have, I do the first wave of our Green Belt training, and then when there is other coaching that needs to be done, I am the first person they come to.

Joe: Helen, could you explain your role?

Helen DeNero: I am responsible for the program management of this program within Xerox. What that means is I work with the development organizations to make sure that they're software developers are trained sufficiently in these techniques. I lead a team that also looks at what is required to keep Xerox moving forward in the Lean and Agile domain.

Joe: When did Xerox start using the Agile, and why did they start using it?

Helen: It started actually back in August of 2003. First Laverne, she had sponsored a Lean Six Sigma Project to address improving the development and engineering productivity. As a result of that project, Design for Lean Six Sigma was launched at Xerox. We began with the electromechanical community in late 2004, and then expanded that to the software community in mid 2005.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Since then we have also included Inbound Marketing, late 2006. We are now beginning a program for Systems Engineering. Since the launch of the software, DFLSS Program, in mid 2000, which was targeted at certification for Green Belts, there are different levels of competency. The Green Belt Program began in mid 2005. Since then we have trained over 700 software developers.

In that program, it consists of two and half weeks of in-class instruction, and additional training on project work and coaching. Of these 700 trained developers, about 60% of them have received their Green Belt Certification, and the rest of them are in process.

In late 2008, we launched the software Black Belt Program. That is much more in-depth programming then the Green Belt Program. It consists of about four and half weeks of in class instruction, followed by about nine months of practice work, at which time the students are working with the instructor. They are being evaluated constantly by that master instructor.

So, there is a series of proficiencies that the students have to demonstrate in order to become Black Belt certified. Since we started that program, we have trained 21 developers. They are all in the process of getting their certification.

Patrick: I think that answers the question of how the program started. When we started looking at the content and what we thought was important to train our software people in, we realized it was really centered on a lot of Lean principles and Lean practices. The Agile practices really are embodiments of a lot of those Lean principles.

So, when we started looking at that content, that's really how we went to Lean and Agile as the predominant content for it. We also do Six Sigma content in there as well, and at the level that is appropriate for a software development.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Joe: You're one of the earliest adaptors of Agile out there, aren't you?

Patrick: I wouldn't say that. Agile has been around for quite a long time. It's growing in popularity I think. It's also growing, in terms of how to scale it to larger organizations.

Agile started with smaller communities of developers, and it really focused on how you can be productive with a smaller group. Over time, larger organizations have been adopting a lot of the agile practices, and figuring out how to apply those in a larger enterprise context.

Joe: How does the agile process work at Xerox? Can you do that, an overview?

Patrick: Do you mean the way we train it, or how we actually utilize these tools and techniques?

Joe: How do you utilize the tools and techniques?

Patrick: There are really two planks to this, I think. When we talk about agility, we're talking about business agility. There are really two things you need to be an agile business. You have to have agile processes, and you have to be technically agile. So, our agile processes really look at our software development process, and try to make sure that we can be as responsive to change as we possibly can. Our customer requirements are constantly changing, so we need to be able to respond to them.

The process that we use to do that, most of Xerox has been adopting Scrum as their agile project management technique. Scrum is a relatively simple project management process, but it really gives a lot of opportunities to be responsive, to give feedback, and to adapt a change, and also to have it built into continuous improvement.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

We can have very agile processes that allow us to respond to our customers, but also in order to be responsive to your customers; your software has to be agile as well. You need to be able to write and design your software, so that it can easily change when your requirements change.

If you have a lot of high coupling, things can get very brittle that way. Our technical aspects of this really look at understanding good design, and making sure we have unit tests in there. When you do changes, you do so knowing if you broke something or not.

So, when we do our training, we have the two planks. You have to have agile processes, and you have to be technically agile, so that your whole business can be agile.

Joe: Does it take a different type of software developer to like Agile?

Helen: I don't know that it really takes a different type of software developer; it is really I think more of just learning different skills and techniques.

Joe: I always picture the software developer, the guy sitting there who is doing the coding in the little corner by himself. Agile is something that becomes more of a community type, more of a team effort.

Helen: That's one of the things that we've worked closely with our developers to overcome is that cultural change as you described, working in the corner in their own little cubicle, to being able to work more collaboratively with their Scrum team in a more open environment, sharing ideas and working pair wise.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Patrick: I think our experience has been that even those folks who traditionally like to be off on their own, and like to work in their cube or whatever, have really grown to enjoy the community spirit. Because you come in, and you start working with a group of people and it's just a much friendlier atmosphere. It has been well received, I think in general.

Helen: I have to say, that initially there was a little bit of reluctance to it. The more success we have with it, the more other engineers are becoming more open and willing to try it, and to do it.

Joe: You mentioned that you're using Agile in inbound marketing. How are you using that?

Patrick: I don't think it is so much Agile in inbound marketing, but we have been using the Design for Lean Six Sigma curriculum and techniques. A lot of our inbound marketing focuses on a lot of Six Sigma parts, and understanding that you are looking at populations and sample sizes, and making sure that you are really getting true voice of the customer, and not just what your impression of it is. There is a lot of the more statistical analysis in there.

But there is a feed into the other part as well in the sense that the product marketing people and our product owners are understanding that they don't have to give us 100% of the requirements upfront and then we're going to go off and come back a year and a half later and hopefully do the product that they wanted.

They know they are able to now feed in the requirements as they get them and adjust those priorities over time, because we are going to deliver the content iteratively and they can get feedback and look to see if it's really the product they want and they can make adjustments as we go.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Helen: Not only do we teach them that they are able to do it but it's the more desirable way to do product development now.

Joe: How long of a cycle do you have? You develop something then you push it out to the customer and that feedback cycle comes back. It's not a tomorrow thing and I know it depends upon the project a lot, but what do you do in the meantime? Do you have other projects going on while you're waiting for the feedback of the first one? Do you have, as some people call them, stories that you're making as you're going through the process?

Patrick: The iterations for the development teams are usually two to four weeks so they'll deliver some level of content every two to four weeks. The feedback they're getting is going to be from the product owner, product marketing, and any other stakeholders who are interested in seeing the progress of that development. It's not necessarily being released out to the customers that frequently but you're getting that constant feedback and you're relying on your product marketing people to be giving you the requirements of the actual customer and giving you the proper feedback.

When they believe the product is ready to meet their customers' needs, that's when you go off and you actually release it to the customer so that they can get the product that they were really looking for.

Joe: One of the things I'm thinking of is how software developers work as a team. You talked a little bit in a note I saw from you about pair programming. How does pair programming work?

Patrick: Pair programming is basically two programmers working on the same piece of code together side by side, with the same machine though they might have two monitors.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

There are a couple of really important things that happen with pair programming. One is when you're working side by side like that you're getting instantaneous code review rather than some programmer programming his code, scheduling a meeting, then having a group of people review his code some weeks later.

When you do pair programming, you get that instantaneous feedback. It's another one of these lean principles where we are trying to eliminate that waiting time, that waste, by getting the instant feedback.

The other thing that happens with pair programming is you do sharing of information and sharing of knowledge. So it's a great way to bring someone who's new to a particular module and you might have the person who is an expert in the module. Working together, they get this cross pollination of training and knowledge.

It's a great way to get that kind of feedback. The other thing when we do peer programming is to do with the person who's not actually typing, we call them the co-pilot and they keep the list of all the things they are working on.

They are the consciousness of the other person making sure they keep track of things: don't forget we have to go back and do the refactoring, don't forget we have to do this, or we might want to take a look at this design. They create that to-do list. So together they work very closely to develop the particular module.

Joe: Doesn't one become more dominant than the other, one becomes a primary programmer and one becomes a checker, or do they switch roles?

Patrick: No you switch pretty frequently. You wouldn't program for more than an hour before you switch so you switch quite frequently back and forth.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Helen: And that just helps to perpetuate the knowledge sharing that Pat mentioned a minute ago.

Joe: Is that similar to continuous integration or is it entirely different?

Patrick: It's pretty much different. Continuous integration is when you want to integrate your software as often as possible because when you do that integration you are gaining knowledge about whether or not your code is working with other peoples' code. Continuous integration is making that integration happen all the time. Essentially every time a programmer checks their code in, the continuous integration server is going to take that new code, bring it over to its environment, build the software, and run all the tests.

When the programmers are doing their programming they have unit test for all the codes that they are actually writing. When they check it in, the continuous integration server builds the code and runs the test to make sure nothing is broken.

Traditionally, what would happen is you do your integrations at the end of a long development cycle. You develop code for three months then do your integrations. What do you find out when you do your integrations? It doesn't work.

Helen: Everything is broken.

Patrick: Right, everything is broken. There were misunderstandings and lack of communication. Then takes you a really long time to figure out why it broke and you have to do all this debugging. When you do it continuously you get that feedback immediately. Then you know exactly what broke because you have tests told you exactly what broke. It just speeds up that whole cycle.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Joe: How do you know when it's good enough? I mean, how do you really know - as you are sitting there doing Agile, it's the Lean thing of continuous improvement - how do you know when you have exhausted it? When does the product release happen? As you go through that process, how do you know when it's right, when it ends?

Helen: At the beginning of the process or at the beginning of the release, you define what the requirements are for done, how good is good enough, what are the criteria for the release. Then you have to meet that definition at every iteration. When you implement the feature, has it met the definition of done for that feature? You demonstrate it to the product owner at the end of every iteration and then again at the end of every release. The product owner is the one who says whether or not it has met their satisfaction.

Joe: Now, would you recommend Agile for everyone?

Patrick: I think there are a couple things that come into play; one is the kind of product you are developing. Agile works better for some projects than others. Though I think you can use these agile techniques on any project, it's just a better fit with some than others. I think there are some cultural aspects in there as well - some companies might not respond to Agile techniques as well as other companies. If you have a very command and control culture, then Agile is going to be a real tension in there because Agile gives a lot of control down to the developers. There's a lot of self-organization and flexibility. If you have a very strong command and control culture, that's not going to fit very well.

Helen: I think the other point that Pat mentioned earlier is the scalability. If you have a very large development organization, it does take a lot to scale appropriately to make it work. And that's some of what we have been working on at Xerox since the beginning.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Joe: I always hear Agile mentioned with Lean but I very seldom hear it mentioned with Six Sigma. It seems that Six Sigma is a pretty integral part of Agile at Xerox. Is that different than most or do you think it is quite common?

Helen: I don't know how common it is but it is something that we at Xerox intentionally strove for - the integration of Lean with Six Sigma.

Patrick: I think you might not hear it called Six Sigma in a lot of other Agile communities but if you listen to what they are talking about most Agile communities talk a lot about appropriate measurements and metrics. If you look, a lot of people misconstrue Agile as being no discipline, very loose, and that's not true at all. It's actually a very disciplined process with a lot of good metrics and measures that understand how you're progressing and what you're delivering. Are you delivering the right amount of quality?

So, they may not call it Six Sigma, but it's really about understanding what it is you're developing through a good sense of measures and metrics. To me, that's what Six Sigma is all about, reducing your defects and your variation through good measures.

Joe: What's your typical size of teams that you have in an agile project?

Helen: Typically, we have about seven, plus or minus two. A typical team is comprised of the product owner, the Scrum master, the developers, a tester, maybe a UI designer.

We try to make them as cross functional as possible.

Joe: You've mentioned Scrum. Can you give me just a brief definition of it?

Helen: Scrum is just a lightweight project management method for Agile or iterative software development. Actually, it could be used for anything.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Patrick: Right, it doesn't have to be for software.

Helen: It doesn't have to be for software, but in our environment, that's what we use it for.

Patrick: There are basically three roles and there are five events that occur in the Scrum process. All of those roles and events have pretty critical purposes. In the beginning, there's a sprint planning meeting, where the planning is done for that particular sprint. What's going to get accomplished? That's really the responsibility of the product owner. He defines the what, and then the team goes off and defines the how.

They come up with all the tasks that they need to do to deliver the what.

Then there's the sprint itself, where they're doing the actual work. Within there, there's a daily Scrum where the team gets together and they answer three basic questions: What did I do since the last sprint meeting? What am I going to do today? And, do I have any impediments?

That synchronizes the team. Every day, the team gets synchronized. That meeting is a maximum of a 15 minute meeting, so it's a very quick, brief thing. Get together, synchronize, all right, let's get back to work.

Then, at the end of that iteration, you have a review. That review is, you basically have a team comes back and says, "This is what we delivered. This is what we promised that we were going to deliver. Here's what we delivered."

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Patrick: They demonstrate it to the product owner and any other key stakeholders, whether its management or customers or whomever, that wants to watch the progress of their development. You get another feedback, where the team gets the feedback from the product owner, and are they doing, are they creating the right product? Because that's the most important thing, respond to the changes that our customers are bringing to us; we want to deliver the right product.

And then there's the... The last event is the retrospective, where the team gets together, and looks at what worked in this last iteration, what didn't work so well that we can make some changes.

So, there's a feedback loop, where you have this continuous improvement. So, not only are you iteratively improving your product, but through the retrospective you're iteratively improving the process to develop the product.

So, it's very lightweight, but if done right, it can be very effective in developing product and your process at the same time.

Joe: When you're looking for software developers in the marketplace, do you hold an agile background as an important feature for Xerox, to be hired at Xerox now?

Patrick: I think that's one of the questions that gets asked, is what kind of background do you have, and a history of development. What are your design skills? Are you familiar with certain design patterns? Interestingly now, we're finding as new college grads are coming out, they are being trained in a lot of this now in university, so it's not some underground thing. It's really becoming more and more mainstream.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Joe: Where do you think Agile will go in the future? In the next two or three or four years, do you think that we'll develop more of that process? Is there something out there that you're kind of playing with now that may replace it, or...?

Patrick: I think that, like anything, Agile is, since it's all about responding to change, it's able to respond to changes in the environment, and new information, new techniques. So, I think it... I don't think there will be some sort of revolutionary change, but I think it will continue to evolve. I mean, if you look at Agile five or ten years ago, it doesn't look the same now as it did then. It's evolved over time. There was the extreme program movement.

They were very rigid about what techniques and things you had to do, and now it's a lot looser. Now, it's more of a toolkit. You apply it as necessary. I think that as time goes on, you'll continue to see that sort of evolution occurring.

Again, there are always some new kinds of things coming out. There are people talking about Kanban software development, where they use Kanban techniques to do it. So, there are different ideas that are always being floated, and I think the good ones will stick, and the ones that aren't so good won't stick.

Helen: We are constantly looking at what's out there, and whether or not something might fit within our environment.

Joe: Would either of you like to add anything to the conversation that I left off about Agile and things that Xerox is doing?

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Patrick: I guess the only other thing that I think that we're finding that's really interesting here within Xerox that has been a real challenge for us is dealing with agile development and distributed environments. Because we're a global company, and our developers are spread across multiple coasts and multiple continents. Implementing agile techniques across that distributed environment is really interesting. Done right, it can be extremely powerful, but it has a lot of very difficult challenges that you have to deal with.

And so, that's been one of my more interesting topics right now, is dealing with a lot of those issues.

Joe: That 15 minute meeting in the morning, is it done virtually or in person?

Patrick: Traditionally, it's done in person. It's a stand up meeting, with folks coming in.

You stand up, you answer the three questions, and then you disperse. Doing it with distributed teams, all of a sudden you have to come up with all these different virtual ideas. If you have overlap in work hours, you can use video cameras or maybe just a phone conference. Things like that. But when you're distributed across a twelve hour time difference, then you have to come up with whole new sets of ideas and techniques of how to do it.

That's the thing about Agile. It's all about continually looking at your environment, and improving. It's basically a plan to check... act as sort of a process. You just have to make your best guess. Try it, look at your results, and then change your behavior after what you've learned.

Helen: Since the Scrum teams are fairly small, we try to structure them so that the team members are collocated, so that we don't have to deal with those issues that you just brought up.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Patrick: If possible, sometimes it's not possible, and sometimes it's... One of the experiences I've been observing is that sometimes, actually, forcing the teams to spread across the multiple coasts makes you face the issues that you have, and it can actually expose those issues, and by exposing them, you're forced to solve them. Once solved, then you actually are in a better position. Sometimes by forcing collocation, you are hiding the rocks? There's value in exposing those rocks.

Joe: As I'm sitting here thinking about it, I envision a Venn diagram, that you could have different teams across the globe that you could take a project, a three week project, and turn it into a one week project, just because of the time zones.

Patrick: You can. You can really control that and do it well, you're absolutely right. You could basically have your developers working 24 hours a day.

Joe: That would be for another discussion, probably.

Patrick: Absolutely. Not the same developers to work out.

Joe: I want to thank you very much Pat, Helen. I had an enjoyable conversation, and I look forward to getting it posted. It will be on a Business901 iTunes store, so you can download it to your iPod, if you'd like. And again, thank you very much.

Patrick: Thank you, Joe. It's been a lot of fun.

Helen: Thanks for the opportunity.

Agile Product Development at Xerox

Business901

Value Stream Mapping

Expert Status

Joseph T. Dager Lean Six Sigma Black Belt

Ph: 260-438-0411

Fax: 260-818-2022

Email: jtdager@business901.com Web/Blog: http://www.business901.com Twitter: @business901 What others say: In the past 20 years, Joe and I have collaborated on many difficult issues. Joe's ability to combine his expertise with "out of the box" thinking is unsurpassed. He has always delivered quickly, cost effectively and with ingenuity. A brilliant mind that is always a pleasure to work with." James R.

Joe Dager is President of Business901, a progressive company providing direction in areas such as Lean Marketing, Product Marketing, Product Launches and Re-Launches. As a Lean Six Sigma Black Belt, Business901 provides and implements marketing, project and performance planning methodologies in small businesses. The simplicity of a single flexible model will create clarity for your staff and as a result better execution. My goal is to allow you spend your time on the need versus the plan.

An example of how we may work: Business901 could start with a consulting style utilizing an individual from your organization or a virtual assistance that is well versed in our principles. We have capabilities to plug virtually any marketing function into your process immediately. As proficiencies develop, Business901 moves into a coach’s role supporting the process as needed. The goal of implementing a system is that the processes will become a habit and not an event. Part of your marketing strategy is to learn and implement these tools.

Be Productive, Be Visual

Business901

Value Stream Mapping

Expert Status