Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Where Did All the Positions Go?

Scott is the practice leader of the Agile Modeling and Agile Unified Process (AUP) methods. His latest book is Refactoring Databases: Evolutionary Database Design (Addison- Wesley, 2006,). He can be contacted at www.ambysoft.com/scottAmbler.html.

A COUPLE OF MONTHS ago, I gave a talk about agile software development to a quality assurance and testing user group in my hometown of Toronto. I was asked by Michael Bolton (the group's president, not the singer/songwriter) to shake things up a bit, so I chose to describe how agilists actually work in practice when management allows them to succeed. Some people in the audience were very relieved to see that agilists have adopted techniques such as test-driven development (TDD), acceptance testing, pair programming, following development guidelines, code refactoring, and database refactoring, all of which promote creation of high-quality work products. A few were dismayed that I didn't demarcate a long list of positions, responsibilities for the positions, and the work flow between positions that they have come to expect from traditional methodologies. I didn't discuss these sorts of issues because they weren't really applicable. The times they are a changin'.

This isn't just an issue for QA people; the fact is that many traditional IT professionals are struggling to see how they fit into an agile software development project. The easy answer is that in their current state of mind they very likely don't fit. The hard answer, my topic this month, is that traditional IT people need to completely rework their expectations and skill sets if they're to succeed on agile teams. Just as we required a paradigm shift in the early 1990s to succeed at object technology, a similar paradigm shift is required for agile techniques.

Deceptively Similar, but Dangerously Different

A good starting point is to understand the agile software development lifecycle (SDLC) and its implications. Figure 1 shows an overview of the lifecycle for a typical agile project—be it an XP, Scrum, DSDM, or Agile UP project (or combinations thereof). The first week or so of an agile project is often referred to as "Cycle 0", cycle being an alternative term for iteration. During Cycle 0 you initiate the project, doing just enough initial modeling (www.agilemodeling.com/essays/amdd.htm) to identify the scope of, and a potential architecture for, your system. We often use simple tools, such as index cards and whiteboards to do this modeling—our goal is to understand the problem and solution domain, not to create mounds of documentation. We also start to build the development team and working environment, as well as garner initial support and funding for the project. Next month, I'll explore Cycle 0 in detail.

[Click image to view at full size]

Figure 1: The Agile Project Lifecycle.

During development cycles, we work closely with both our stakeholders and with other developers. We do this to reduce risk through tightening the feedback cycle and by improving communication via closer collaboration. We implement functionality in priority order, allowing our stakeholders to change the requirements to meet their exact needs as they see fit. The stakeholders are given complete control over the scope, budget, and schedule—they get what they want and spend as much as they want for as long as they're willing to do so. We analyze individual requirements by model storming on a just-in-time (JIT) basis for a few minutes before spending several hours or days implementing the requirement. Guided by our architecture models, often hand-sketched diagrams, we take a highly collaborative, test-driven development (TDD) approach to development where we iteratively write a test and then write just enough production code to fulfill that test. As required, we refactor our application code and/or our database schema to ensure that we have the best design possible. By taking this approach, we incrementally deliver high-quality working software that meets the changing needs of our stakeholders.

During the release cycle, we transition the system into production, an important part of which is final testing and fixing of the system. We finalize any system and user documentation at this point, assuming of course that our stakeholders are willing to invest in that documentation—agilists believe that if stakeholders are smart enough to earn the money then they must also be smart enough to spend it appropriately. We train end users, operations staff, and support staff to work effectively with our system.

On the surface, the agile SDLC looks very much like a traditional SDLC, but you discover this isn't the case when you dive deeper. Because the agile SDLC is highly collaborative, iterative, and incremental, the roles that people take are more robust than on traditional projects. In the traditional world, a business analyst created a requirements model that is handed off to an architect who creates design models that are handed off to a coder who writes programs that are handed off to a tester and so on. On an agile project, developers work closely with their stakeholders to understand their needs, they pair together to implement and test their solution, and the solution is shown to the stakeholder for quick feedback. Instead of specialists handing artifacts to one another, and thereby injecting defects at every step along the way, agile developers are generalizing specialists (www.agilemodeling.com/essays/generalizingSpecialists.htm) with full lifecycle skills.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.