Pollyanna Pixton: One of the outcomes of our summit today is to have topics that we can discuss as a community, for the APLN community and other leaders, things we should be thinking about, talking about, discussing, maybe research, developing models, looking at strategies. So that's what we're trying to discover today: What we still need to look at and still need to talk about.

Ole Jepsen: Where we are at right now is we did #1 and #2, so we have been through 2 of the 6 stories that were presented here earlier, and just say what some of the highlights were. And, after the panel, we will go back in there and we will have one more story to explore. We are doing that in a fishbowl kind of way and we have just had a quick retrospective in there and everybody loved the fishbowl. So, we will do that a little more. After that we will move towards distilling the really interesting stuff out of the stories we have heard. And we have a lot of sheets on the walls in there now, so that's much material to work with. So, that will happen next in there. And later this afternoon we will connect strategies to situations in the past and project them into the future, so kind of bridge something so that you all know exactly what to do when you get home Monday on Monday and start being a true Agile leader. We had 2 stories: Rick Jonesfirst "Have it their way".

One of my highlights, and you can correct me Rick wherever you are, one of the things that was not new to me, but you said "I make people pair up and make people do pair programming". And is that "Agile" to make people do stuff? Is that Agile leadership? Then I thought a little more about that, and I thought that when people refuse to go to training and to educate themselves, and build up their own personalities and experiences, I won't let that happen, I force them to choose some direction they want to go. What I got out of that was was that it's ok, that even if you are a "soft" or Agile leader, to effectively push people in the direction that you know will make some change. That was one thing I got out of that. And one of the guys in the fishbowl said "I guess I kind of do this, but the thing that we stopping (because we are very close to the users in this way of working), we've stopped just solving their requirements but actually (because we know them so well) we also know that some of the requirements are probably not the right requirements to solve, so we'll do something else, maybe be cheaper to do, or maybe create more business value than if we just do what they tell us to do.

Pollyanna: Now, one of the more interesting times (at the conference) is the panel. This time we have 4 executives that have actually done Agile in organizations, they are not consultants, they are real leaders in organizations. They have done great things, and it's thrilling to have these minds in our community and helping us, and willing to share, mentor, talk and spend their time with us today.

The first one I would like to introduce is Bud Phillips, the VP of Decisioning Services - Capital One, he's been in charge of credit card decisioning, application processing and upper originating services, he has done Lean, Agile, software development, Lean 6 Sigma (I'd like to know more about that one) and transforming from cost to total value thinking in this organization. The next one I want to talk about is Israel Gat, he's been with IBM, Digital, Microsoft, EMC and now with BMC and other companies. He has been growing this kind of companies and positioning companies in new high growth markets; he has brought to market Netview, Celera, MOM2000 and the BMC Performance Manager. Then we have Steven Ambrose, the Director at DTE Energy, he's responsible for the IT at their company's non-utility subsidiaries in diverse energy businesses. He has 19 years experience; from 2002 he has been moving software development towards being a CMMI level 3, class A Agile shop. We are lucky to have him, as well. And Peter George, senior VP of Engineering and CTO at Cronos Incorporated, he leads the company development strategy and has delivered Cronos' flagship Workforce Central product line and he has been moving it from a clientserver to a web-based architecture.

What I asked them today is to give us a list of 5 minutes heads up about some topics that they have seen, issues and challenges they have had, and then we are going to open it up to a Q&A, so be sure and keep your questions.

We'll have two microphones on both sides of the rooms and runners to capture them so you can ask them. Now I turn it over to the Panelists. Thank you!

Peter George (Chronos Inc.) : We were asked to keep this brief and just tell you one little story. The one I chose was to talk about the challenge of introducing Agile beyond the Engineering organization.

I run the Engineering organization across, well we are about 600 people in Engineering, and to a certain extent I can say how things work, so I can mandate change. But we use a combination of an evaluation and an evangelistic approach to motivate the Engineering organization to change, and it was very effective. Over the past year we have completely adopted the Agile process. But another part of the challenge was to have the rest of the company, who feel good about their Engineering organizations, using Agile processes. Because they were used to us using more of a waterfall model, and being able to say up front what we were going to do, say how much it was going to cost and then we deliver our releases on an annual basis, delivered to that plan. And part of the challenge with Agile was maintaining that outside appearance, at the same time as, within the organization, doing things very differently. And the way we did that was that as part as our introduction of Agile into Engineering, we actually called it "Agile light", because we acknowledged that there were these two constraints that we needed to apply to our Agile process to make it fit to our company.

And one was that we were going to timebox our releases to be annual (we had interesting discussions in Engineering about the difference between being timeboxed and being schedule-driven), and that we wanted to do high quality features within the annual time box, but not make schedule paramount, but we needed to do that to maintain our commitment to the company. The other part is that we needed to be able to say a year in advance what we were going to do. And a lot of engineers worried that that was not Agile, to be able to promise in advance what we were going to do. The way we addressed the second issue was in a couple of ways: one was we made the commitment at an appropriate level of abstraction. So as we planned our annual releases, we first talked about high level "themes" for the release. If you think of the effort of about 500 engineers working on a release, we would come up with 6 themes for a release and we will review those with the executive committee at the company and we'll make sure that we have buy-in at that level for what we are trying to accomplish in a given year.

We'll take that down another level to an abstraction we call "headlines". We would have maybe 30 headlines for a release, and those headlines will be things that we will then communicate to the marketing organizations, service organizations, sales organizations, and tell them that at that level we are committing to delivering these capabilities as part of the release. We still haven't approached "features" or "stories", those are two levels even further down and with those we don't commit to the company, those are where we start bringing the Agile process in and where we empower the teams to actually take the headlines that have been assigned to them and figure out what features those translate to, , what the highest priority features are, where they can make tradeoffs, where they are acceptable and complete in their implementations and how to manage their time to fit the constraints. And it has been a great success. We could talk more later, as you ask questions, about how we rolled out the Agile process - but by working with those concepts we were able to preserve the external envelope of the annual releases and the upfront promises of what's coming in the release, at the same time as changing the internal practice of how we actually build the releases. So, that's the little story I was going to tell you.

Steven Ambrose (DTE Energy) : In the story that Pollyanna sent out, the original request said "all right, you need a position on an issue, pick a couple, choose which one you want to position it on", and the one that she picked (and I'm glad she did) is "How Agile leadership ruins middle management". Deliberately provocative.

And what I want to talk a little bit about here is how we... first, some context: So at DTE Energy, we have been on this path from the beginning and really working to institutionalize it across all of our development efforts. So we are an energy company, not a software development company. Our software shop is smaller, an 800 person IT organization with half of those in Development. So significant, in the sense that it is a real organization, not two people on a truck, but still not the massive distributive scale that a lot of companies have. So we have been reasonably, and I would argue very, successful, at implementing and maturing the Agile mindset through our software development shop, and seeing very good results from that. As a result we naturally chose to start applying some of those principles in how we do other organizational things, like lead the organization as a whole, specifically.

We have taken things like the DOI (Declaration of Interdependence) which we didn't have at the time, and started infusing that in how we run the department. Things that all departments have, like status meetings, we changed those to collaborative meetings. It took a couple of years to really be able to infuse that Agile leadership into the organization, but it worked to very good effect. As life always happens, so change happens. We've had some change, we've had different pressures, we had some new people come on the team, some other people leave, some shifting in responsibilities. And there's an interesting problem, challenge, dynamic that we are facing right now, and it has to do with what happens to a first level leader or a manager (a leader-of-leaders, if you will).

When you spend a couple of years engaging them in the leadership process, saying "it's not enough for you to say: give me my orders and I'll execute" but encouraging them to ask questions why, to understand the context for the mission, to question the basis for the decision and really focus on the outcomes. Not everybody buys into that, and it's uncomfortable for some people but you are working hard to try to get that behavior as part of leadership. (By the way that is not the dominant form of leadership training in America). So you go through all that, now you shift some pieces around and get other people in leadership roles, and all of a sudden those behaviors that you have encouraged look very different from a "normal" or traditional, hierarchical leader's point of view.

So you shift a manager who is very successful in this department then get promoted into another department in the "normal" business, and all of a sudden they are asking questions like "why are we doing this? What's our outcome?" and the reaction is "are you questioning my authority? Who are you to ask me these kinds of questions?" And it's an interesting dynamic because that is a the lot that you pick, and whenever a middle manager is freed from the constraints of the traditional hierarchy management and learns to ask the questions, and feels empowered, they are "ruined". So they go to another structure and all of a sudden they can't work in that environment, they become insensitive to the leader, and start pushing. The most effective middle managers will learn how to work with that leadership team and bring them along, but it has been an interesting dynamic as this has persisted over time. That's the topic I wanted to position on.

Israel Gat (BMC Software) : I am Israel Gat and I will be saying a few words about "defining moments in Agile".

My view of Agile is that it is actually like a dog: if the dog feels that I am afraid it will bark or jump on me, and possibly bite me. The point that I am trying to get at is the business of: Whether any one of us who embark upon starting an Agile project, is really, really ready for empowering the teams, in the full sense of the word, or whether one wrestles with the concerns: "oh my gosh, but what would happen if the team goes in a different way than what I planned? Or what would my customers say? What the field would say? What would my boss say?" etc. And I have seen, time and time again, that the number one factor in the success or failure of Agile projects is whether the person who was starting it was really thinking to say "hey there is an integrity of the Agile process, and I'm not going to jeopardize it even if I get in trouble," or whether the person is saying "oh well let's see how it will go and if I get in trouble when I implement it I will change course".

Let me give you a very specific example that we wrestled with 5-6 months ago. We started our release on BMC Performance Manager, which is our number one monitoring system, and for a variety of reasons we had certain hopes that it would come out in the May timeframe. As we went through the detailed release planning, the first 2 days of the release work, what we actually found at the very end of the 2 days when we polled the various teams about their level of confidence in what they said they would be doing, is that 2 out of 5 or 6 teams were actually not confident at all. We could do any one of the traditional tricks that one does in such a situation: "hey you guys are too pessimistic; hey, you have already got the architectural runaway and you will pick up speed; we will plan to hire some new people for you" etc. Instead of any of these answers, what we did was send them back for another day at the drawing board and basically told them "don't do anything to please us, this is not the metric. Give us something that you believe in".

And what it turned out is that we need to come back out in June, and did come back in June instead of May. And I lost a little hair, talking to some customers, but what I heard time and time again from quite a few people in the team is that for them this was a "proof point". But we really mean it, it's not something that I give them and then whenever they get stuck I take it away and then kill the whole process. But that it's something, even if my own neck is, the single wringable neck, it is something where I share the responsibilities with them and I trust them as much as I trust myself. My advice to every one of you: if you take up Agile, think in advance, to the extent that you can foresee, how would you behave in any of the awkward minutes that Agile can lead you to, and think very carefully if you are ready to say "I will take the heat of doing Agile because the benefits on the long term are bigger", or are you going to step back at the point in which the going gets tough. Thank you.

Bud Phillips (Capital One Financial) : My name is Bud Phillips; I am with Capital One, very happy to be here this afternoon. And Pollyanna got back with us on a couple of topics and the one she wanted me to address was essentially "going after total value in production".

I will tell you a bit about the context of what I mean by that and where I am coming from. I had a group at Capital One that basically receives and processes credit decisions, and identity checks, nearly all of the applications for products that Capital One offers. In that context I am not in the IT world, I am in the operations execution world. But as you all know right away I am completely dependent on my IT colleagues to either have that complex information factory up and running, as well as the development portion of those colleagues to put new features and new capabilities into that process.

As we at Capital One have moved down this path of getting to understand Agile as a project approach and using that for development what I really wanted to do was not stop just at the Agile project level, I wanted to combine Agile thinking with Lean thinking and I wanted to get to a total understanding of all the work we do as a system and get total value flow in that entire way. And where we are today is we have a production group, and then our team has between 5 and 10 standing integrated delivery teams, that are made up of IT colleagues as well as other people who are part of the value stream of getting that work to go, and what we are pushing for is getting all performers in all of the 28 processes that make up what we do, getting them all to understand not only the value of their individual work, but the value of their work within the context of that entire system.

The most fascinating thing about this, if you really step back from it is the following: Capital One's business strategy, like that of many companies, is built on being flexible and being able to do different things in the market place, and in many ways that business value is highly expressed in the area that I run, because we are really a micro-segment of credit, and we like to offer different products and different product terms to different portions of the market, and this means that the infrastructure that we have for dealing with that must change all the time. We probably reconfigure it somewhere between 30 to 100 times a year. So, that has to change all the time. But at the same time, how we deal with those (credit) applications and process them has to be completely accurate.

So I've got these 2 competing demands, it has to be completely accurate, it has to be exact, otherwise the value that the business was looking for in a particular marketing campaign or strategy isn't really realized, or regulators and auditors and so on will say "hey, you have done a couple of things a little differently there, and you are either breaking the laws of the US and Canada, or you are risking some type of problem". So it has to be incredibly accurate. But at the same time I need people and processes that can be incredibly creative and innovative at the same time. Bringing together these twin cultures of almost "Lean/6 Sigma" manufacturing accuracy and the culture of Agile innovation and creativity is the path that we are on and where we are trying to go. As I said in my description, I love what I'm doing. Now, that doesn't mean that I know what I'm doing, but I love what I'm doing. Thanks.

Pete when you were talking about your annual release timebox you were talking about the high level "themes". Could you give us an example of what a high level theme might be, so we can conceptualize it?

Peter: "Refresh the user interface for the whole suite of products" would be an example of high level theme.

I would like that broken down into a couple of "headlines"

Peter: A "headline" under that might be "providing a new navigation system to get through from application to application", another one might be "providing a new launch page for the suite", and things like that. I don't know if I can tell you the "story" because I am not involved at that level. But taking the example of the new navigation technique, we went from a theme of "a fresh user interface" to the headline that we want to "have a more contemporary navigation system", to features that might include "providing a new tree navigation widget," for example, and "within the widget being able to provide the ability for the end user to configure what's visible and what's not visible," and "how they are grouped" and features like that. As I said I am not sure I am the right person to take you down to the story level because the story level for us is planned as part of the two weeks iterations that the project team does and that's really a one or two-day work item. So at that level I have no visibility into what goes on in the organization.

Peter: So, the question was: if each of us could give a brief statement of how Agile was introduced into the organization, whether it was a bottom-up or top-down. and I will go first...

Peter: In my case it was introduced top-down. We moved to an Agile process because I believed that as the organization was growing larger, and as the scale of what we were doing (we deliver about two dozen integrated applications) was growing larger, the complexity of dealing with that scale was slowing us down and was making it tougher and tougher to do the job. So, I was looking into a way to get on a different curve in terms of engineering performance, and so we did an evaluation using help from the consultants from the Cutter Consortium to benchmark our current environment and confirm my suspicions, and then based on that I started down the path of Agile and really draw that motivation through the organization.

Israel: It's funny that you ask this, and I will give you a very funny answer: I started it top down, when I joined BMC about 2 years ago.

Israel: Some of the teams made such phenomenal progress that I went to meet with them to understand why it was working so well. And one of my developers told me: "we were dreaming about doing Agile". At that point I realized that the desire was much bigger than I had realized and that actually all I needed to do is to provide the air cover for the initiative to go bottom up. Now, I don't know to what extent this is a universal phenomenon - namely, if you go to a company which does ELT or does healthcare, whether you will find the same desire to do Agile. In my case I thought it would take me a longer time to socialize it and have it assimilated, and basically all I needed to do was to put the spark in and then provide the air cover, the guys together with the consultants did all the rest.

Steven: In our case started pretty early. Glen Allen (?) came to us from Netscape and had friends and visibility into the seminal work that was being done there, and so it was top down in the sense that the CIO believed that we should be trying something different.

Steven: We had this matter in the early days, it says "one person at a time, one team at a time." So we were figuring it out as we went, in the Agile language we use today, but we literally started with a single project, some consultants, and we started figuring out "it was a success, let's do 2, let's do 3". And at some point we said "ok this is good, we really want to start institutionalizing this more broadly". So, it was a top down "cover", but one team at a time.

Bud: I think when you frame the question as as bottom-up or topdown... I think over time it's going to be both. At Capital One I can point to maybe 3 phases, and we are in the third phase right now.

Bud: What I would say is that the first phase was simply a realization, on some partsone of the Capital One business side of being incredibly discouraged and challenged by our time-to-market, whether that was top-down or bottom-up is not important because there is really just a business side saying "there's got to be something better, let's find something better". And then tapping into what I think is the incredible energy and adaptability of many people in our company, and finding some folks who did want to experiment, and that was truly at the level of the working associate who creates value, truly at that level. Phase one it was just piloting, let's try it, let's learn as we go, let's enjoy it, maybe there's a little rebelliousness or renegade-ness going on during that time, but we are going to go and demonstrate and do this. And, if things are successful there is a reflex in our company that basically was: "wow, that's successful, we're kind of interest in that! Why is it successful, and can we adapt it or adopt it also?" That's when we started to getting into the second phase, where other groups and other leaders, as well as other folks who wanted to become Agile teams, started to do it. I saw a public statistic that about 30% of our development across all of the US Card organization (which is the large portion of Capital One), is Agile right now. We are in the third phase, really figuring out what portion of the portfolio of efforts are Agile and which portion are, rightly, waterfall. It's been an up and down synchronous thing, if you will.

Pete I listened to your talk the other day about the Big Bang implementation and in my experience it seems like you get to a point where you ask other executives to make a leap of faith about a transition like that. Do you have any advice or comments about how you bridge the gap there, like in your particular case, how do you make sure your peers on the business side don't think you are risking the entire business model with a Big Bang change like that?

Peter: It's a good question, thanks for coming to the session earlier this week. I think that one of the real advantages I have at Cronos is that the engineering organization had confidence of the rest of the company, we were NOT broken. We were regularly delivering high quality, we were delivering the capabilities the company needed, so I was trying to get ahead of issues right in the stream, and take the organization to a new level. So, given that starting point, people saw it astrying to take us to a new place and to do even better things. They gave me the rope to work with, they said: "this is your shop to run, you have been doing a good job, if you say it's the right thing to do we'll do it". So, actually that was the least of my problems, it was a very soft sell to the rest of the company: I explained to them the motivation and people quickly jumped on board.

I will say that I'm sure they were holding their breath. And a number of people who worked for me believed that I had put my badge on the table I was betting the company on this move. So, they were wondering about that, there was perhaps more concern within my organization than outside the organization. One thing that helped a lot was that we embarked on doing this over a year cycle, because that was our annual release. In July last year was when we launched the switch to Agile and in June this year is when we shipped the release. And we did that and delivered it with all the content we had planned. As I mentioned earlier this week, one of the things that really helped in terms of the rest of company was that as is consistenct with Agile, some of the requirements changed, some new things came up within the release.

And one of the things that came up was a request to deliver a new product, and that's something that normally would have been quite a challenge to us, given the annual cycle and all the forces in motion. Using the Agile processes that by now we were a little bit more experienced on now, this was about the 6 to 8 months points in the release, we quickly put a team together, got them engaged with the customer's for the new product, and got the product out in 2 to 3 months.

This was something that I don't know if we could have done before, I suspect not. We accomplished the mission in a time-to-market sense that was just revolutionary. And then the other thing was that to do it we engaged the sales guys, the marketing guys, services guys, all those people in other functions who were wondering what was going to happen. And they loved the experience. Stories are powerful things, so we suddenly had this story in the company about this product that has been developed out of nowhere in a collaborative way using the new process that got people asking: "Hey, can we learn a little more about the new process?" and "Isn't that great, what we're doing?"

Q: There's industry-wide a great push for a lot of PMOs (Project Management Offices) in IS organizations to improve practices, and Agile seems to fly in the face of some of their practices, and depending who you are you think it's complementary or not. I would be curious to see what all your opinions are.

Bud: I will offer one. I find an overall level of PMO can be valuable if it really is looking at the total portfolio view and not trying to micro or too controlling, but that's a big "if" and I found that most PMOs are a waste, they are just not that helpful. One of the biggest things that we tried to do over the past couple of years is simply say: "you know what? We are not really interested in one project, and one waterfall delivery or one Agile delivery; we are interested in all of them and we are interested in them as a stream of work". And so looking at that total portfolio, if you will, and starting to thin about it in terms of work-in-process, and work-in-process capacity, and draining things out of it or waiting to start things, has been the path that we've been headed down. And so at this time the function of, let us call it a global PMO, or a very large program PMO, can be simply gating work, gating requests before they can get into the different parts of the company. That has been just instrumental, as a context or a macro factor in allowing Agile teams to work in quicker cycle times - it's kind of indispensible.

Israel: We actually found the PMO organizations to be immensely instrumental in doing Agile. As a matter of fact, two people from my PMO organization are here at the conference Eric Justine and Pam Wolf. If you have the opportunity I'm sure they would gladly speak with you about their experiences. I think the trick to benefitting from the PMO organization is the business of making them full stakeholders in what we are doing, and in the exposing them to the methodology. To "jump" on a PMO person unready to be exposed to Agile and ask him to run an Agile project, before he or she got their bearings, is probably a recipe for failure. However, you invest in them just like you invest in dev or in product management or in anyone else in terms of : "here is a methodology that could work even better for you, and enable you, and us, accomplish what we jointly want to accomplish, you go about it this way...". Our results, at least, and I think they can be generalized, have been very, very encouraging.

Steven: We are struggling through that even as we speak, so through the change process (and we run into this time and again in organizational change), if you think about the purpose of the PMO with a normal project portfolio it makes a lot of sense. And the folks that have generally ended up in PMO have that career path (PMP certification, large projects, etc) and they end up in a PMO. And then you get the Agile anti-PMO mindset that defines that as bad, and you have this organizational conflict, this emotional tension. So, what we are going through right now as a leadership team is: we want the value of a PMO, and we define that differently, maybe, than we defined it in the past. As opposed to the "subject matter experts, that train and mentor all project managers" kind of PMO and dispatch those things; rather more of a portfolio view and like Bud is talking about, the stream of value view, resource view, this type of thing. And it's been a struggle, we are right in the middle of that battle. We are not dismantling our PMO - we believe in the nature of it, we think it needs to be repurposed.

Peter: We don't have a Project Management Office and I don't expect we will in the foreseeable future. I think what we have done is: we have taken the various roles that the group might perform and distributed them. So, for example, we do have a very robust portfolio planning and resource allocation process, and that's driven by a combination of our product managers and our architects, who work together at the front of the release to identify the most important business priorities and to roughly cost them out and to balance capacity with desire, to propose an investment portfolio for the year. We also have a thing we call a suite management team which is responsible for operationally dealing with issues involved in pulling together and integrating a suite of applications over the course of a year. And then the traditional "pure project management" role, we actually embed in our organizations, so our teams will consist of development, and QA and product management and project management and tech pubs and anyone else I have forgotten (I don't want to offend anybody). But they would all be within a single organizational unit, so there's not a separate PMO that's managing that, those capabilities are embedded in our organizations.

Israel: We would like you to take a minute and expand the question a little bit to suggest a way to look at it. It's not about the PMO, it's about the key stakeholders in what we are doing. One way to look at what we are doing is we produce a sausage, once the sausage is produced there are some people, marketing or sales, or field, who will pick it up and run with it, and you can think about the PMO (if you choose to) along similar lines. I would contend that if you go in this fashion you only get part of the potential of Agile. And often you will find yourself in a situation where you produce a sausage faster, better, etc, but the rest of the organization is not geared to going Agile end-to-end and as a result can't benefit out of it.

My recommendation to anyone here: think about your support people, think about your sales people, think about your software consultants, marketing etc, and see in what manner do you want to embed them into the Agile process. To give you one example, very early in the life cycle of some of our products developed with Agile, we gave Rally licenses to people in support and told them "look, you might not necessarily be interested in how we do the sausage but here is a vehicle by which you will interface with us to manage the requirements, etc.". It worked wonderfully, what we found out is that we were not only getting very good data from those stakeholders, but they turned out to be wonderful evangelists, they feel they are part of it, they feel it is very valuable, and these days when I really need to spread the good word around I simply go to those people and say "guys can you help me, we goofed here, we goofed there, explain to your constituencies what happened". Think about Agile, and it can be very challenging, in terms of end to end - it's not about just producing the sausage, it's about selling the sausage and selling it with great profit.

I think it is great we have a pile of pretty senior people with larger organizations, so I wanted to ask you about 3 things that all relate to scale: the first one you sort-of just commented on was: 1) how are you doing program or multi-project management, where there are these dependent projects that fit together, the next one is: 2) larger projects that require larger teams - how are you scaling that, and then finally: 3) how are you scaling over time? There's lots of literature and case studies on the RAD (Rapid Application Design) movement that iteratiuve development can lead to pretty crufty code bases that often have to be scrapped, and I have certainly been into an organization where I took over from some manager and we had to scrap a code base and took about 9 months to replace it, which (considering it had taken 3 years to make it) wasn't bad, but senior management doesn't like the idea that we had to scrap the code base. I am interested in whether any of you have seen that, whether you are suffering from it yet and how you are dealing with the other scale problems.

Steven: I will jump on that first. For multiproject dependencies - again, we use PMO more for visibility - we lean heavily on a couple of people that really have good systemic view of our whole system and enterprise, to look for those loosely-coupled places and break that appropriately. We certainly have used Agile on large projects and essentially what it comes down to is breaking it into pieces that make sense. You bust it down like you do any other project. And we've used that very successfully. What we've found happens is: when you do that, you end up with a central coordinating function, architecture and the like, that has to conduct some of the pieces because they are never totally autonomous, as much as you would like them to be. But we've done 70-, 80-person projects that we broke them down into teams of 7 to 11 and divide the work. And the last one, the scaling over time: inherently code base is fit for use at the time that you built it and to design for the future is always good but only as much as you need to, and that's always a challenge and the way we have dealt with that very specifically is a strong technical architecture discipline. We have a TA group, every project has to have TA participation, and we strongly believe that if you get that foundation right, there's tons of reusable stuff, even if 3 years down the road you look back and say: "we have written everything over time", you never face that ugly conversation where you say "Give us a million bucks and we'll give you what you already have".

Bud: On the large teams or multiple teams front, I'm in the same camp, we are just finishing some work that was the equivalent of, say, 5 Agile teams, and they are going to go for a year and a half, and the key thing that we tried to do there is chunk the work, break it up into these component pieces that a team can go after, but also we are huge believers in face-to-face communication and co-location, so if we are going to put an Agile team together and have that co-located and then when we are going to have 5 Agile teams that need to talk to each other a lot, we are going to co-locate them too. So clearing out the floor or whatever it is, moving the real estate around and saying: "this is where you work and this is how you are going to communicate", it has been our bias.

I will remind everyone again that I'm not an IT professional, and your last question around "hey is the code base going to get messed up and too complex, and we are going to have to scrap it" it's a concern I have, and it is something that is on the agenda for us, our area, with my IT colleagues to establish a more integrated architecture capability that looks not just at the software and hardware technical components but also the operational use of that. And so again, just to emphasis the theme, we are very interested in total business value, not this function or that function, and the lens that we put on everything that we either see as a problem or we want to go after is: "all right, what's the full value stream of knowledge that I would really want represented, to help me assess whether or not we are going down the bad path and 2 years from now we will have to scrap an entire thing?". We'll figure it out; I'm completely comfortable with learning that as we go.

Israel: Let me give you a few numbers to give you an idea of what we know how to do and what we do not. At this point at BMC we've got about 400 people scrumming furiously. The biggest project is north of 200 people, I think something like 250. I will tell you for sure, and we'll give you the "secret sauce" in a minute, that they can work successfully at those levels. We have plenty of proof points. We have our failures, don't misunderstand me, it's not that it was all sun and honey, but at this point in time we know how to do Scrum in an effective manner at this level. Now, with respect to your concern about "will I need to scrap the code base?" something that keeps you and my colleagues on the panel and myself awake at night, I found at the point in time that they became "always releasable", this faded away.

Until we reach this point of being "always releasable", frankly there was no way to know that we really did Scrum the way it should be done, or doing some kind of quasi-waterfall. It's only at the point in time when the code was always releasable and you don't put a next feature in until it works, that we reached the virtual cycle in which, whatever the code, was it was quite adequately debugged and quite adequately robust to continue to function in such a manner. If I take a look at our evolution, I would say that the period until we managed to reach the "always releasable" state of affairs, we were playing (in the best sense of the word) with Agile but I don't know if I could say that we really did a good job at it.

As of the time when we reached the "always releasable," life became immensely easier at all levels, and I sleep very well at night at this point in time. With respect to the business, how do you manage at this scale of operation, I will give you a very funny answer. I think that the traditional structure (you've got sales, support, marketing and engineering) stands in the way of really succeeding in Scrum, big time. After 6 or 9 months of doing Scrum, we changed the structure in such a way that all the functions are represented, to the extent feasible, within the fractal Scrum units - and certainly at a higher level that the structure is not made by sales, support, marketing and engineering, the structure is made by a set of people who are committed to a release. Once you are able to do it you can concatenate, and add on Scrum teams almost to your heart's desires.

Again, I will qualify, we are doing it for 250 people at this point in time, but everything that I have seen I think is a strong indicator that you could do more. So at the earliest possible time that you've got enough political clout to say "hey guys, our traditional structure - sales, marketing, finance and engineeering - is a hindrance, is a waterfall-ish structure," and you need to turn it by 90 degrees and make it into "this is a project team for a project XYZ," at this point I would say you can start growing in an almost unbounded manner. Peter: A part of my answer is the answer I gave to the PMO question, which is why we have a single PMO and instead of dividing the workup in the way I described, was because we were managing from day 1 a very large project by using Agile methods. We used Agile from the very beginning, we are talking about 400 - 500 people who are interconnected and interdependent in some way, shape or form. I would say the hard part for us has been trying to figure out the level of granularity. We all know you need to break the projects up, you need to break them down into smaller units, and when we first launched into Agile, our teams launched into that hardly and broke themselves down into very small teams, maybe 4-5 developers, 5-10 people cross functionally.

And created these small Agile teams, so we had 4-500 person organization, and 40-50 teams like that. What we found was that it didn't work, it was too granular, it took our product managers and have them show up in countless Monday morning kick off meetings and things like that. Now our project teams are more like 20-30 people teams and roll up into product teams of slightly bigger scale. So we are still trying to find the right balance and I think there is a balance between being too small and being too large.

The other thing I would say about that is that I don't believe that we can accurately plan individual projects. I think part of that is the state of our industry, it's sad to say that we can't get individual projects precisely right. So what I do is I take my senior managers and I give them a portfolio of projects and I give them the resources that they ask for the portfolio of projects and I ask them to manage the whole thing. As part of that I expect that they are going to flex resources and flex whatever they need to do across the projects to get the portfolio to come out right.

And I believe we've been extraordinary successful at doing that, and we've extended that into the Agile process so that uncertainth, those risk factors, we give people some leeway in the constraints. That's one important way we do that, is we give the senior managers enough projects for their portfolio, so their projects can help each other out. And the last question about code, actually I don't think it's specific to look at Agile or waterfall, we have plenty of code rot before Agile, I expect to have plenty of code rot after Agile. I think it has more to do with great software engineering practices and the craft of software engineering, and I think Agile helped because we will not in a silly way help the code rot, because we deliver highly architectural services from day one, but the architectural questions, the questions of object structure and things like that, those are hard questions, I don't think Agile gets that directly, I think that's something we have to look at from a different angle.

With regard to extending the Agile approach beyond project teams, more to integrate with the rest of the organization, I'm interested in hearing what's your next challenge that you are about to tackle, or what's something that has been in the back of your mind and you know you need to solve, but it's too complicated and you haven't been able to get there yet.

Israel: I would propose that it is the mental shift between: one-to-one mapping of what engineering does and what marketing and sales does, versus many-to-one or a one-to-many mapping. And here is what I mean by that: we finished a release, and let's say we deposit it in the repository of software development, I told my marketing and sales people quite a few times: "I don't expect that you promote it and I don't totally expect that you would sell it, at the point in time in which we put it there". Your customers may not be able to cope with so many releases; you may not have the resources to do a good marketing campaign, brief the analysts, etc. Bear in mind that what we were trying to do is to provide you with as much functionality and with as much modular functionality that you can pick and choose what is the right time for the market or what is the right time for the resources for the organization, etc. This may sound to be a relatively straight forward step but what I've actually found is that it's very difficult for organizations who are set in their ways to operate in this manner. It is always the same thing, "Oh, release 2.1 is coming out in July we must start doing the whole set of activities that are necessary to promote it." Even though I, as a business owner, say "I'm not quite certain that you need to do it, it's ok, we just introduced 2.0 a few months ago, so build until we are ready." There is a major mental shift from one-to-one mapping between what R&D does and the rest of the corporation does to, to a many-to-one mapping, which I think is a most tricky piece in making Agile end to end.

Peter: I think the companies are sort of tempted to jump and say "let's do it because we can" but not sure if that's the best thing for the whole company, for the service organization, long term support, for the customers adoption rate for all those issues, I think this is one category of business practices. I think the other opportunity for us in particular is around technology and architecture. What I'd like to see us reduce some of the constraints that are holding our suites together so tightly and forces us to shift all products on the cycle annually. We can take our younger products and shift them more frequently, take our more mature products and shift them less frequently. The Agile process will help us do that, what we have done with our team will help us do that, now I've got to get the architecture and technology and catch up to that.

Steven: I wrote two things down: one is the natural forces of entroy - life happens, people change and organizations change and it takes a tremendous amount of effort to not lose whatever ground you've gained. And the best way to do that is try to institutionalize beyond the personality. And the other piece which I think is more universal and challenging one for us right now is the sideways challenge. Our business partners love the way we do this stuff, we had no problems with that, we have high cover at the executive level, but you get nit-picked all the time - so the Finance CFO comes along and he says: "how do we know we are not paying too much for IT? Benchmark against [whatever]," but the industry is not that mature and we can wave our slides about "it's not about cost it's about value," but you have all those natural corporate pressures to deal with IT as an operational force and squeeze and optimize, etc.. So, it's an interesting defensive work that needs to be done, to not let that eat away at you.

Bud: What I would go with is that - there are two things that we have to look at: one of them is: as we have deployed Agile as a way to deliver, the real clients of that within capital One, who value it the most, which are our business that are now competing in the market place and said "I need more of that; that's what I want". And so get ready to enter a period where the demand for innovation will increase, and our capacity to deploy those teams, we think, is technically limited by our support tools. And so we are going to take a hard look at those and figure out if there are changes we can make, that will effectively increase our capacity by increasing [sic] the cycle times of our Agile teams.

If we can do that I think we are going to be in good shape. The other thing that Steve really got into is that in a large complex company there are staff groups, whether they are audit people or finance people or whatever, and they will come along and what they want to do is assure themselves that we are properly accounting for the business value-add that they need. I think that part of the agenda for us is going to be persistently reconnecting what they ask for to the total business value that we were trying to deliver in the market place, and kind-of reframing their questions. So: "What we have found is that we have increased our cycle time, the quality of what we do has gone up, the ... of our client ... has increased immeasurably and our productivity is much higher and our cost is lower."

It's really just a wonderful place to be in and anytime someone comes I and says "I want to look at your costs" my reaction now is "Good let's talk about the value we're delivering and then I'll get to the cost but put it in that complete context," and I'm not going to let you frame the question in a particular way: "hey we are going to come and take a look at the client risks that you are creating". And I say "OK, good, we'll talk about that but it will be 30 minutes before we get to it, let's talk about the total value we are delivering." That's the persistence that I think has to happen, to take this way of Agile thinking and use it at the enterprise level as opposed to let it get trapped in a box that doesn't need to be in, which is "OK, that's a faster way to do projects in IT", and if you leave it there, as all these folks are saying, you are missing an opportunity for ultimately a pretty significant competitive advantage.