Agile Modeling: Where Do I Start?

The first thing to do is read An Introduction to Agile Modeling to gain an understanding of the basic concepts. Regardless of your role, you should actively strive to keep your approach to modeling as collaborative and simple as possible. Recognize that you only need to create models which are just good enough for your task at hand — models don’t need to be perfect (they never are) nor do they need to be complete, they just need to fulfill the needs of their audience right now. Model with others whenever possible, in particular the audience for your model, to ensure that you understand their needs. Of course, you should read and try to adopt as many of the principles and practices of AM as you can and should try to ease into AM gradually.My specific advice for the major roles on software development initiatives follows:

I’m an Architect…

To understand how architecture changes within an agile environment:

High-level, initial architecture envisioning should be done at the beginning of an initiative. The goal is to identify a potential architectural solution, not to document the details, typically using simple techniques such as free-form diagrams on plain-old whiteboards (POWs). This effort typically takes several hours or days.
All architectures work on POWs, therefore you need to prove it with code.
The details are modeled on a just-in-time basis in model storming sessions, and then coded immediately afterwards.
Your architecture will evolve over time as you learn more about what your stakeholders need built.
Because systems are complex, effective architects understand how to apply a wide range of modeling techniques.
Architects should be active participants on the team, and ideally should also code.
Read Agile Architecture Modeling for more details.
The best architects are generalizing specialists who have one or more specialties (e.g. architecture), a broad understanding of IT, and a good understanding of the domain which they work in.

I’m a Data Professional…

The Agile Data site focuses on exactly this topic.

I’m a Designer…

To understand how design changes within an agile environment:

Over the first couple of days a high-level, initial architecture model is created using simple techniques such as free-form diagrams on plain-old whiteboards (POWs).
Recognize that the concept of a “design phase” has been abandoned for the concept that you need to model throughout the initiative. Instead, your design emerges over time to reflect the fact that requirements change over time.
Because systems are complex, effective designers understand how to apply a wide range of modeling techniques.
The details are modeled on a just-in-time basis in model storming sessions, and then coded immediately afterwards.
The quality of your application design is kept high via refactoring, a programming technique.
The quality of your database design is kept high via database refactoring.
The best designers are generalizing specialists who have one or more specialties (e.g. design), a broad understanding of IT, and a good understanding of the domain which they work in.

I’m an Enterprise Architect…

To understand how enterprise architecture changes within an agile environment:

Your goal should be to promote consistent, proven architectural practices and strategies amongst development teams.
Start by developing a vision, then get involved with development teams and work with them as part of the team to help them work to that vision. Over time you’ll develop architectural documentation, but don’t invest much time at first because the teams need vision and help from you, not mounds of documentation.
The most important thing your enterprise architecture group can provide to teams is actual help to follow the enterprise vision. The next most important things are working examples ( reference architectures) and practical guidance (standards and guidelines) for building systems.
Your enterprise architecture will evolve over time as you work with the teams, because you’ll learn what works in practice and what the developers actually need.
The best enterprise architects are generalizing specialists who have one or more specialties, a broad understanding of IT, and a good understanding of the domain in which they work.

I’m a Programmer…

To understand the relationship between AM and programming:

The primary advantage of modeling is that it provides one way for you to think before you build something. You can draw a sketch on a whiteboard or in a modeling tool to think something through and the once you have a viable strategy then you can prove your model with code.
Whenever you run into a requirement you don’t understand, perhaps you have a new user story to implement or the requirement simply isn’t clear, then you can model storm with your stakeholder(s) on a just-in-time (JIT) manner to get the details that you need.
Whenever you run into a technical issue, perhaps you’re not sure which strategy to implement something is best suited for your current architecture, or perhaps you simply need to think through the high-level design before you get into coding, then you should model storm with a co-worker(s) (often your pair if you’re pair programming) to think it through first.
You don’t need a big design document written up before you write your code, and you don’t even need a lot of details, you just need to create models which are just barely good enough for your situation.
I highly suggest that you take a test-driven development (TDD) approach, as I indicate in the AMDD article, and pair program whenever possible.

I’m a Project Manager…

To understand the relationship between AM and project management:

You will likely need to schedule initial envisioning sessions at the beginning of the project.
Organize your project into short iterations. The functionality that you implement in each iteration should be the highest priority functionality, as defined by your stakeholders, at the time. The requirements stack changes throughout the project, so don’t invest much time planning ahead because you’ll only need to do a lot of updating.
The best people to estimate something are the people building it, and they might need to do a little bit of modeling to understand the feature that they’re estimating.
Modeling isn’t a task that you schedule, it’s an activity that people do on a just-in-time (JIT) basis throughout the project.
You’ll discover that model reviews (requirement, architecture, …) really don’t provide a lot of value on agile teams, so expect to discover that you don’t need them after awhile (if at all).

I’m a QA/Test Professional…

To understand the relationship between AM and validation activities:

Agile models evolve over time and they are just good enough for the task at hand. The implication is that it’s unlikely that you’ll have a “complete” model to review, except at the end of the project.
Because Agile Modelers work incrementally and prove it with code whenever they can you’ll have working software to validate very quickly, so reviewing models really does become busy work. Everything works on a whiteboard, or in a CASE tool, but not always in code. Focus on the code.

I’m a Requirements Analyst…

To understand how requirements analysis changes within an agile environment:

High-level, initial requirements envisioning should be done at the beginning of an initiative. This effort takes days, not weeks or months. Your goal is to understand the scope, not to get the details.
Ideally the details are modeled, analyzed if you will, on a just-in-time basis in model storming sessions.
Recognize that the concept of a “requirements phase” has been abandoned for the concept that you need to do requirements analysis throughout the initiative.
Requirements will change over time, and that’s perfectly ok. Manage them as a prioritized, evolving stack.
Stakeholders actively participate in the modeling effort, so adopt inclusive modeling techniques which enable them to do so.
Because systems are complex, effective requirements analysts understand how to apply a wide range of modeling techniques.
The goal is to understand the requirements, not to write requirements documentation. If you do write documentation, keep it concise and useful for your audience and strive to single source information as much as possible.
Recognize that you have a wide range of models at your disposal.
Model with developers so that they understand what the requirements are and you understand what they’re trying to build.\
The best requirements analysts are generalizing specialists who have one or more specialties (e.g. requirements elicitation), a broad understanding of IT, and a good understanding of the domain which they work in.

I’m a Senior Manager…

To be honest, you’re likely hard to convince that AM is a good idea, and you’re likely right to be skeptical – just be open minded as well. Here’s a few important concepts that you need to understand:

Modeling and documentation are important aspects of agile software development. The main difference between agile and traditional approaches are that we strive to maximize stakeholder ROI and therefore we focus on remaining as lean and effective as possible.
Your primary goal should be to develop working software, modeling and documentation should be secondary to that.
There is no co-relation between documentation and success, and in fact lots of arguably unnecessary documentation seems to be associated with failure. Ever had a well defined requirements document in place, but the developers built something else? Or an architecture model in place, but the programmers ignored it? What you really want to strive for is sufficient documentation that is just barely good enough for your situation.
Creating a large, well-defined requirements document which is reviewed and accepted early in the lifecycle is a very risky and ineffective way to work. Requirements change for very good reasons, so you should adopt techniques which enable you to embrace change. Agilists manage requirements as a prioritized stack, each iteration they pull the highest priority requirements (as defined by their stakeholders) off the top of the stack and work on them. The end result is that stakeholders have complete control over what gets developed and how much money gets spent on it (they simply stop funding the initiative once they’re happy with what’s been produced to date). In short, with agile you get to see regular progress in the form of working software, and you get the highest value possible for your investment.
You do need some documentation, just nowhere near as much as you think, and the documentation that does get produced should be concise and contain only information that couldn’t be captured effectively in the source code. Strive to single source information.
The best developers are generalizing specialists who have one or more specialties, a broad knowledge of development, and a good understanding of the domain. Teams made up of specialists can struggle to work together effectively because they don’t understand what each other is doing, and have a tendency to create lots of extra documentation because their skills are too narrow to allow them to capture information in the most appropriate manner.
There’s sufficient anecdotal evidence, and even research evidence, showing that agile software development is a good idea. If you have several initiative to do, and you’re struggling to succeed using your existing approaches, doesn’t it make sense to at least run an agile pilot to see if agile works in your environment?

I’m a Stakeholder…

In AM stakeholders, and in particular their active participation as team members, are a critical factor to the success of an initiative. You need to understand:

The rights and responsibilities of everyone on the team.
The basics of AM by reading An Introduction to Agile Modeling.
How you can be an active participant in the modeling efforts through adoption of inclusive modeling techniques.
Recognize that it’s ok for you to change your mind, because we manage requirements as a prioritized stack.