Where Did All the Positions Go?

When management lets agilists in the door, roles and responsibilities are just a couple of issues that need to be addressed.


May 16, 2006
URL:http://www.drdobbs.com/architecture-and-design/where-did-all-the-positions-go/187203749

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.

Where Do I Fit In?

On agile teams we have roles such as stakeholder, developer, and coach instead of stakeholder, business analyst, architect, designer, programmer, tester, project manager, quality assurance expert, database administrator (DBA), and so on. The result is that it can be difficult for traditionalists to see where they fit into an agile project. Agile teams don't need someone who is just a DBA, but they do need someone with good database skills who can also model, program, test, and so on.

Table 1 presents strategies for traditional IT professionals to transition to agile software development teams. First, traditionalists must change their mindset (see "The New Rules" sidebar) and approach the situation with an open mind. Second, traditionalists should leverage their existing skills, which are still incredibly valuable, while learning new skills from their teammates. Table 1 also suggests a few activities that each traditional role should consider starting with as they ease into agile ways of working as well as activities and/or ideas that will hamper your ability to fit into an agile team.

Traditionalists often bring valuable skills to the table, and that's a great start, but you need to be willing to stretch your skill set in new directions if you're going to be a valued team member. A traditional DBA might have phenomenal database skills, but because agile developers iterate back and forth between development tasks, we might only need database skills for a few hours each week. It isn't sufficient to be a specialist any more. You can gain the new skills that you require by working closely with others who have those skills. Luckily, close collaboration is a fundamental value of agile software development.

The New Rules

To be successful as an agile developer, you must:

  • Focus on building working software. Upon hearing the detailed description of a requirement you should have working, tested software in place within hours or at most days, not weeks or months.
  • Maximize collaboration. Agilists rarely work alone; instead, they follow collaborative practices such as pair programming, modeling with others, and active stakeholder participation.
  • Become a generalizing specialist. Agilists have one or more specialties, a general understanding of software development, and better yet, a good understanding of the domain in which they work.
  • Minimize hand-offs. A hand-off between people or groups is a barrier to communication where defects will be injected and wastage introduced.
  • Constantly improve your skill set. Recently on the Agile Modeling list, Jon Kern, one of the original 17 signers of the Agile Manifesto, had this to say: "One of the hardest things people struggle with regarding "goin' agile" is that you have to 1) have a brain and 2) be willing to use it on a regular basis."

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.