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 creation of a Stakeholder Goals Map to capture this critical information that you'll use throughout the project to guide decision making.
The product owner will also work to gain stakeholder support for the project during Iteration 0. They'll do this by helping to set stakeholder expectations of your Agile project team, educating them on the importance of working software over documentation, the roles and responsibilities of everyone involved with the project, and the importance of active stakeholder participation throughout the project. The product owner often works with the procurement and legal professionals in the negotiation of any contracts required for the project. They'll also be involved in the initial planning for the project, helping to identify critical dependencies on other teams as well as a potential release date. My July 2006 column (www.ddj.com/architect/188700850) covers Iteration 0 in greater detail.
At the beginning of each Construction iteration, the product owner is involved with the rest of the team planning out the work. An often-neglected aspect of Mike Cohn's planning poker (www.planningpoker.com) is the required modeling activities implied by the technique. To analyze the details behind a requirement, the product owner will not only drive the discussion, they'll also be active participants in any modeling, often whiteboard sketching. This modeling in effect is the analysis and design of the requirements being implemented that iteration.
The product owner will also be actively involved with model storming sessions (www.agilemodeling.com/essays/modelStorming.htm), which typically last between five and 15 minutes, throughout the iteration. No matter how good the iteration planning modeling, there will still be a need for business details when the developers go to implement the requirement, details that the product owner provides. Throughout the iteration, the product owner will be in regular contact with project stakeholders, often identifying new requirements or renegotiating priorities.
The product owner may be able to provide broad direction, but for any reasonably complex problem domain, they won't have all of the details and the team shouldn't have to wait on them to gather and then document the required information. Therefore, it is important for product owners to have a wide range of contacts within the stakeholder community and be able to schedule working sessions with experts as required. You can't expect all stakeholders to be available on a whim, but it is reasonable to be able to expect to schedule time with experts, even if it's only via a telephone call or e-mail.
Because the product owner represents the team to many stakeholders, they often find themselves demoing the software to stakeholders who don't work with the team regularly. It's critical to regularly show visible progress in the form of working software to communicate the work done to date. An "all-hands" demo can help to get feedback from a wide range of people quickly. Sometimes you may identify that you're in trouble, perhaps some stakeholders are being unfairly favored over others or, worse yet, that the product owner isn't doing a good job of representing the overall stakeholder community.
Sometimes demos aren't enough. If some stakeholders want more detailed information, the product owner may choose to invite them to listen in on the team's daily meetings. Or, with team permission, the product owner may even give them read access to the team's work products.
Although a traditional business analyst could fill the role of product owner, there is a significant risk that they can fall into old habits of communicating via documentation. The traditional software development community has significant cultural barriers to overcome when it comes to modeling and documentation, and as a result, experienced business analysts often struggle to fit into agile teams. Like I said, we need to do business analysis on agile projects, but that doesn't imply that we need specialized business analysts.
