Question

Describe how the Rational User Process can accommodate agile process. Specify in what phases and what disciplines agile methods could be appropriate.

Answer 1

Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner. The practices of AM should be used, ideally in whole, to enhance other, more complete software process such as eXtreme Programming (XP), the Rational Unified Process (RUP), Disciplined Agile Delivery (DAD), and the Enterprise Unified Process (EUP) to name a few. These processes cover a wider scope than AM, in the first three cases the development process and in the fourth the full software process including both development and production. Although these processes all include modeling and documentation activities, in one form or the other, there is definitely room for improvement. With DAD the practices of AM are built right into the framework, with XP the modeling processes should be better defined, and with RUP modeling processes could definitely stand to be made more agile.

In this article I explore in detail how AM can be used in conjunction with the various instantiations of the Unified Process (UP), including but not limited to the RUP and the EUP. To do so, I discuss

• How modeling works in the Unified Process
• How good is the fit between AM and RUP?
• Case study
• Adopting AM on an UP project
• How does this work?
• References and Suggested Reading

How Modeling Works in the Unified Process

All efforts, including modeling, is organized into disciplines (formerly called workflows) in the UP and is performed in an iterative and incremental manner. The lifecycles of the AUP and EUP are presented in Figure 1 and Figure 2 respectively. The AUP is a subset of the RUP and the EUP a superset of the it. I like to say that the UP is serial in the large and iterative in the small. The six phases of the EUP clearly occur in a serial manner over time, at the beginning of an UP project your focus is on project initiation activities during the Inception phase, once your initial scope is understood your major focus becomes requirements analysis and architecture evolution during the Elaboration phase, then your focus shifts to building your system during the Construction phase, then you deliver your software during the Transition phase, you operate and support your software in the Production phase, and finally you remove it from production during the Retirement phase. However, on a day-to-day basis you are working in an iterative manner, perhaps doing some modeling, some implementation, some testing, and some management activities.

In the RUP there are three disciplines[2] that encompass modeling activities for a single project - Business Modeling, Requirements, and Analysis & Design - and the EUP adds Enterprise Business Modeling and Enterprise Architecture. The AUP on the other hand, being a subset of the RUP, combines the three modeling disciplines into a single Model discipline. All six disciplines are described in Table 1. For a description of potential artifacts to create during these disciplines visit Agile Models Distilled.
Figure 1. The lifecycle of the Agile Unified Process (AUP).

Figure 2. The lifecycle for the Enterprise Unified Process (EUP).

Table 1. The Modeling Disciplines of the Unified Process.

Discipline	Purpose
Business Modeling	The purpose of this discipline is to model the business context, the scope, of your system. Common modeling activities include the development of: A context model (often a data flow diagram) showing how your system fits into its overall environment A high-level business requirements model (often an essential use case model) A glossary defining critical business terms A domain model (often a class diagram or data diagram) depicting major business classes or entities A business process model (often a data flow diagram or activity diagram) depicting a high-level overview of the business process to be supported by your system. This diagram is one level of detail greater than your context diagram
Requirements	The purpose of this discipline is to engineer the requirements for your project, including the identification, modeling, and documentation of those requirements. The main deliverable of this discipline is the Software Requirements Specification (SRS), also referred to as the Requirements Model, which encompasses the captured requirements.
Analysis & Design	The purpose of this discipline is to evolve a robust architecture for your system based on your requirements, to transform the requirements into a design, and to ensure that implementation environment issues are reflected in your design.
Model	In the AUP this is the combination of the Business Modeling, Requirements, and Analysis & Design discipline.
Enterprise Business Modeling	The Enterprise Business Modeling discipline extends business modeling to enable your organization to explicitly realize the benefits of doing so outside the context of a project. The goal of the Enterprise Business Modeling discipline, also sometimes referred to as enterprise requirements modeling, is to enable you to understand and effectively communicate the business that your organization is engaged in. It explores both the business process that your organization engages in as well as the overarching business requirements for the software applications that support it.
Enterprise Architecture	The Enterprise Architecture discipline defines the enterprise architecture of an organization. It consists of models that define it, reference architectures, prototypes and working models that demonstrate how it works, and frameworks that make it easier to use. An enterprise architecture model is a representation of the structures and processes of an organization; a good one depicts the organization both as it is today and as it is envisioned in the future, and maps the various views representing the architecture to one another. These views include both business-oriented perspectives as well as technical perspectives. In many ways enterprise architecture models are a communication bridge between senior business stakeholders and senior IT professionals.

How Good is the Fit Between AM and UP?

Now that we understand the basics of how modeling in the UP works, we can examine how well AM fits in with it.Luckily many of AM's principles and practices are arguably a part of the UP already, although perhaps not as explicitly as I would like. Table 2 presents an examination of how well each individual AM practice is currently implemented in the UP, if at all, and discusses how to adopt the practice within the scope of the UP. My experience is that it is relatively straightforward for UP teams to adopt AM practices if they choose to do so. This is because the UP is very flexible, one of its underlying principles is that you should tailor it to meet your unique needs, making it easy to merge AM practices into the UP.

Table 2. The Fit Between UP and AM.

Practice	Fit
Active Stakeholder Participation	AM has a wide definition for project stakeholders, including users, management, operations staff, and support staff to name a few that are compatible with the UP. The UP clearly includes project stakeholders, such as users and customers, throughout most of it disciplines. To be successful UP project teams should allow project stakeholders to take on modeling roles such as Business Process Designer and Requirements Specifier as appropriate, there is nothing in the RUP preventing this by the way. The more active project stakeholders are the less of a need there will be for reviews, management presentations, and other overhead activities that reduce your team's development velocity.
Apply Modeling Standards	The application of modeling standards, in particular the diagrams of the Unified Modeling Language (UML), is a significant part of the UP. Furthermore the RUP product includes guidelines for the creation of many modeling artifacts, guidelines that your teams should consider adopting and following as appropriate, and explicitly suggests that you tailor the guidelines that they provide for your exact needs. To remain agile, however, UP teams should recognize that you often need to bend the guidelines and standards - in other words, don't let them become a straight jacket. There are detailed UML modeling guidelines posted at this site.
Apply Patterns Gently	UP teams are free to apply modeling patterns, the RUP product describes many common modeling patterns, as part of their efforts for any of the modeling disciplines. This practice enhances the UP with its advice to ease into the application of a pattern, the UP does not make this concept as explicit as it could.
Apply the Right Artifact(s)	One of the strengths of the UP is that provides some advice for when to create each type of model, and recent incarnations of the RUP product includes significant advice for non-UML artifacts such as data models and user interface storyboards (UI flow diagrams).
Collective Ownership	AM's concept of collective ownership can be used to enhance the efforts on UP projects, assuming that the team culture supports the concept of open and honest communication. The UP supports collective ownership with its strong focus on configuration management issues, it has a discipline dedicated to this task, although its change management processes may potentially get in your way if developers and project stakeholders are unable to distinguish when to formalize change control and when not to. To be fair, this is a problem regardless of when you apply AM on an UP project, or on any type of project for that matter. UP teams should turn the configuration management dial up a few notches and allow anyone on the project to access and work on any artifact that they wish, including models and documents.
Create Several Models in Parallel	The UP clearly includes this concept, one only has to look at the activity diagrams depicting each discipline to see that several artifacts are potentially being worked on in parallel. However, this concept could be communicated better because the near-serial flow in its activity diagrams presented for each major modeling activity doesn't communicate this concept well. There is a larger issue as well when you consider the lifecycle as a whole. Because the UP has organized its modeling efforts into separate disciplines, for very good reasons, it isn't as apparent that not only could you work on several business modeling artifacts in parallel but you could also work on requirements-oriented artifacts, analysis-oriented artifacts, architecture artifacts, and design artifacts too. UP teams can turn the dial up a few notches by reading between the lines of the discipline activity diagrams and the UP lifecycle diagram and choosing to perform activities from several disciplines simultaneously when it makes sense to do so.
Create Simple Content	This practice is a choice made by the modeler(s), albeit one that must be implicitly supported by the rest of the development team. UP teams will need to adopt modeling guidelines that allow models that are just good enough and the customers of those models (including programmers, project stakeholders, and reviewers) must also be willing to accept simple models. This is a cultural issue, one that is often difficult for many organizations to adopt.
Depict Models Simply	See Create Simple Content.
Discard Temporary Models	Modelers on UP teams are free to discard anything that they wish. As with the simplicity practices your organization's culture must accept the concept of traveling light, of developing and maintaining just enough models and documents and no more.
Display Models Publicly	UP teams are free to follow this practice. UP teams can turn the communication dial up a notch by following the principle of Open and Honest Communication by making all artifacts available to everyone as well as to publicly display the critical models used by the project team.
Formalize Contract Models	The UP includes the concept of integrating with external systems, these systems are typically identified on use case models and the RUP suggests introducing "boundary classes" to implement the interface to these systems. At the time of this writing the RUP appears weak with respect to activities such as legacy system analysis and enterprise application integration (EAI). The explicit adoption of this practice clearly strengthens the UP's integration activities and fits in well with it's concepts of use case realizations - the interaction between systems could be specified with one or more use cases and then the corresponding use case realization would be the formalized contract model.
Iterate to Another Artifact	This practice can be easily adopted by an UP team. As mentioned previously, the unfortunate depiction of UP modeling activities as quasi-serial processes and the division of modeling activities into separate disciplines can hinder the iterative mindset required of agile modelers.
Model in Small Increments	This practice is clearly an aspect of the UP - the UP's support for iterations implies that you will be incrementally developing your model throughout your project. UP teams can easily turn the iterative and incremental dial up a few notches by preferring smaller, simpler models that quickly lead to implementation and testing.
Model With Others	The UP implicitly includes this practice. Every modeling discipline clearly includes several roles, each role being filled by one or more people. UP teams can turn the communication dial up a few notches by adopting tools that support team modeling, such as whiteboards and collaborative modeling tools (see the Communication article) over single-user modeling tools.
Prove it With Code	The UP explicitly includes this practice. At the end of every iteration, except perhaps for the ones during the Inception phase, the UP specifically states that you should have a working prototype. Furthermore, the UP insists that you have a working end-to-end prototype at the end of the Elaboration phase that proves your architecture.
Reuse Existing Resources	Reuse is an implicit part of the UP, and reuse management is an explicit part of the Enterprise Unified Process (EUP). UP teams can turn the reuse dial up a few notches by actively preferring to reuse existing resources instead of building them from scratch, including but not limited to existing models, existing components, open source software (OSS), and existing tools.
Single Source Information	There is no reason why you cannot store information in a single place when following the UP. Unfortunately, many organizations choose to instantiate the RUP in a documentation-driven manner (which IBM Rational clearly advices you not to do), and as a result they travel very heavy and clearly take a multi-source approach.
Update Only When it Hurts	In theory this can be an easy concept for UP teams to adopt as it dramatically reduces the effort expended to keep your artifacts up to date. However, in practice many organizations prove to have a problem with this concept, particularly if they have a strong "traceability" culture. Traceability is the ability to relate aspects of project artifacts to one another, the support for which is a strong feature of the UP as it is an important aspect of its Configuration and Change Management discipline. Furthermore, the RUP product includes tool mentors for working with Rational RequisitePro, a requirements traceability tool, making it appear easy to maintain a traceability matrix between artifacts. My experience is that organizations with traceability cultures will often choose to update artifacts regularly, even if it isn't yet painful to have the artifacts out of date, and update the traceability matrix relating everything to one another. To turn their productivity dial up several notches UP teams should choose to travel light, to loosen up a bit and allow project artifacts to get out of sync with one another, and to maintain a traceability matrix between artifacts only when there is clear benefit to do so AND their project stakeholders understand the issues involved as well as authorize the effort. A traceability matrix is effectively a document and is therefore a business decision to be made by project stakeholders.
Use the Simplest Tools	The RUP product includes tool mentors that make it easier for teams to work with tools sold by Rational Corporation. However, the reality is that UP teams are welcome to use any development tool that they want and Rational tools compete on their merits just like the products of any other company. UP teams can turn their productivity dial up several notches by expanding their horizons to include simple tools such as whiteboards, index cards, and Post-It notes in addition to CASE tools.

Something that is important to understand is that for AM to be successful the culture of your organization must be open to the concepts, values, and principles of agile software development.The problem is that the UP is often adopted by organizations that either implicitly or explicitly do not accept the values of agile software development. Their focus is often on following processes and using tools, the RUP product clearly defines many processes and describes how to apply Rational's tools effectively on software projects, and therefore the RUP is clearly attractive to them. Unfortunately this goes against the agile value of preferring individuals and interactions over processes and tools. When the culture of an organization is documentation centric they may find the UP appealing because you can instantiate it in such a way as to result in the creation of significant amounts of documentation (you can also instantiate it to result in very little documentation, remember, the UP is flexible). If an organization is documentation centric then this aspect of its culture goes against agile software development's value of preferring working software over comprehensive documentation. This organization may still successfully adopt, tailor, and instantiate the UP but be unable to follow many of AM's principles and practices effectively because it does not have an agile culture (see the article When Does(n't) AM Make Sense). My point is that how well AM and UP will fit together in your organization depends largely on your organization's culture and not so much on the UP itself. You can easily use the techniques of AM to improve your UP modeling efforts, but to be effective you will find that you need to overcome cultural challenges within your organization.

Case Study: Wayne Enterprises

In early 2001 I was involved with a development project at Wayne Enterprises, the name has been changed to protect the innocent, a medium-sized financial institution. They had adopted the RUP and wanted to tailor it with Enterprise Management concepts from the EUP, in particular they wanted to ensure that the Inception phase and Elaboration phase efforts of individual projects were supported by enterprise-level requirements, architecture, and reuse efforts. They also wanted to ensure that their modeling processes were effective, they weren't convinced that the UML was sufficient for their needs (it wasn't) and they wanted to ensure that legacy integration modeling was reflected in their tailoring of the RUP. I was eager to apply AM on a RUP project and they liked the basic concept of the methodology and were willing to give it a try.

The culture of Wayne Enterprises was conducive to change, which was a huge benefit. Management was open minded and willing to try new techniques, hence the RUP. As you would expect the developers were also eager to try new techniques and work with new technologies, although nowhere near as enamored with the RUP as management was.Our approach was to pilot the RUP on a small project - there was seven developers, one manager, one senior manager and four users - over a period of seven months. The project was of mid-level importance, it would be noticeable if we failed but it wouldn't put the company at risk. It was their first real J2EE project, and the team was fairly typical: there was two mid-level Java developers; a senior consultant experienced in EJB; another senior developer with a C++, OMT, and UML background; a experienced business analyst that was new to use cases and object-oriented development; a DB2 database administrator (DBA) learning Oracle; and a good QA/tester person with some Java testing background.

At the beginning of the project we tailored the RUP with the practices of AM and a portion of the EUP, the end result of which was the creation of something the RUP calls a development case. This effort took several days, I had all the raw material that we needed to add, and everyone recognized that there was little value in spending much more time than that - everybody wanted to get to work on the project.My involvement with the project was to help them with the initial creation of the development case and initial overview training to the development team. I also periodically reviewed the effort, both from an architectural point of view and from a software process point of view - their first goal was to develop a good system and their second goal was to ensure that they were learning how to do so effectively.

During the Inception phase the team produced a high-level requirements model, about 20 use cases and a 15-page supplementary specification that the business analyst evolved throughout the project. A lot of this documentation was initially written by the user representatives, after breaking out of requirements modeling sessions led by the business analyst and attended by one or two developers at a time. The Elaboration phase was mostly white boarding performed by the entire team and some coding and testing of an end-to-end prototype to prove the architecture. They kept the models as simple as they possibly could, some of this was motivated by the realization that they weren't familiar with the technology and therefore it was futile to over model things, and part of it was because they were eager to code EJBs, servlets, and JSPs. This phase went a little slower than usual due to the team's inexperience with setting up EJB, developing EJBs, and deploying them. The Elaboration phase was a good learning experience for the team because it gave them experience in the technology and in following their tailored process. It also helped to dampen the DBA's argument that the data architecture was the primary concern, granted, the legacy data issues were challenging, and was an important stepping stone towards building a common understanding of how to work together as a team. During the Construction phase the use of Together/J and the data modeling tool was very common, although white boarding was still used for high-level thinking and discussions. From what I could gather the architecture models stayed up on the white boards, the critical ones were a layered deployment diagram and a high-level sketch of the structure of the object schema. The DBA maintained and evolved the data model, outputting it regularly to their plotter and tacking to the wall. The organization already made it a practice to Display Models Publicly long before they adopted RUP and AM. The team had five four-week iterations in the Construction phase, implementing between two and five use cases at a time. The Transition phase was fairly standard, from an AM point of view the most important effort was a documentation clean up at the end.

As the project progressed the team ran into several issues:

1. Personnel. The Java/EJB developers took to the process pretty quickly, much of the object-oriented development practices were familiar to them already and they preferred an iterative and incremental approach to development. The C++ developer had a "big design up front" (BDUF) mindset that he started to overcome mid-project after seeing that our emergent design approach actually worked in practice (see the Agile Design Modeling article a discussion of these two approaches to design). The DBA had a similar mindset although he wanted to create a data model early in the project, which was clearly inappropriate because we wanted to let our object design drive our database design so we diverted him to focus on legacy analysis and the formalization of contract models with the relevant groups. The business analyst struggled with learning how to apply use cases effectively in combination with other requirements artifacts. The tester was initially concerned that we weren't producing detailed models that could be inspected and peer reviewed, but he recognized the closer collaboration among the team and the combination of Agile Testing and Quality Strategies was sufficient for our needs.
2. Management. The team had good senior management support throughout the effort as it was clear to them that the team was delivering. The team's senior manager focused on technical issues such as scheduling and estimating and the junior manager focused on softer issues such as ensuring the team had the resources they needed, including training, and that they weren't being delayed by politics.
3. Tools. The team could have been more agile when it came to tool usage. The practice of Use the Simplest Tools wasn't fully accepted, whiteboards made sense to the team but index cards and essential user interface prototypes using Post It Notes and flip chart paper were too foreign for them. Initial diagrams were drawn on the whiteboard and in the case of structural diagrams such as UML class diagrams and data diagrams they were then transcribed into the appropriate CASE tool, Together/J and Oracle Developer respectively. The use case diagram was transcribed into Microsoft Visio, they needed to present it to senior management and my suggestion that we simply provide them with a digital picture of the whiteboard didn't go over well. The diagram also appeared in the final documentation so the effort was worthwhile.
4. Cultural. The hardest thing to overcome was the serial/waterfall mindset of some of the people involved. The C++ developer, who was learning EJB, and DBA both had a BDUF mindset and the tester wanted to see more formal documentation. The data-driven mentality of the DBA was typical but eventually overcome when he saw that an object-driven approach actually worked in practice - this was clearly a struggle for him at first and I suspect that he was initially giving the team enough rope to hang themselves with, but slowly saw that there are in fact more effective ways to work than what he was familiar with. The managers were open to iterative and incremental development, I suspect that not only did they purchase Kruchten's RUP book (2000) they actually read it, and had communicated the advantages of this approach to the user representatives we were working with. One of our user representatives had been involved with a "challenged project" in the past and definitely didn't want to repeat that experience and as a result was incredibly open to following the RUP.
5. Documentation. In my opinion the team wrote too much documentation, but at the same time it increased their comfort level with the new approach so that wasn't too bad. They stuck to the traditional RUP artifacts. Their requirements model was focused around the use case diagram and a collection of use cases, business rules, technical requirements, and glossary written in English prose. The business analyst wrote and maintained this document, keeping it up to date as the requirements evolved. The Software Architecture Document (SAD) was maintained as point form notes on an HTML page, whiteboard sketches, and arguably in the CASE tool models. The notes, basically an overview of the team's decisions, and the whiteboard diagrams were quite agile. However, the team complained that there was nothing in between the high-level sketches and the detailed diagrams in their CASE tools - both Together/J and the data modeling tool are oriented towards detailed design and development, not high-level architecture. In the end they discovered that they didn't need the intermediate-level models, but this was a point of contention for awhile. The data model appeared to be of value to the team and was considered a permanent artifact, although the diagrams in Together/J weren't perceived to be as important - Together/J writes most information to Java class files, which were clearly considered critical to success. The Test Model, the definition of the test cases, was maintained by the tester, and although I never looked at it from what I could tell the tester invested too much effort in its development. To be fair, the tester was new to J2EE development and wanted to err on the side of caution.

Adopting AM on an UP Project

For an UP project team to adopt AM they will need to overcome the common misconceptions that developers have about the UP as well as several cultural barriers that are common within organizations that instantiate the UP. they need to begin by thinking outside of the current UML-centric nature of the UP. To do this, you should:

1. Forget the term "use-case driven". Yes, it's a wonderful marketing term but the reality is that use cases aren't sufficient to drive much of anything. Use cases are a good technique to document behavioral requirements but that's only a small part of the functional requirements picture and an even smaller part of the total requirements picture - they aren't very good at documenting business rules, user interface requirements, constraints, or non-functional requirements - which is why the UP includes something called a supplementary specification to contain all these other things. Requirements drive things, use cases don't. Your modeling efforts will always remain hobbled if you don't separate the UP's software engineering wheat from its marketing-rhetoric chaff.
2. Recognize that there are more modeling artifacts than those described by the UML. AM's principle Multiple Models tells you that you have many modeling artifacts at your disposal - change cases, user stories, business rules, UML activity diagrams, UML class diagrams, data models, and external interface specifications - to name a few. An interesting implication of this principle is that you have far more than just the diagrams of the UML at your disposal. The good news is that the UP recognizes that a wide range of models is needed to explore the complexities of modern software, recent versions do in fact include data modeling and user interface design activities that are currently outside the scope of the UML, the bad news is that it many people erroneously perceive that the UP is simply a process for using the UML.
3. Recognize that the UP is not inherently documentation centric. The UP is actually very clear that you should only develop the artifacts that you actually need, however, this is good message is something that often gets missed by many software professionals so it is something that is worth repeating here. You should question every single model that the UP suggests creating because it purposely describes a wide variety of artifacts, many of which your project simply doesn't need. The UP includes three major sets of modeling-oriented artifacts - the business modeling set, the requirements set, and the analysis & design set - each of which in turn is composed of several detailed artifacts. For example the business modeling set includes a business use-case model, business rules, a business architecture document, and a business supplementary specification. Do you actually need all of these things? Likely not. If you do need them, do you need them as formal documentation? Likely not. Communicate AM's Travel Light and Model With a Purpose principles to your project stakeholders, as well as the practices Update Only When It Hurts and Discard Temporary Models.
4. Build a common process vision between developers and project stakeholders. Managers often tend towards a prescriptive software process, something that appears well defined and comprehensive such as the UP, one with a perceived focus on control. Developers, on the other hand, gravitate towards agile techniques such as XP and AM due to their perceived focus on what is important to developers: building software. Because management holds the purse strings many developers find themselves in a situation where their managers have chosen to adopt the UP and are now being required to follow it. Luckily the UP is flexible enough that it can be tailored to be reasonably agile, but to do so developers and project stakeholders will need to come to an agreement as to the extent of the tailoring.
5. Actively promote iterative and incremental development. Agile Modeling's practices of Model in Small Increments, Iterate to Another Artifact and Create Several Models in Parallel can be tough ones for experienced modelers to adopt - and chances are that your experienced modelers are already chaffing at the UP's concepts of iterations, let alone an even greater emphasis on iterative and incremental modeling. Traditional modeling techniques often promoted a single artifact approach, such as use-case modeling or user-interface prototyping sessions, and often even modelers that focused, for example data modelers. Also, they often promoted a BDUF approach where you modeled everything in detail before you started coding. These concepts were great in theory, focusing on a single artifact at a time should have allowed the modelers to get it right quickly, but unfortunately practice shows this not to be the case. A good way to ease into these practices is instead of use-case modeling sessions run requirements modeling sessions where you work on use cases, Class Responsibility Collaborator (CRC) cards, business rules, and user interface prototypes simultaneously. Similarly, hold analysis sessions where you are use case modeling, sequence diagramming, user interface prototyping, and class modeling may make sense, and design sessions where you are class modeling, state modeling, data modeling, component modeling, user interface prototyping, and hopefully even developing business code. Once you are comfortable with these practices the next step is to then merge your modeling efforts in with your implementation efforts, applying multiple artifacts including all your potential models, source code, and test cases as needed - truly iterative development. While you are doing this, keep their focus on the requirements that you are implementing in the current iteration, resulting in an incremental delivery of functionality each iteration.
6. Actively promote simplicity. Simplicity is a fundamental value of AM, one that motivates several critical principles that can dramatically improve the effectiveness of your modeling efforts.Many experienced modelers want to specify everything they possibly can, for example, not only do they wish to model the overall structure of their software in UML class diagrams they also want to specify the scaffolding code needed to implement that structure.This is a lot of effort which provides very little actual value. A better approach is to create a class diagram that is just barely good enough for your purpose, to depict the likely structure of your classes, and then start coding from there. Agile modelers assume that the programmers, often themselves, can figure out the details at the time and instead will focus on issues that may not be so obvious. This approach implies less work for the modeler and less modeling noise for the actual programmer to wade through. When an agile modeler is creating a class diagram they realize that they don't need to model all of the classes required to build the software, instead they focus on getting the core classes right and assume that the programmers are competent enough to handle the rest[1]. By keeping your models simple you are likely to work faster while at the same time create something that is actually of value to your programmers - models that focus on critical issues that are devoid of fluff.
7. Staff projects with generalizing specialists. Many organizations have separate positions for modelers, motivating their staff to focus on specialties, a practice that in my experience reduces your ability to be agile.Although the UP is very clear that individual developers can and should take multiple roles on a project my experience is that this is advice that falls on deaf ears within many organizations.Instead what happens is that organizations adopting the UP tend to introduce positions along the lines of UP's modeling roles - for example Requirements Specifier, System Analyst, User-Interface Designer, Database Designer - and therefore slots people into individual roles, going against the advice of both AM and the UP. If your only job on a software project is to produce models then there is a tendency for you to over model things, first because you naturally want to do a good job and second because if it's your job to model then that means it's likely someone else's job not to model (e.g. their job is to program). Because there is a hand-off there is now greater motivation to add greater detail into your model, details that likely wouldn't be needed if the people writing the code also developed the models that helped them to identify what needed to be coded in the first place.
8. Live AM's principle of Open and Honest Communication. I've run into several situations where a development team was reluctant to follow the Display Models Publicly practice, one way to promote open and honest communication with people external to your team, often because they were afraid of what another political faction within the organization would do with the information. However, when they finally worked up the courage to display their models publicly they quickly discovered that the politicos they were so afraid of couldn't find much to criticize, and when they did this was great input that the developers quickly acted on and benefited from.