|
When you want to launch an agile project, where do you start?
June 01, 2006
URL:http://www.drdobbs.com/architecture-and-design/initiating-an-agile-project/188700850
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.
ONE OF THE MOST MISUNDERSTOOD aspects of agile software development is the first few days, or weeks if things aren't going well for you, of a new project. Little has been written about this subject, perhaps because it's a "phase" that we just get through on the way to starting the interesting development work, perhaps because it's fairly straightforward to people with agile experience, and perhaps because many traditionalists seem to struggle with the overall concept no matter how we explain it. Regardless, I'm going to do my best to overview how to successfully initiate an agile software development project.
Figure 1 depicts the lifecycle of a typical agile project (described in detail in "Where Did All the Positions Go?", DDJ, June 2006; www.ddj.com). Agilists refer to the initial iteration of a project as "Cycle 0," during which you determine whether the project is feasible, setup the technical environment, start building the team, and do sufficient modeling to support these activities. Sounds like what you do on a traditional project? Absolutely. The difference, however, is agilists achieve the same goals with a lot less effort—Cycle 0 is typically a week or two at most.
Fundamentally, you need to do just barely enough to get the job done, or as the Extreme Programming (XP) aficionados say, "You need to maximize the amount of work not done." This is likely where traditionalists struggle most when it comes to agility: You don't need anywhere near the level of documentation, or detail for that matter, that you've been led to believe over the years. For example, although you'll likely be asked for an initial estimate, you don't need to spend weeks or months doing detailed requirements, analysis, and design so that you have the input into some form of complicated estimating process. A ballpark estimate will often do, and frankly it is just as accurate as anything you'd produce counting function points or following COCOMO II.
An important consideration during Cycle 0 is the economic, technical, operational, and political feasibility of the project. So we ask ourselves if the system will pay for itself; if you have the ability to build the system (or to manage the project if you're outsourcing the effort); if you can keep the system running once it's built; and whether your organization can tolerate the successful delivery of this system. Although there are detailed techniques for determining the answers to these questions (which I describe at www.ambysoft.com/essays/ projectJustification.html), the fact is that I don't remember a project where I couldn't have honestly answered those questions during the first week with very little effort at all. Luckily, open and honest communication is a hallmark of agile teams, so if you're truly agile, then you should be able to easily address these questions. The alternative, of course, is to waste money following more bureaucratic techniques.
You begin to build your team during Cycle 0. You don't need everybody on the first day, but you do need your key people if available. This can be a bit different from what traditionalists are used to—there is very little "ramp up time" on an agile project because we start doing the work right away. On an agile project, there aren't weeks or months of modeling, documentation, and reviews to get through. Instead, there are hours or days of it—and then you start to work on building working software.
Ideally, agile teams are typically made up of generalizing specialists who have one or more specialties (for example, they're great at both use-case modeling and Java coding), a general knowledge of the software process, and at least a general knowledge of the domain. If you don't have such people yet, don't worry—as long as you can find people who are willing to work towards becoming a generalizing specialist, you should be okay.
One or more stakeholders will be active participants on the team, and now is the time to start identifying who these people will be, negotiating their availability, and actually getting them going. You want to start building relationships with critical stakeholders, such as the people paying for the system, who might not be active participants.
You also need to setup your working environment. This includes obtaining a workspace for the team and getting them moved into it. Don't underestimate the importance of shared tools such as whiteboards on which to sketch and dedicated wall space to post important diagrams. Furthermore, it is critical to setup the technical environment, including test databases, integration machines, testing tools, development tools, and your configuration management environment.
During Cycle 0 you will likely be required to do some initial requirements and architectural modeling (see www.agilemodeling.com/essays/amdd.htm) for several reasons.
When building business applications, I've found that the initial requirements modeling effort needs to focus on the development of a high-level usage model, a slim domain model, and a user interface (UI) model. The process that you're following drives the choice of your usage model—an XP team creates user stories, whereas an Agile Unified Process (AUP) team writes point-form use cases. The domain model should identify the main business entities (Customer and Account in a bank, for instance) and the relationships between them. During Cycle 0, you don't need to identify either the data attributes or the behaviors of the entities—this level of detail will be identified on a just-in-time (JIT) model-storming basis during development cycles. For the UI model, you may just need to draw a few whiteboard sketches of critical screens or you may need to do some UI prototyping, something you want to do after identifying the actual platform you'll be deploying to. The UI is the system to your stakeholders, and you need to convince them that you are able to understand their needs and deliver something usable that meets those needs. For complicated systems, a UI flow/navigation diagram may also be needed.
The goal of your initial architecture modeling effort is to try to identify an architecture that has a good chance of working. This is often done by the technical people on the team working together around a whiteboard, sketching and discussing what they believe will work. At this point, your goal is to come to a shared understanding of a reasonable architectural strategy, it is not to create mounds of documentation. As we identify the initial architecture, we'll try to ensure that it reflects the realities of the enterprise architecture, something that is much easier to accomplish when one or more enterprise architects roll up their sleeves and get actively involved with our project.
Agile or not, someone is going to ask the questions: "How much is this going to cost?", "How long is this going to take?", and "What am I going to get?". The real answers, respectively, are "As much as you're willing to spend," "As long as it takes," and "Whatever you tell us that you want," but few organizations are willing to tolerate this level of honesty and instead ask for "exact" answers. Striving for exact answers typically results in both time and money being wasted with little improvement in accuracy to show for it. I believe that it is time to admit that we can't predict the future accurately and cast off the shackles of traditional thinking.
Agilists will do just enough work to provide answers that are just as good, and just as inaccurate, as those provided by traditionalists. The difference is that we do an order of magnitude less work doing so and we're clear about the likelihood that they're inaccurate (which never seems to be news to our stakeholders, by the way). We want to get to the actual development effort where we regularly deliver high quality, working software that meets the changing needs of our stakeholders in a cost-effective manner. Isn't that what software development should really be about?
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.