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