Dr. Dobb's Journal - January 2008 - (Page 64) d01ambler_p4ma 11/9/07 10:14 AM Page 64 The Agile Edge Business Analysis Over Business Analysts For several years now, I’ve claimed that agile teams need to perform the activity of business analysis, almost every day in fact, but that they don’t need the role of business analyst. Although the role of product owner is close to that of the traditional business analyst, what they produce is often significantly different. Product owners facilitate communication, which means they will be actively involved in modeling and will inevitably produce some documentation, but they will do so agilely. Traditional business analysts often follow documentation-heavy strategies, something that proves to be a serious mistake in practice—considering that industry statistics show that traditional approaches to requirements specifications result in systems where 45 percent of their functionality is never used by end users. Not surprisingly, Dr. Dobb’s 2007 Project Success Survey (www .ddj.com/architect/202800777) revealed that 87 percent of people would rather have systems that meet their actual needs instead of those that fulfill initial specifications. Product owners clearly need to be skilled in agile business analysis to identify stakeholder needs, negotiate priorities between repeating stakeholder factions, and then collaborate with developers to ensure that the requirements are implemented effectively. This can be difficult in practice. For example, stakeholders are often not very good at describing their actual needs, and an important part of business analysis is to not simply take requests at face value but to instead explore with stakeholders what they really require. When you ask stakeholders why they need a feature, and do so several times to get to the heart of the matter, you often discover that their “requirement” is really a thinly veiled design solution that can be addressed more effectively in other ways. The lifecycle of AMDD indicates how modeling fits into the agile software development process. There are three basic times when business analysis occurs: initial requirements envisioning during Iteration 0, iteration planning at the beginning of each iteration, and just-in-time (JIT) model storming throughout an iteration. During Iteration 0, often called the “warm up” phase, the product owner will play a critical role in the project organization effort. They’ll help to identify potential stakeholders and involve the critical ones in initial requirements envisioning, and there’s a bit more to this than writing on index cards. First, even if all requirements can be captured on index cards, those cards still need to come from somewhere, implying the need for some initial modeling. Second, at the beginning of the project, you’re going to need to answer questions such as what are you going to build, how much will it cost, and how long will it take— this implies that you’ll need to do some scoping work. Third, cards aren’t the best option for all requirement types. For business software, you’ll likely need to do some user interface (UI) sketching if not outright prototyping, some initial domain modeling to identify major business concepts, and even some initial usage modeling. Fourth, because stakeholder priorities vary, you’re going to need to negotiate and then communicate those priorities. The Outside-In Development methodology suggests the 64 Dr. Dobb’s Journal l www.ddj.com l January 2008 http://www.ddj.com/architect/202800777 http://www.ddj.com/architect/202800777 http://www.programmingresearch.com http://www.programmingresearch.com http://www.ddj.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.