|
When trying to scale agile software development for complex situations, a common stumbling block is how to understand, prioritize, and act on requirements.
December 11, 2007
URL:http://www.drdobbs.com/global-developer/scaling-on-site-customer/204801134
Scott is a DDJ Senior Contributing Editor, Practice Leader Agile Development with IBM Rational, and author of several best-selling books. He can be contacted at www.ambysoft.com/scottAmbler.html.
A common stumbling block when trying to scale agile software development for complex situations is how to understand, prioritize, and then act on the multitude of requirements, which their system must address. This is an issue that traditional teams also face, one that is often addressed by business analysts. While business analysis activities are important, it doesn't imply that you necessarily need people in that specific role, nor does it imply that you need detailed requirements documentation. Then again, Extreme Programming's (XP) practice of having a single "on-site customer" doesn't seem to work beyond anything more than the simplest of situations. Most real-world Agile teams find that they need something in between these two extremes.
To successfully scale XP's on-site customer practice to meet your specific needs, my experience is that you should adopt four values pertaining to your relationships with stakeholders. In the lingo of the Agile Alliance, these four values describe preferences; while the ideas on both sides of each value are important, the ones on the left are more important than the ones on the right. These four values are:
The idea of the on-site customer practice is that there should be someone for the team to go to for timely information about the domain and to make timely decisions, particularly when it came to prioritization. Unfortunately, many people misinterpreted this advice to mean that you only needed to work with a single person, that you only needed to focus on the needs of end users, or that the person funding the project (the "gold owner") should drive all requirements. In the second version of XP, these misconceptions were cleared up, yet many teams still seem to fall into this trap.
Years ago, in Agile Modeling (Wiley Publishing, 2002), I pointed out that projects have a wide range of stakeholders, far more than just end users and gold owners. We also need to consider the needs of operations and support people, senior managers, architects, regulatory compliance auditors, senior management, and so on. These stakeholders all have important, different, and sometimes conflicting needs, which your project team must take into account. Unfortunately, it can be daunting when you first visibly recognize how many stakeholders actually exist, but the fact is that you will put your project team at risk if you limit yourself to just business stakeholders.
In Outside-In Software Development (IBM Press, 2007), Carl Kessler and John Sweitzer described a strategy for categorizing stakeholders. This categorization helps to make the range stakeholders explicit while at the same time managing to simplify the overall concept. Their four stakeholder categories are:
Because there is a wide range of potential stakeholders, it is difficult for a single person to represent them all, yet this is something that Agile teams often strive to do. Scrum (www.implementingscrum.com) is a partial methodology that focuses on project and requirements management that has a role called product owner, the single person who is responsible for prioritizing the team's requirements. Yet, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole. Product owners are in effect a communication conduit between the project team and its stakeholders.
Internally, the primary goal is to get the team information and decisions in a timely manner. That doesn't necessarily mean that the information has to come directly from the product owner, they instead may choose to put the team in contact with the appropriate expert stakeholders. Their primary external goal is to make the team's progress visible to the overall stakeholder community and thereby build up people's trust in the team's ability to deliver high-quality working software. Because the product owner is a communication conduit between these two groups, they often find themselves needing to define, communicate, and negotiate everyone's rights and responsibilities (see www.agilemodeling.com/essays/activeStakeholderParticipation.htm for some suggestions).
The role of product owner on Scrum teams greatly simplifies things for developers because they're the ONE person to go to for getting answers from the outside world, but in practice, all this really accomplishes is dumping the complexities of working with stakeholders onto their shoulders. Because Scrum provides little advice for people in this role, they quickly find that they need to supplement Scrum with the techniques of Agile Model Driven Development (AMDD), in particular, those pertaining to agile requirements analysis.
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.
There's a very real danger of product owners becoming a bottleneck on Agile project teams, particularly at scale. What development teams really need is direct access in a timely manner to the stakeholder(s) with the domain expertise required to address any questions that they may have about the functionality they are currently implementing. Stakeholder proxies are good, actual stakeholders are even better. A critical task performed by product owners is putting developers in touch with the right stakeholders in a timely and efficient manner.
Another important technique that doesn't get the attention it deserves is observing end users at work. In the late 1980s, the user-centered design (UCD) community showed us that what end users told us they did, and what they actually did in practice, could vary widely. People will often discuss the ideal way of working, ignoring significant details and less-than ideal events. For example, how many times have you told people that your morning routine is to wake up, shower, dress, have breakfast, then get off to work? Yet we all know that far more than showering occurs in the bathroom each morning, enough said about that topic, and that many of us would be embarrassed to admit what we actually consumed for breakfast. Until you observe people in action, you'll never know what actually happens, and therefore you'll never truly understand their needs.
To successfully scale the concept of agile customers to meet your specific needs, my experience is that you should adopt four values pertaining to stakeholder relationship management. In the lingo of the Agile Alliance, these four values describe preferences; while the ideas on both sides of each value are important, the ones on the left are more important than the ones on the right. These four values are stakeholders over customers; communication conduits over product owners; business analysis over business analysts; and stakeholders over stakeholder proxies. In this instance, the Agile community can clearly benefit from taking the good ideas of traditional development while leaving behind the bureaucracy.
Thanks to Mike Vizdos for his insightful feedback, which was incorporated into this article.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.