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 projectbe 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 modelingour 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.
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 schedulethey 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 documentationagilists 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.