Agility@Scale: Strategies for Scaling Agile Software Development

It's customary to start a blog by describing the vision for it. Although this vision will undoubtedly evolve over time, it's always good to put a stake in the ground to get things started. Agile software development is clearly taking off and in my opinion is becoming the dominant development paradigm. Furthermore it appears that Agile approaches enjoy a higher success rate, providing better value for your IT investment, than do traditional approaches. Although organizations are succeeding at simpler projects with agile, many are struggling when applying Agile in more complex situations. They're finding that the "Agile rhetoric" doesn't always live up to its promises once you move into these complex situations. My goal with this blog is to share strategies for applying Agile techniques at scale.

When applying Agile strategies at scale you are likely to run into one or more of the following complexity factors:1. Geographical distribution. Is your team, including stakeholders, in different locations? Even being in different cubicles within the same building can erect barriers to communication, let alone being in different cities or even on different continents.2. Regulatory compliance. Regulations, including the Sarbanes-Oxley act, BASEL-II, and FDA statutes, to name a few, can increase the documentation and process burden on your projects. Complying to these regulations while still remaining as agile as possible can be a challenge.3. Entrenched policies, people, and processes. Most agile teams need to work within the scope of a larger organization, and that larger organization isn't always perfectly agile. Hopefully that will change in time, but we still need to get the job done right now. Your existing culture and organization can really hinder your ability to scale agile approaches, then a few "simple" changes can really help your efforts.4. Legacy systems. Although the politically correct term would be "proven assets" the reality is that it can be very difficult to leverage existing code and data sources due to quality problems. The code may not be well written, documented, or even have tests in place, yet that doesn't mean that your agile team should rewrite everything from scratch. Some legacy data sources are questionable at best, or the owners of those data sources difficult to work with, yet that doesn't given an agile team license to create yet another database.5. Organizational distribution. When your teams are made up of people working for different divisions, or if you have people from different companies (such as contractors, partners, or consultants), then your management complexity rises.6. Degree of governance. If you have one or more IT projects then you have an IT governance process in place. How formal it is, how explicit it is, and how effective it is will be up to you. IBM has been doing a lot of work in this topic over the past few years, and just recently Per Kroll and I have done some work around Lean Governance strategies. 7. Team size. Large teams will be organized differently than small teams, and they'll work differently too.8. System complexity. The more complex the system the greater the need for a viable architectural strategy. An interesting feature of the Rational Unified Process (RUP) is that it's Elaboration phase's primary goal is to prove the architecture via the creation of an end-to-end, working skeleton of the system. This risk-reduction technique is clearly a concept which Extreme Programming (XP) and Scrum teams can clearly benefit from.

It is definitely possible to scale Agile software development to meet the real-world complexities faced by modern organizations. Based on my experiences, I believe that over the next few years we'll discover that Agile scales better than traditional approaches. Many people have already discovered this, but as an industry I believe that there isn't yet sufficient evidence to state this as more than opinion. My goal with this blog is to provide advice for scaling Agile so as to increase your chances of success.

So, it looks like I have my work cut out for me. My strategy will be to address common questions which I get when working with customers and with internal IBM development teams. I have the privilege to work with a variety of software development teams worldwide, helping them to become more agile. They're all struggling with the same basic issues although don't recognize it because they're too focused on their own situation. So hopefully I'll be able to spread the word about what's actually working in practice.

I hope that you stay tuned.

- Scott[Read More]

1. Be crystal clear about what "not-for-profit" actually means.  This is a wonderfully deceptive term from the US tax system which can make organizations appear far more virtuous than they actually are, which is particularly easy in situations where the audience doesn't have a sophisticated knowledge of finance.  Not that I'm implying anything.  Although we have taken some steps to explain the implications of what being a "not-for-profit" organization means, we could do a lot more by being less self-serving.  Yes, the SA isn't a for-profit organization.  The implication of this being that we need to spend the money we rake in, but it doesn't imply that as individuals we can't make a lot of money via our SA work.  I'm not taking on the position of Managing Director for free after all, and I'm sure that previous MDs have found the position lucrative.
   
2. Publish our salaries.  To live the high standards which we espouse through our rhetoric, we're going to be very clear about the way that we operate.  This includes publishing the salaries of the employees of the SA and the revenue derived from Scrum training of all of our certified trainers. Part of being respectful to our membership is to be clear about how we spend their hard-earned money.
3. Publish how we spend the rest of the money.  After we pay ourselves, how much do we really spend on supporting user groups, education, and research as we claim?  Don't you think you deserve to know?  I certainly do, which is why we're going to ensure our finances are no longer opaque.  With tens of thousands of members and/or "certified masters" running around out there, it's pretty clear that we making a lot of money.  To guarantee that money is being spent appropriately we're going to share with our membership where it's coming from and going to.
4. Publish our meeting minutes.  This will be both in written form, e.g. traditional meeting minutes, as well as recorded form (ideally video but at least audio).  The only way that our membership can be assured that we're working in an ethical and integral manner is through complete visibility into our operations.

The fundamental idea here is that the Scrum Alliance should have nothing to hide from our membership. We've preached open and honest communication for years, now we're going to start actually living by those words.  Yes, it may be a bit painful to work to this level of clarity, but we feel that you deserve this.

1. Increase investment in research.  Although we've big claims about support Scrum research over the years, very little has actually come of this due to lack of funding (see discussion of salaries above) which can be seen in the serious lack of research results posted at the SA site.  Of the six publications at the site tagged as research results, three were performed by Carnigie Mellon University, the home of the Software Engineering Institute, producers of the CMMI.  Although I personally respect the work surrounding the CMMI, not that I agree with all of it, I'm concerned about relying on CMU for half of our Scrum research results.  We can and should do a lot better, and the first step is to divert some funds away from our own pockets into research.  Having actual empirical results, as opposed to espousing rhetoric about empiricism, will go a long way towards more respectful behavior via actual fact-based discussions.  Until then, you may find my IT Survey Results page to be a valuable resource. 
2. Deprecate the Certified ScrumMaster (CSM) certification.  Although I would prefer to end this embarrassment immediately, we need to be respectful of the fact that CSM courses have been scheduled several months in advance and some people have already paid for seats in them.  So, as of June 30th 2011 the CSM certification will be deprecated.  This should give our Certified Scrum Trainers time to rework their business models and focus on more respectable activities.
3. Existing CSMs must clarify the certification.  People who have previously "earned" the CSM designation will be grandfathered in until December 21st, 2012 in accordance with the Mayan Calendar.  However, until that time all CSMs who choose to indicate their designation publicly (many CSMs choose not to) in email signatures, business cards and so on must now use the following wording - "Certified ScrumMaster (earned by staying awake during a two/three day training course)".  This wording reflects our new desire for clear and open communication as well as for being respectful.  Far too many people are fooled by the terms "certified" and "master" and we're going to do our best to reduce this problem through greater clarity.

1. Does the team regularly produce value for their stakeholders?
2. Does the team validate its own work to the best of its ability?
3. Are stakeholders actively involved?
4. Is the team self organizing?
5. Does the team strive to improve their process?

Some interesting results include:

• 94% of teams which are claiming to be agile are providing value to stakeholders on a regular basis.  
• 87% of teams which are claiming to be agile are validating their own work.  
• 95% of teams which are claiming to be agile are working closely with stakeholders.  
• 56% of teams which are claiming to be agile are self organizing. 
• 88% of teams which are claiming to be agile are improving the process that they follow throughout the lifecycle.  
• Teams which are claiming to be agile often aren't.  53% of "agile teams" meet the five criteria, although 72% meet all but the self-organization criteria.
• Teams which are moving towards agile but aren't there yet are reasonably close.  39% of those teams meet all five criteria and 63% meet all but self-organization.

• Whenever someone claims to be on an agile team you may want to explore that claim a bit deeper.
• The low level of self organization may be an indicator of cultural challenges with organizations in that their project managers aren't giving up sufficient control.  The Agility at Scale survey in November 2009 found that 59% of respondents who indicated that their organization hadn't adopted agile techniques yet that a rigid culture was hampering their efforts.  The IT Governance and Project Management survey in July 2009 discovered that "questionable behaviors", many of which were ethically questionable (I'm being polite), were far too common within IT project management.
• Although "agile teams" may not be as agile as they claim, they're still doing better than traditional V-model teams, as revealed (again) by the 2010 IT Project Success survey.
• If there was some sort of consensus within the agile community as to the criteria for determining whether a team is agile, I highly suspect that the agileness ratings would increase over time.  What gets measured often improves.
• However, how agile you are isn't anywhere near as important as getting better at what you're doing.  So perhaps I'm barking up the wrong tree on this issue.  ;-) 

One of the scaling factors called out in the Agile Scaling Model (ASM) is “regulatory compliance”.   This name is a bit of a misnomer because this scaling factor really addresses two issues: complying to regulations imposed upon you from external sources and choosing to adhere to internal regulations willingly adopted by your organization.   It is relatively common for agile teams to find themselves in such situations.  For example, in the 2009 Agile Practices Survey one third of respondents said that they were applying agile on projects where one or more industry regulations applied.

First let’s consider external regulatory compliance.  In these situations you may face the need to undergo an audit by an external regulatory body with consequences for non-compliance ranging from anywhere to a warning to a fine or even to legal action.  Sometimes even a warning may be a grave thing.  A few years ago I was working with a pharmaceutical company which had discovered that a warning from the FDA for non-compliance with their CFR 21 Part 11 regulation, when reported in major newspapers, resulted on average in a half-billion dollar loss to their market capitalization as the result of a dip in their stock price.   There are financial regulations such as Sarbanes-Oxley and Basel II, informational regulations such as HIPAA which focuses on health information  privacy, technical regulations such as ISO 27002 for security practices, and even life-critical regulations such as some of the FDA regulations.  

External regulations are typically managed by a government organization or industry watchdog will range in complexity and can have a myriad of effects on project teams.  For example, you may need to be able to prove that you had a documented process and that you followed it appropriately; you may need to produce extra artifacts, or more detailed artifacts, than you normally would; you may need to add extra features to your solution, such as tracking financial information, that you wouldn’t have normally implemented; you may need to produce specific reports to be submitted to the regulatory body; or you may even need to submit your team to audits, sometimes scheduled and sometimes not, to ensure regulatory compliance.  Interestingly, even though many of those requirements go against the agile grain, the 2009 Agility at Scale Survey found that organizations were successfully applying agile techniques while still conforming to external regulations.  So yes, it is possible to scale your agile strategy to address regulatory compliance.

Second, let’s consider compliance to internally adopted, or sometimes even developed, “regulations” which you will be potentially evaluated/appraised against.  Perfect examples of these are process improvement frameworks such as CMMI and ISO 900x.  Similar to external regulations, the 2009 Agility at Scale Survey found that some agile teams are succeeding in situations where they have chosen to adopt such frameworks.  It’s important to note that frameworks such as CMMI aren’t primarily about ensuring the compliance of development teams to a standard process, regardless of what CMMI detractors may claim, but instead about process improvement.  Process improvement at the IT department (or beyond) is an enterprise discipline issue from the point of view of ASM, implying that frameworks such as CMMI affect more than one scaling factor.  

When you find yourself in a regulatory situation, whether those regulations are imposed or willingly adopted, the best advice that I can give is to read the regulations and develop a strategy to conform to them in the most agile manner possible.  If you let bureaucrats interpret the regulations you’ll likely end up with a bureaucratic strategy, but if you instead choose to take a pragmatic approach you will very likely end up with a very practical strategy.  Part of that strategy is to treat the regulatory representative(s) within your organization as important stakeholders whom you interact with regularly throughout the project.

The SEMAT vision has recently been posted online.  SEMAT is short for Software Engineering and Method and Theory (SEMAT) and I am one of several signatories and a provider of input into the effort. 

There are several reasons why I'm involved with SEMAT:

1. The industry clearly needs something like this.  Ivar Jacobson has been writing and speaking for awhile now about how our industry behaves in a similar manner to the fashion industry -- we lurch from one cool idea (the fashion) to another and few of us observe that the current fashion is often just a rehash of fashion(s) from the past.
2. The right people are involved.  The SEMAT initiative has attracted a wide range of industry experts, including both the old guard, the new "agile guard", and people in between.  Arguably we may be short a few people, the data community isn't well represented and I'm not sure we have the systems community covered well, but we can address those challenges in time.
3. We'll achieve something.  We may not pull of the entire vision, but we are going to produce something of value and I hope that it has a positive impact on the industry.  Time will tell.

I have several thoughts about the SEMAT vision which I'd like to share with you:

1. The vision is coherent.  A lot of reasoned effort went into it's development as you can see when you read it.
   
2. It will be a challenge to identify a non-trivial kernel.  Even developing a kernel language will be hard as people will often stick to their preferred terms.  For example, is it an iteration, a sprint, or a time box?
3. Practitioners may not notice.  It will also be a significant challenge to get practitioners interested in the SEMAT effort and more importantly to leverage the material.  For example, the patterns community has a long history of producing great work which for the most part is ignored by the vast majority of practitioners, with the exception of a handful of the hundreds of patterns out there.  So, although SEMAT is likely to produce some great ideas, will anyone care?
4. Academics may not notice.  I suspect that this will be less of a problem than practitioners not noticing, but it's still a possibility. 

Next steps:

1. Position papers from many of the signatories, including myself, will soon be published at the SEMAT site.   Several non-signatories have been invited to submit papers as well.
2. A workshop is being held in the third week of March in Zurich.  At this workshop the people who published position papers will flesh out our ideas.
3. I'll blog about these things as they occur.

The Scrum community has adopted a different set of terms than the other agile methodologies. This is done on purpose to help people realize that Agile approaches are different than traditional approaches, which can help in their adoption, but it can also hinder people's understanding because some of the terminology is not only non-standard it really doesn't make much sense. Because of this I'm often asked by people that I'm coaching to convert back and forth between terms, and recently wrote a detailed article on the subject. The following summarizes the mapping:

• Daily Scrum Meeting ==> Daily Stand-up Meeting
• Product Backlog ==> Work Item List
• Scrum Master ==> Team Lead or Team Coach
• Sprint ==> Iteration or Time Box

For more details read my article Translating Scrum Terminology which includes explanations of a wider range of Scrum terms and discussions of why some of them really are questionable.


Further reading:

• Translating Scrum Terminology
• Implementing Scrum Site
• Scaling Scrum
• Roles on Agile Teams

[Read More]

Recently I visited a customer who had adopted Scrum. They were a few sprints, what Scrum calls iterations, into the project and were running into some difficulties. Although I was primarily brought in to educate senior management on disciplined agile software development, I was also asked to sit in on the team’s daily stand-up meeting so that I could hopefully provide some suggestions as to how to address the problems they were running into.

Their work area was fairly typical. They had some whiteboards which they were using for project planning and tracking, with sticky notes to indicate what work had been taken on by each team member. The current status of the task (not yet started, in progress, and completed) was indicated by putting each sticky note in a corresponding column for the status and corresponding column for the team member. This allowed everyone on the team to easily share their status and to see the status of everyone else. On the sides were sketches of the architecture as well as some business oriented models. In addition to Scrum the team had adopted several practices from Agile Modeling, in this case they had done some initial requirements envisioning and architecture envisioning, as well as practices from Extreme Programming (XP) for construction. In short, they had followed a fairly common strategy of combining practices from various agile methods.

This would have worked perfectly fine if they had tailored the practices to reflect the situation that they were in, but instead they adopted them "straight out of the book". First, the team was distributed, with most of the team in the location that I was visiting but some people located in two other distant cities. Therein was the source of most of their problems. The people at the other two locations weren’t getting much value out of the daily stand-up meetings, even though they would dial in, because they couldn’t see the project status information. Although people at this location were trying their best to represent these distant people in the daily stand-ups it wasn’t working well – their status information wasn’t being kept up to date and for some people it was a bit of mystery as to what they were actually working on at all.

This team also had 30 people in it, which isn’t a big deal although it can stretch the limits of the simple modeling and planning tools (in this case paper and whiteboards) that they were using. Because the team was larger they were investing a fair bit of time creating burn down charts at both the iteration/sprint and project levels. One of the unfortunate implications of using manual tools for project management is that any associated metric/status reporting in turn becomes manual as well. Considering how the agile community is so concerned with working efficiently, I find it comical that we have a tendency to overlook our own potentially unnecessary bureaucracy such as this.

The problem was that the team was applying strategies, in this case using sticky notes and whiteboards to capture the detailed iteration plan, applying similar strategies to capture key models, and were verbally relaying of status information between sub-teams. There are perfectly fine strategies for smaller co-located teams, but not so good for large or distributed teams. The solution was to recognize that they were in an Agility@Scale situation and needed to tailor their approach to reflect this fact. In this case they needed to forgo some of the manual tools and instead use electronic tooling such as Rational Team Concert (RTC) to share information across disparate locations, in particular the work assignment and corresponding status information. RTC also creates common agile reports such as burn-down charts based on the activities of the developers, providing accurate (nearly) real-time information while removing the burden of status reporting. The RTC project dashboard does more than just this, to see an actual example of one visit www.jazz.net to see the dashboard for the RTC development team itself. You can also see their actual work item list too, a more advanced version of Scrum’s product and sprint backlogs.[Read More]

I've been getting a lot of questions lately about applying the acceleration metric in practice. So, here's some answers to frequently asked questions:
1. How do I monetize acceleration? This is fairly straightforward to do. For example, assume your acceleration is 0.007 (0.7%), there are five people on the team, your annual burdened cost per person is $150,000, and you have two week iterations. All these numbers are made up, but you know how to calculate acceleration now and IT management had darn well better know the average burdened cost (salary plus overhead) of their staff. So, per iteration the average burdened cost per person must be $150,000/26 = $5,770. Productivity improvement per iteration for this team must be $5,770 * 5 * .007 = $202. If the acceleration stayed constant at 0.7% the overall productivity improvement for the year would be (1.007)^26 (assuming the team works all 52 weeks of the year) which would be 1.198 or 19.8%. This would be a savings of $148,500 (pretty much the equivalent of one new person). Of course a 20% productivity increase over an entire year is a really aggressive improvement, regardless of some of the claims made by the agile snake oil salesman out there, although at 10-15% increase is a reasonable expectation. What I'd really want to do is calculate the acceleration for the year by comparing the velocity from the beginning of the year to the end of the year (in Western cultures I'd want to avoid comparing iterations near to the holidays). So, if the team velocity the first week of February 2008 was 20 points, now the same team's velocity the first week of February 2009 was 23 points, that's an acceleration of (23-20)/20 = 15% over a one year period, for a savings of $112,500.
2. Is acceleration really unitless? For the sake of comparison it is. The "units" are % change in points per iteration, or % change in points per time period depending on the way that you want to look at it. Because it's a percentage I can easily monetize it, as you see above, and use it as a basis of comparison.
3. How do I convince teams to share their data? This can be difficult. Because acceleration is easy to calculate for agile teams, and because it's easy to use to compare teams (my team has .7% acceleration whereas other teams down the hall from mine have accelerations of .3% and -.2% of teams), people are concerned that this metric will be used against them. OK, to be fair, my team might be OK with this. ;-) Seriously though, this is a valid fear that will only be addressed by an effective governance program based on enablement, collaboration, and trust instead of the traditional command-and-control approach. Management's track record regarding how they've used measurements in the past, and how they've governed in general, have a great effect on people's willingness to trust them with new metrics such as acceleration. The implication is that you need to build up trust, something that could take years if it's possible at all.
4. Why does this work for agile teams? Agile teams are self organizing, and an implication of that is that they will be held accountable for their estimates. Because of this accountability, and because velocity is a vital input into their planning and estimation efforts, agile teams are motivated to calculate their velocity accurately and to track it over time. Because they're eager to get their velocity right, and because acceleration is based on velocity, there's an exceptionally good chance that it's accurate.
5. What about function points or similar productivity measures? Function points can be calculated for projects being developed via an agile approach, or other approaches for that matter, but it's a very expensive endeavor compared to calculating acceleration (which is essentially free) and likely will be seen as a bureaucratic overhead by the development team. My rule of thumb is that if you're not being explicitly paid to count function points (for example the US DoD will often pay contracting companies to create estimates based on function point counts) then I wouldn't bother with them.
6. What about calculating acceleration for iterative project teams? Iterative project teams, perhaps following Rational Unified Process (RUP), can choose to calculate and track their velocity and thereby their acceleration. The key is to allow the team to be self organizing and accountable for their estimates, which in turn motivates them to get their velocity right just like agile teams (RUP can be as agile as you want to make it, don't let anyone tell you differently).
7. What about calculating acceleration for traditional project teams? In theory this should work, in practice it is incredibly unlikely. Traditional teams don't work in iterations where working software is produced on a regular basis, they're typically not self organizing, and therefore there really isn't any motivate to calculate velocity (even if they do, there is little motivation to get it right). Without knowing the velocity you can't calculate acceleration. If you can't trust the velocity estimate, and I certainly wouldn't trust a traditional team's velocity estimate, then you can't trust your acceleration calculation. So, my fall back position to calculate productivity improvement would be to do something like function point counting (which is expensive and difficult to compare between teams due to different fudge factors used by different FP counters) and then looking at change in FPs delivered over time.
8. How can I apply this across a department? It is fairly straightforward to roll up the acceleration of project teams into an overall acceleration measure for a portfolio of teams simply by taking a weighted average based on team size. However, this is only applicable to teams that are in a position to report an accurate acceleration (the agile and iterative teams) and of course are willing to do so.
9. What does a negative acceleration tell me? If the acceleration is negative then productivity on the team is going down, likely an indicator of quality and/or team work problems. However, you don't want to manage by the numbers so you should talk to the team to see what's actually going on.
10. What does a zero acceleration tell me? This is an indication that the team's productivity is not increasing, and that perhaps they should consider doing retrospectives at the end of each iteration and then acting on the results from those retrospectives. Better yet they can "dial up" their process improvement efforts by adopting something along the lines of IBM Rational Self Check.
Further reading:

• Acceleration: An Agile Productivity Measure
• Lean Development Governance
• Agile and Rational Unified Process (RUP)
• Introducing IBM Rational Self Check for Software Teams
  
  

[Read More]

A common question that I keep running into with customers is whether you can take an agile approach to service oriented architecture (SOA). The quick answer is yes, because Agile is orthogonal to the implementation technologies used. You can take an agile approach developing COBOL applications running on mainframes, fat-client Java applications, multi-tier J2EE applications, and yes, even services. Granted, it's easier to do with some technologies than others, either because of the nature of the technology or because of the supporting tools.

The long answer is "yes, but". You don't adopt an SOA approach for the sheer joy of doing so, instead you very likely want to improve the level of reuse within your organization. To succeed at SOA-driven reuse you need an enterprise focus, something that doesn't appear to be very common on many agile teams. Therein lies the challenge. Several strategies for improving your chances with Agile SOA, and SOA in general, follows:1. Invest in some initial enterprise architecture modeling. You don't need to identify all of the details up front, that would take too long and actually put the effort at risk, but you do need to set a starting point to guide development teams. Identifying the technical architecture is critical, and identifying a few basic services which would provide immediate business value to one or more teams is critical. Involve people from several application project teams to ensure that you get a wide range of input. See http://www.agiledata.org/essays/enterpriseArchitecture.html for a streamlined approach to enterprise architecture modeling. Creating big, detailed models often proves to be a waste of time because development teams are rarely motivated to read mounds of documentation.2. Build out the initial infrastructure on a real application development project. This proves that your SOA strategy actually works and puts the technical foundation in place for future teams. During this period you'll be tempted to try to support several development teams, which is feasible but dramatically increases your risk. It's also tempting to focus simply on getting the infrastructure in place without delivering any business functionality, but this risks producing an ivory-tower architecture that nobody is interested in.3. Spread the service architects out onto application development teams. The people that formulated and then proved your SOA should be actively involved on the development teams that are working with it to ensure that the teams use it appropriately and to ensure that the architects get concrete feedback which they can use to evolve the architecture. When working on agile teams, these people will need to work in a collaborative and evolutionary approach just like other team members.4. Fund reuse separately. I've lost track of the number of organizations that I've run into that fail at reuse because their development teams never have the resources to develop reusable assets. That's simply the nature of the beast -- project teams will always be more interested in addressing their own specific requirements than they are in investing the time and effort to make something reusable. The real problem here is that you expect them to act differently. A better strategy is to have a separate reuse engineering team that has the resources to monitor existing projects to look for potentially reusable assets. When they find said assets this team does the work to harvest the asset, to reengineer it to make it reusable, and then to integrate back into the original source project. The goal is to make it as painless as possible to produce reusable assets such as services. If you expect project teams to do this work out of the goodness of their hearts then you're effectively punishing them when they do the right thing. That's not a very good governance strategy, IMHO.5. The reuse team now owns the asset. Any reusable asset, including services, will need to be maintained, evolved over time, and supported. This isn't free nor is it viable for project teams to do so.

If you're interested, I provide agile strategies for both enterprise architecture and strategic reuse in the book "Enterprise Unified Process". Although written under the assumption that you're taking a RUP-based approach to development, the reality is that the EUP can extend any evolutionary/agile software development process so that it addresses the larger-scale needs of modern IT organizations.

- Scott[Read More]