Complementary To Other Methods ("drawing" on years of work)

The following sections look how Agile Draw will leverage existing standards (e.g. UML) and methods from the past (e.g. Coad, Yourdan, DeMarco, Martin) to avoid reinventing the wheel while leveraging years of work already done. Of course, Agile Draw looks to the future by aligning itself with the Agile Manifesto and the more further out philosophies such as OMG's MDA.

When/Where To Use Agile Draw

Use Agile Draw when you prefer simplicity over complexity, content over format, good enough documentation over precise artifacts, shared understanding over tools, practical matter over blue-sky abstractions, and obvious concepts over obscure notation.

The following figure demonstrates how Agile Draw can be used for higher-level modeling/design and user discussions while UML can be used for more detailed design and blueprint (e.g. reverse engineered models).

Looking to the Future: Alignment with Agile Manifesto

Principles From agilemanifesto.org	How Agile Draw Aligns
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	Agile Draw chooses the simplest form of diagrams which users can relate to and marketing departments can use.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.	Given the simplicity of Agile Draw, it is easier and more pleasant to either maintain diagrams or simply throw them away and recreate if needed.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	Instead of wasting time with big up front design (BDUF), you can use Agile Draw to get a shared understanding and move on to coding quickly and delivering frequently.
Business people and developers must work together daily throughout the project.	Precisely! This is exactly why Agile Draw is diagramming technique targeted towards higher level conceptual and business use.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.	I honestly believe if you give someone UML tools to diagram versus using simple tools with a free-form, fun and colorful approach, they might be a bit more motivated.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.	Agile Draw doesn't get in the way by introducing confusing notations. The concepts behind Agile Draw are the bare minimum to do basic sketching and high-level diagramming that all stakeholders can relate to.
Working software is the primary measure of progress.	Exactly! This is one of the values behind Agile Draw that code (working software) is the best source of progress and documentation (e.g. by using reverse engineering to generate pretty UML diagrams).
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.	Constant pace is about iterative development in short iterations (e.g. 1 to 3 weeks). Since minimal design is done at the beginning of each iteration, having an agile modeling technique comes in handy and keeps the pace of the project constantly moving without slowing it down with cumbersome tools and complex, un-maintainable diagrams.
Continuous attention to technical excellence and good design enhances agility.	Good design from refactoring on a daily basis. Agile draw helps with some minimal sketch work on the whiteboard, for example. Technical excellence comes from focusing on what matters (the code) and delivering a solid product each time while supporting the customer, not getting bogged down in complex diagramming notations and overkill processes.
Simplicity--the art of maximizing the amount of work not done--is essential.	Simplicity is what Agile draw is all about!
The best architectures, requirements, and designs emerge from self-organizing teams.	Self-organizing teams often work as groups, brain-storming around a whiteboard in a conference room or notepad in a cafeteria, having a simple sketching technique such as Agile draw is key.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.	Agile draw can be used to free-form sketching to see if how to improve on previous architecture, design or more.

Acknowledging the Present: Complimenting UML

Activity	Level	Best Technique	Examples
Discovering business concepts/objects	Conceptual	Agile Draw	Domain model
High-level architecture	Conceptual	Agile Draw	Free-form architecture
Explore high-level design	Conceptual	Agile Draw	Proof-of-concept, key classes, etc.
Implementation	Physical	UML	Detailed class diagrams for object and replacement for ER diagrams
Reverse engineering	Physical	UML	Get instant idea of system (e.g. blueprint)
Continuous software construction snapshot (a new idea; whitepaper/essay on the way)	Physical	UML	Automated reverse engineering.

A Tribute To the Past: Learning From "Out-of-Style" Methods

Many brilliant software engineers and methodologists paved the path for us by introducing innovative ideas that lead us to this point, some of these include:

• Grady Booch
• Peter Chen
• Edward Yourdan
• Peter Coad
• Tom DeMarco
• James Martin and O'Dell
• James Rumbaugh
• Nassi-Schneiderman (N-S) diagrams

Agile draw plans to borrow concepts from some of the above methods. At the very least, we will study the above techniques to learn from them.

Alignment With Other Present Philosophies/Techniques

Object Management Group (omg.org) Model-Driven Architecture (MDA)

If the MDA vision every becomes a reality (I hope it does but I'm skeptical), Agile Draw will continue to compliment it since Agile Draw is about conceptual modeling (e.g. on the whiteboard) and it helps to grasp some high-level concepts before jumping on the computer to begin architecting/designing with the MDA.

Agile Modeling (Scott W. Ambler, agilemodeling.com)

• "your goal is to build a shared understanding, it isn’t to write detailed documentation" - http://www.agilemodeling.com/essays/amdd.htm
• "…Simplicity Enables Agility…" - http://agilemodeling.com/essays/simpleTools.htm
• Software Modeling on Plain Old Whiteboards (POWs) http://www.agilemodeling.com/essays/whiteboardModeling.htm
• Some of the practices and principles:
  • Apply the Right Artifact(s)
  • Use the Simplest Tools
  • Create Simple Content
  • Depict Models Simply
  • Model with a Purpose
  • Maximize Stakeholder Investment
  • Travel Light
  • Multiple Models
  • Assume Simplicity
  • Quality Work
  • Software Is Your Primary Goal
  • Content Is More Important Than Representation

Extreme Programming (XP; extremeprogramming.org)

IBM Rational Unified Process (RUP; ibm.com)

Patterns of Enterprise Application Architecture (Martin Fowler, martinfowler.com/)

Domain Driven Design (Eric Evans, domaindrivendesign.org)

High-Assurance Design (Clifford Berg, assuredbydesign.com)