Agility Is for Everyone

Dear Software Development reader:

Every month, we receive letters from readers thanking us for our coverage of the design-build-test-deploy lifecycle for successful software projects. One of the must-read resources we provide is an annual developer salary survey. Our data is the most trusted and unique tool for anyone -- from developer to project manager to chief technology officer -- wondering whether they're getting paid what they're worth in the field.

If you work in the U.S., I'd like to invite you to participate in Software Development magazine's annual salary survey. The 26-question survey takes about eight minutes to complete, and can be found at http://www.cicresearch.com/Proj04725/Default.asp

Please be assured that all responses are completely confidential. This is used exclusively as editorial research for an article to be published in the November 2004 issue. Only aggregate results will be used, and we will not disclose or use your e-mail address for any other purpose than to alert you to next year's survey.

Sincerely,

Alexandra Weber Morales
Editor in Chief
Software Development
CMP Media LLC
600 Harrison Street
San Francisco, California 94107
[email protected]

P.S. Last year, we received over 6,000 responses -- a new record since we launched this research six years ago. Help us make this the largest developer salary survey in the U.S. -- the more data we have, the more accurately we can portray compensation, job satisfaction and technology trends!

>>AGILITY IS FOR EVERYONE
Database modelers can also benefit from a flexible approach.
By Scott W. Ambler

Over the years, I've learned that for agile teams to succeed, everyone -- from team members to those who interact with team -- must work in an agile manner. It's a fact borne out by not just my own experience, but that of thousands of other agile adherents. Although developers have quickly taken to agile software development techniques, other communities within the IT industry have not -- in particular, data professionals. Many agile techniques are applicable to data-oriented development -- visit www.agiledata.org for details-- and in this newsletter, I'll explore an important one: agile data modeling.

Data modeling is the act of exploring data-oriented structures, often to create some form of diagram and supporting documentation describing those structures. Evolutionary data modeling is data modeling performed in an iterative and incremental manner, and agile data modeling is evolutionary data modeling done in a collaborative manner.

In the July, August and September 2004 issues of Software Development, I show how to create a physical data model in an agile manner, explaining how the model evolves throughout the project. In those columns, I identified several important lessons that all data professionals should take to heart:

1. Be agile, yet still support the needs of the enterprise. Agility and fulfilling enterprise concerns aren't contradictory goals. Data professionals often lament that developers don't take the bigger picture into account, and often, that's a fair assessment. However, that doesn't mean you need to model everything to the nth degree before you start coding. Instead, seek the sweet spot somewhere between the extremes. Invest some time thinking about, and then acting on, about the bigger picture, but don't hold up development. Better yet, work collaboratively with developers to pass on your "big picture" skills -- and pick up some "small picture" skills in return.

2. Travel light. Agile data modelers write just enough documentation to get the job done and no more. Gone are the days when modelers took weeks or even months to write a comprehensive data model; now, you typically have minutes to capture the essential information before you must move on to other tasks.

3. Agile data models are just barely good enough. Agile developers solve today's problem today and trust that they can solve tomorrow's problem tomorrow. The same can be said of agile data modelers: You know that you don't have to model all of the potential data attributes an entity might need; instead, you model only the information required today and recognize that you can evolve your model when new requirements demand it.

4. Agile data models can and should follow your corporate standards. Agile Modeling (AM) includes a specific practice for adopting and following modeling standards and guidelines. Critical data modeling standards focus on naming conventions for tables and their columns, as well as conventions for writing stored procedures and triggers. These standards should be straightforward, simple, and adequately described so that the team can learn and then follow them.

5. Trying to define all the requirements up front is a risky proposition. One of software development's bitter truths is that, like it or not, requirements change. People change their minds, don't fully understand what they want at first, and sometimes external events occur that necessitate changes. If you try to baseline requirements too early in the life of a software development project, you'll simply guarantee that you build the wrong

thing. Embrace change and adopt techniques that allow you to react effectively to it.

6. It isn't enough to specialize in one aspect of technology. I shouldn't be talking about just data professionals and programmers -- I should widen my focus to include all IT professionals, because the industry still embraces the antiquated Taylorist concept of specialists. The most effective developers are generalizing specialists, people with one or more specialties (such as data modeling or programming), a general knowledge of software process, and, better yet, a good understanding of the domain in which they work. Expand your horizons and pick up some non-data skills. When you do, you'll be more effective because you can relate better to your coworkers. Remember, agile practioners work in a highly collaborative manner, so getting good at collaborating with others is a critical skill.

7. Some tasks that traditionalists avoid, agile practitioners choose to embrace. Agile practitioners realize that refactoring is a critical skill. Agile database administrators (DBAs) realize that database refactoring is a critical skill they need to evolve database schemas. Structural database refactorings, such as moving a column from one table to another, are quite common and often require data migration. Traditionalists believe that data migration is hard -- they're right about that -- and often try to avoid it whenever possible. Thus, they're not very good at migrating data. Agile practitioners, on the other hand, choose to get good at critical activities like these, and become more effective as a result.

Evolutionary, and more often agile, approaches are the norm for modern development projects. Data professionals can also work in an agile manner -- if they choose to.

>>RECENTLY ON THE AM MAILING LIST

Modeling Research Directions
At the beginning of July, I posted a list of suggested topics that I believe need to be looked into within the modeling community, such as my suspicion that upwards of 90 percent of all modeling is done on whiteboards and that the vast majority of developers lean toward nonvisual artifacts such as code instead of visual artifacts such as class diagrams. An upcoming newsletter will discuss these directions in detail.

Challenges with Modeling Research
I also posted a list of challenges I see with existing research into modeling; in particular, a lack of observational studies and an inward focus in which researchers reference only other researchers. Instead, researchers need to get out into actual companies and see what people do in the real world; if they did so, I suspect a lot more of them would discover the principles and practices of AM. I'm also worried that they're missing the agile movement, because most of the writings within the agile community are posted on the Web or in practical books, not in the academic journals favored by researchers. Something needs to give.

Finding the Requirements
A lively discussion focused on the types of questions modelers should ask to elicit requirements. Some can be positive, such as "What would you like to see?" and "How do you envision this working?", whereas others can be negative, such as "What don't you like about the existing environment?" and "When didn't the existing system support your needs?".

>>HOT LINKS

The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.
http://www.agilealliance.org

"Agile Data Modeling," Part 1, explores the first three iterations of the development of a fictitious karate school management system (KSMS).
http://www.sdmagazine.com/documents/sdm0407g/

"The Schema Evolves," Agile Data Modeling Part 2, describes what happens when the requirements for the system changes and explores how to approach iterations four and five.
http://www.sdmagazine.com/documents/sdm0408i/

The process of database refactoring is described at
http://www.agiledata.org/essays/databaseRefactoring.html

The essay "Agile Data Modeling: From Domain to Physical Data Modeling" takes an alternative approach to modeling the KSMS by starting with a high-level overview of the domain. Compare the differences between the resulting schemas as published in the SD magazine column.
http://www.agiledata.org/essays/agileDataModeling.html

Martin Fowler and Pramod Sadalage discuss the fundamentals of evolutionary database development at
http://www.martinfowler.com/articles/evodb.html

The Journal of Conceptual Modeling presents a collection of very good articles about domain modeling at
http://www.inconcept.com/jcm/

About.com provides links to a wide range of articles covering database design issues at
http://databases.about.com/od/specificproducts/

The principles of Agile Modeling are described at
http://www.agilemodeling.com/principles.htm

The practices of Agile Modeling are described at
http://www.agilemodeling.com/practices.htm

Check out the Agile Modeling mailing list at
http://www.agilemodeling.com/feedback.htm

Get agile modeling training resources at
http://www.agilemodeling.com/training.htm