MATHENY: Welcome to this IBM Podcast, Lose that Excess Project Weight, Adapt with IBM Agility at Scale. I'm Angelique Matheny with IBM. In this podcast, Scott Ambler, IBM's Practice Leader for Agile Development, discusses the Agile Scaling Model and how it can help you define a roadmap for effective adoption and tailor agile practices to meet the unique challenges faced by your software and systems delivery team. As I just mentioned, Scott Ambler joins us today. Scott works in the IBM's Methods Group developing process materials and travels the world helping clients understand and adopt the software processes which are right for them. Scott is an award-winning author of several books and is a regular speaker at international IT conferences. He's also contributing editor with Dr. Dobbs Journal. Hi Scott, welcome to the podcast and thanks for joining us. AMBLER: Oh, thanks. My pleasure, Angelique. MATHENY: Let's jump right in. Scott, on ibm.com you recently wrote a paper entitled, The Agile Scaling Model: Adapting Agile Methods for Complex Environments. What is the Agile Scaling Model? -1-
AMBLER: Yes, the Agile Scaling Model is a contextual framework for tailoring Agile strategies in an appropriate manner for the situation that the team finds itself in. So one of the complexities I guess of IT is that every team finds itself in a unique situation, and as a result you really do need to tailor your process, the products that you use, your tools, and your team structure to reflect that situation. This can be a bit rough for organizations and it's often not what people want to hear, but it is a reality. And what the Agile Scaling Model does to help people understand the context they find themselves in is that it defines three categories of situations: core agile development, disciplined agile delivery and agility of scale. MATHENY: Scott, those three categories, can you tell me more about them? AMBLER: Sure. So the first category, core agile development, the focus is on construction, so this is where we see a lot of the mainstream Agile focus actually being on. So in the processes, we find the primary goal is to develop -2-
a high-quality system, often in an evolutionary manner, so iteratively and incrementally in a highly collaborative manner and in a self-organizing manner. And what self organization means is that the people who do the work are also the ones who organize the work. They plan it, they estimate it and then they execute on that plan. So we're basically empowering the people in the trenches, using 1980s terminology. It's also a value-driven lifecycle, so what the focus is there is that it's on the regular production of working software. So every few weeks or every month or so the team has more potentially [issue] level software to demo to people and to potentially ship. So management can increase visibility into the project, into these agile project teams, providing them with better opportunities for governance. I'll talk about that in a minute. But for the most part, the core agile development methods are for small co-located teams, developing relatively straightforward software. The next category -- the second category, I guess you would say -- is disciplined agile delivery. So disciplined agile delivery, first of all, extends agile's development methods to address the full system lifecycle. So where SCRUM and XP -3-
and even agile modeling focus for the most part on construction and in a construction-oriented activities, the disciplined agile delivery also explicitly includes project startup activities. It also explicitly includes transition or relief activities as well. And should also explicitly address at least the concept of a production phase. So, looking at the full lifecycle picture which brings a full complexities into play. It also extends the value-driven lifecycle concept to be also risk driven. So, although value-driven lifecycles without a doubt address a lot of risks that we experience on IT projects, there are a few that it misses. So, for example, at the very beginning of the project you want to make sure that the wide range of stakeholders that you're working with come to some sort of consensus, at least they agree on the direction that you're going in. And you should also prove your architecture with working code right at the very beginning and prove it end to end. So we talk a lot about emerging architecture and evolutionary architecture in agile and that's a phenomenally good thing. But you want to make sure that you're emerging towards something that actually works. So the more disciplined agile teams have a tendency to address their technical risks as soon as they possibly can. -4-
It also extends to self-organization which is a phenomenally good practice, with appropriate governance. So, and that can be a challenge in a lot of organizations. A lot of organizations have a command and command control governance approach which can be very challenging for agile people because we're more about collaboration and enablement, not about command and control. So an example of appropriate governance would be making sure...helping the agile team follow corporate guidelines, data guidelines, coding guidelines, using interface guidelines, good stuff like that. Helping them work towards a common infrastructure and other reporting metrics up the management food chain, hopefully in an automated and real-time manner -- so, having good tooling to help support that. But for the most part, this agile delivery is also for small co-located teams. But in this case, instead of delivering software, we extend that a bit to deliver a solution. So there might be hardware involved as well. You're probably going to change the business process a bit. You're probably going to change some of the ways the people organize themselves, the organization structure. All those things can change, supporting documentation. We want to -5-
look at the full picture, not just software. And then the third category is agility of scale, and that's basically disciplined agile delivery but now one or more scaling factors apply making it a little more complex for the team. MATHENY: Scott, what are the agile scaling factors? AMBLER: So, there's eight of them. Usually what happens, when people are first thinking about scaling and they think about team size, which is obviously one of the scaling factors, and often geographic distribution, which is another one. But there are six more scaling factors on top of that. And all eight of these scaling factors are ranges. So on the one end, you've got very simple situations and on the other end you've got very complex situations. And any given team can be anywhere on this range. Now, ideally life is good to you and everything is on the easy end, but sometimes that's not the case. So the eight scaling factors, I named the first two already, geographic distribution and team size. But there's also regulatory compliance, this can throw a few wrenches into the works for you. -6-
Domain complexity -- so that the observation there is that you'll work differently if you're building an informational Web site as compared to, say, building an air traffic control system. So, the complexity of the problem domain that you're trying to address can have a huge impact on the way you work. Your organization distribution itself -- so, life's pretty easy when you're all working for the same company and the same division. But what happens if you're working with people from multiple divisions, or you have several companies that are partnering to build a system? Some sort of industry consortium, for example? Or, what if you're outsourcing some of the work and you're working with contract organizations and/or consultants. So, this can be a bit of a challenge. The next scaling factor is technical complexity. So it's pretty straightforward if you're building a greenfield system from scratch on a single platform. But what happens if you're dealing with legacy software or have to work with legacy data sources? Or more importantly, you've got to clean up that legacy software or those legacy data sources? Or, if you're working on multiple platforms? This can add great complexity, or if you're working with technology that -7-
has never been worked with before. This can throw some complexity into the mix. Then, we have organizational complexity, is the seventh scaling factor. It's nice, I wish that everybody worked for a flexible organization that was politic-free, but many organizations have politics, many organizations have a group of people that want to work in a different manner that are very against working in an agile or lean manner that has very rigid cultures. This can be a very difficult scaling factor to address sometimes. And the eighth scaling factor is what we call enterprise discipline. So, getting effective at enterprise architecture, getting effective at strategic reuse and at [corporate] management having a common operations and support strategy. These are all...these enterprise-level issues cross systems, they cross projects. And they can throw some complexities into the works for the project team. But it can also greatly enhance their activities as well. So this is the one scaling factor that actually, there's some trade-off, and if you're at the complex end of the spectrum you can actually be, your life can be a lot easier from a project point of view if you're doing it right, of -8-
course. MATHENY: Can you walk us through an example of how a common agile practice would be affected? AMBLER: Yes, definitely. So, one of the messages that we try to make clear with the Agile Scaling Model is that when you're tailoring agile processes to your agile approach in your needs, you'll still be following a common set of practices, perhaps. It's very often that's the case. But you'll be tailoring them and following different flavors. So, for example, a very common practice in the agile community is a daily meeting, also called the daily SCRUM meeting. So when you're a small co-located team, that's a fairly straightforward thing to do. You get together for 10, 15 minutes at the beginning of the day and you share your status. You talk about what we did yesterday, and what you think you're going to do today, and identify any problems that you might be running into. Everybody on the team does that. They listen to each other. If there's any issues, they take them off line and they deal with it. So that's pretty straightforward. But if you're a large team, you know, so if you're a team of 10 people, yes, you can do that in 15 minutes. If you're a -9-
team of 50 or a hundred, you can't possibly share, have everybody answer all those questions and everybody listen to each other. That would be a couple hours every day. So, there's different ways you can do it. You can split up into, larger teams are always split up into sub teams, but each of the sub teams can have their daily stand-up meeting. And then somebody from each sub team attends a daily stand-up for the program as a whole. And that sort of works, but it doesn't scale very well, but it's a good idea. Other good ideas, though, could be having, following the [can ban] approach. So for example, in can ban, which is a lean method, they suggest that instead of answering three questions, that you only address the...that people only address the issue if anything is blocking them, if they're running into any problems or if they foresee any problems, then let the overall team know. And otherwise don't even say anything. So then they basically get to the heart of the matter of this coordination meeting. So that scales easily to 50 or 60 people, although, then, you're going to have to deal with your team-to-team type of strategy again. Then, so that's for large teams. If you're geographically distributed, then so if you've got -10-
people in different buildings or if they're in different cities or even in different continents, then you're going to have to use electronic tools. At least you're going to have to use a telephone and have a conference call via telephone or maybe a video conference. Or you might use a tool like Rational Team Concert that's geared for distributed teams to help you manage the communication between the team. If you're in a compliancy situation, then you might have to take attendance of who attended the meeting. You might have to have meeting minutes or action items, just because many regulations say you have to have proof you followed your process. If you're in a complex domain, you might be bringing in some experts to listen in more often on what you're doing and hopefully work with you afterwards. If you're organizationally distributed, some people might not be allowed to listen in on the meetings. Some people might not be able to attend. So, for example, you might be in a situation where there's security issues. So if you've got three different organizations that are partnering with each other, they might not be allowed to listen in and find out what the other organizations are doing. So the way that you organize the communication can -11-
vary dramatically. If you're in an organizationally complex situation, maybe your organization culture is too rigid to even have a daily stand-up meeting, so you could be forced back to status report. So the point to be made is that you're still following this same practice of one of daily stand-up meetings, but the flavor of the daily stand-up meetings, your approach to them, will vary depending on what scaling factors apply and how they apply. So this is something that is often missed in the conversation with the agile community. MATHENY: So does the Agile Scaling Model apply to team organization? AMBLER: Yes, it does. So, for example, there's been a raging debate within the agile community about feature teams versus component teams. So what a feature team is, so you've got this feature that, this [new] feature for the system that you've got to work with, that you've got to build. So you assign it to a single team. A single team picks it up or they come together to address that feature, and then they do all the work that it requires to implement the -12-
feature. The other strategy is called...basic strategy is having a component team. So what happens is each team has one or more components, the overall system that they're responsible for working on, so when there's this new feature to implement, each team does their part of that work then they have to integrate it as a part of a larger team. So there's trade-offs between both those approaches. So the feature team approach works very well when...in situations where you have access to all the software, all the components and you can, you've got a very sophisticated configuration management approach. The component team approach works very well when you're taking a domain-driven design to the architecture so that the architect of the system reflects the domain that you're in. So the results, any given feature will probably only hit one or a very small handful of the components. So depending on which approach, which of the scaling factors apply, so if you have an enterprise architecture that reflects the domain, so if that...so if enterprise discipline applies then maybe a component team approach will work better. -13-
If you have a very complex domain, very complex technologies that you're working with, then perhaps feature teams will work better just because the architecture of the system is not organized around a domain-driven approach. So either way works, either team approach works well. There's trade-offs to both. Neither are perfect. So depending on what situation you find yourself in, one will work in a different context or another. Or often what happens is you'll end up taking a hybrid approach and any given, a very large agile team could end up having some feature teams and some component teams. And that's perfectly fine, too. So just do the right thing for the situation you find yourself in. MATHENY: And how does this affect tool selection? AMBLER: So the fundamental message is you always need to use the right tools for the job. And this can be a bit frustrating in organizations that hope to have a single desktop or a common desktop for all their people. Well, the problem is, all their people are on different teams and each team is in a different situation. So, for example...let's walk through a couple of examples. One of the products is called Rational Requirement Composer. This is a requirements [sketching] it's a lightweight -14-
modeling tool, how ever it is you want to look at that. It's a very, very good product. But that product doesn't make sense, so if you're a co-located team, then it's not going to make a lot of sense for you, because white boards and index cards work very well. But if you're a distributed team, if you're a larger team or you're in a regulatory compliance situation, then white boards and index cards aren't going to cut it. So if you're a larger team and your split between sub teams, there's a need to have a common understanding of the requirements of all the sub teams. So you're probably going to have to have a few shared models that you'll probably evolve over time. So having an electronic version of that makes sense. So, if you're a distributed team doesn't matter how good people's eyesights are. If I'm in a different building or different continent I can't see that white board. So I'm going to have to have electronic versions of these models that I can manipulate. And certainly if I'm in a regulatory compliance situation, I'm probably going to have to have some documentation and index cards probably aren't going to cut it. So there's good, there's very good reasons to use Rational -15-
Requirements Composer in some situations. So this I think is an important thing. And there's other situations, of course. But that's just an example. Another example would be Rational Team Concert. So there's a product that for the most part is geared, was primarily geared for distributed teams, but it also makes a lot...but even if you're not distributed it makes a lot of sense. So, for example, I've seen some small co-located agile teams do very good things and get a lot of benefit from using RTC, Rational Team Concert. And then, when other scaling factors apply, RTC still makes sense, too. So some products, some tools, some products make sense in some situations but not others. And that's perfectly fine. MATHENY: Scott, what are our customers saying? AMBLER: So we've had some very positive responses to the Agile Scaling Model, and I think for a couple of reasons. First, it really does help our customers put a lot of the agile advice and some of the agile tooling into perspective because what we're finding again and again is that when companies first start doing agile, they start with small co-located teams, which is a very smart thing to do. You've got to get your feet wet. You want to keep the -16-
situation as simple as possible. But when they start applying agile in more complex situations and they start applying it across the board, I guess you would say, on many projects in their department, they're finding out that some of these mainstream agile techniques don't work very well at scale. And so what's happening now is that they need, the Agile Scaling Model is helping to provide the context for them to understand the problem that they're in, the situation that they're in and then find solutions that solve the issues that they currently face in those situations. So I think they're finding that there's a lot of value in the Agile Scaling Model that really does provide the context that they need. MATHENY: Scott, is there anything else you'd like to leave our listeners with, any parting thoughts? AMBLER: Yes, definitely. There's a few things. First, please keep your eye out for some new papers that I've got coming out later this year. Well, Rational has some great papers in general coming out, but I'm biased, because I've got a few good ones. By the time actually this podcast is available, I hope my -17-
newest paper, Scaling Agile for Executives, will be available online. And I've got a few details. It goes through the Agile Scaling Model, but I've also got a few very detailed papers coming out in the next few months that dig deep down into the details of applying the Agile Scaling Model in practice. So I think a lot of people would be interested in them. Also, if you get a chance, please drop by jazz.net, all the Jazz-based products are described and available for download there, including both Rational Requirement Composer and Rational Team Concert. So, definitely drop by that site. There's a lot of very interesting things going on there. I think anybody trying to scale agile will start seeing that the Jazz-based tools are going to help them do that. And as well, drop by our agile page at ibm.com/rational/agile. We've got a lot of good agile information there, we've got an agile e-kit with a bunch of reportings and other, white papers and things I think you'll be interested in. You can also download or order a copy of our Agility at Scale poster. We just released a new version of it. We had one for about a year and a half now, but the latest version is looking pretty sharp. So it's definitely something I think a lot of people will want to have on their walls. So take a look at it. -18-
MATHENY: Great, Scott. As always, thanks so much for sharing your time today for our podcast, Lose that Excess Project Weight: Adapt with IBM Agility at Scale. We really appreciate you being here. AMBLER: Oh, thank you. My pleasure. MATHENY: That was Rational's Scott Ambler, Practice Leader for Agile Development. If you're interested in more podcasts like this one, check out the Rational Talks To You podcast page at www.ibm.com/rational/podcasts. And we'll also include a link to the white paper Scott discussed today, the Agile Scaling Model, Adapting Agile Methods for Complex Environments. This has been an IBM podcast, I'm Angelique Matheny. Thanks for listening. Keep tuning in as Rational Talks To You. IBM Podcast [END OF SEGMENT] -19-