When the term “agile” comes up in a conversation these days, the mind often jumps to agile software development.
But there’s so much more to being agile than delivering software products iteratively and incrementally.
If our planning or change strategies aren’t agile, we can forget about being able to deliver the maximum amount of business value possible to our customers. Our entire organization must be agile in order to be able to “keep our finger on the pulse” and rapidly adapt to meet today’s demands.
On top of being agile, the most successful organizations out there are also lean mean machines, capable of effectively managing the portfolio to avoid surprises and respond to threats quickly and efficiently.
In our webinar last month, The Path to Business Agility, Enfocus Solutions’ CEO John Parker discussed the four components that make up a lean agile business:
Enterprise Agile Delivery
The agile organization must have the ability to deliver products and services iteratively and incrementally based on discovered and validated customer needs.
Agile software delivery is usually the first place organizations start when adopting agile. Many organizations have yet to move onto implementing agile in other areas of the organization, and limit their focus to the responsibilities of the agile team. In reality, the agile team only makes up one part of Enterprise Agile Delivery, and Enterprise Agile Delivery only makes up one of four fundamentals that must be addressed for the organization to be considered agile. In the Lean Business Agility Framework, Enterprise Agile Delivery is achieved via three key elements:
Agile Teams (Scrum or Kanban)—Support day-to-day work of self-organized teams (using either Scrum or Kanban) to reduce cycle times and defect density.
Agile Portfolio and Program Management—Implement Agile Portfolio and Program Management to deliver more business value and provide more transparency.
DevOps—Manage DevOps to increase visibility and coordinate release management across multiple teams at once.
Customer Needs Validation
The agile organization must be able to understand who their customers are, what the customers’ needs are, and whether those needs are true or not.
According to the 2013 Standish Group CHAOS Report, even in the agile world, 64% of functionality is rarely or never used. That’s because organizations are giving the go-ahead to start developing software before getting an accurate understanding of customer needs. While traditional lengthy requirement gathering processes are a thing of the past, there’s still a need for performing minimal front-end analysis before starting to build anything. Unfortunately, most organizations don’t even do the minimum. But in order for the organization to be lean, we need to get rid of the waste of developing features and functions that are of no use to our customers, and that’s going to require iterative and incremental discovery and validation activities. The three key elements of successful Customer Needs Validation include:
Customer Discovery—Discover customers and understand their problems to gain a competitive advantage by being able to deliver products that customers want.
Customer Validation—Validate customer needs before building to reduce developer frustration and costs.
Customer Experience—Understand and enhance the customer experience to improve customer loyalty.
Service Strategy and Design
The agile organization must have the ability to design services and manage the service portfolio according to a service strategy aligned with customer needs.
Enfocus Solutions has found that the concepts and best practices of agile and the Information Technology Infrastructure Library (ITIL) work really well together. That’s because, when you get down to it, isn’t software just a more specific term for a type of service being provided to your customers? For example, is an Apple iPhone a product or a service? We see it as a service. When you purchase an iPhone, it includes support, delivers content, and answers questions such as, “Siri, where is the nearest donut shop?”
By applying agile principles to ITIL best practices, we are able to design and manage a cost-effective IT service portfolio that improves business and customer outcomes. The key to Service Strategy and Design is addressing the following three elements:
Service Portfolio Management—Identify service enhancements and manage the service portfolio to satisfy customer needs.
Service Delivery Model—Develop a Service Delivery Model that will increase efficiency and significantly reduce costs.
Service Design—Improve service design processes for better alignment between IT and the business and greater customer loyalty.
Business Change Management
The agile organization must have the ability to manage the effects of service changes on the entire organization.
When a new software feature gets delivered to the organization, the size of the effect potentially ranges from minimal to enormous, depending on what gets developed. When we don’t track the impact that software changes have on the rest of the organization, we often end up with some unpleasant surprises come delivery time. In a large organization, business processes, IT services, people, data, rules, and other capabilities may be affected by a software change. It’s our responsibility to ensure that the right parts of the organization are involved in supporting the necessary business changes. The three key elements to successfully performing Business Change Management include:
Collaborative Business Architecture—Collaboratively manage the business architecture to make informed decisions, increase transparency, and establish a common vocabulary.
Impact Analysis—Manage change following Lean best practices to achieve faster and wider user adoption.
Lean Change Management—Assess impacts, gaps, and risks in the portfolio to avoid surprises and respond to threats and opportunities more quickly and effectively.
Strategies for achieving business agility are discussed in our white paper, The Four Components of Lean Business Agility, available soon. Sign up for the eNewsletter below to make sure you get a copy.
Want the latest content and industry news?
Sign up for the Enfocus Solutions Newsletter!
Written by Karl Wiegers and Joy Beatty
The leader of a corporate requirements organization once posed a problem. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?” In another organization, a BA experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked.
These questions exemplify the challenges that can arise when trying to engage BAs, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that he’ll get what he needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as you are; if they were, they’d probably all become business analysts!
Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.
It’s possible that the resisters haven’t been exposed to solid requirements practices. Or they might have suffered from poor implementation of requirements processes, perhaps working on a project that produced a large, incomplete, and ignored requirements specification. That would leave anyone feeling frustrated. Perhaps the resisters don’t understand and appreciate the value of those practices when performed effectively. They might not realize the price they have paid for having worked in a casual and unstructured environment in the past. That price mostly shows up as unexpected rework that leads to late deliveries and poor software. Such rework is buried in the daily activities of the project participants, so they don’t recognize it as a serious inefficiency.
If you’re trying to get developers, managers, and customers on board, make sure everyone understands the past pain the organization and customers have experienced because of requirements problems. Find specific examples to demonstrate the impact in case individuals haven’t felt the pain themselves. Express the cost in units that are meaningful to the organization, be it dollars, time, customer dissatisfaction, or lost business opportunities. Development managers often aren’t aware of how badly requirements shortcomings hurt their teams’ productivity. So show them how poor requirements slow down design and lead to excessive—and expensive—course corrections.
Even if you don’t have data available to quantify the costs of requirements problems, every organization has an anecdotal legacy of project failures. People remember systems that were dead on arrival, rejected by users as unacceptable. Isn’t it strange how project teams never feel that they have the time to devote to getting the requirements right, and yet they always find the time, staff, and money to fix systems that were deeply flawed because of requirements errors? Use such stories from the corporate folklore to help steer the culture to a recognition that, without solid requirements, failure is highly likely.
Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. Therefore, they benefit from providing input that will make the requirements documentation as useful and meaningful as possible. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity. You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies.
Quality assurance staff and testers are also valuable contributors to excellent requirements. Instead of waiting until later in the project, engage these sharp-eyed people in the iterative review of requirements early on. They’re likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements.
Management plays a powerful role—often the dominant role—in shaping the culture of an organization. The organization’s leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Though project-specific and localized grassroots efforts are important, without management commitment, the improvements and benefits likely won’t be sustained after the project ends or after a reorganization. It doesn’t help if your senior people say they “support” the improvements but then revert to the same old processes the minute there is a fire. Behaviors—not pronouncements—constitute evidence of commitment to quality. Figure 1 lists ten signs that your organization’s management is truly committed to excellent requirements processes.
Figure 1. Some behaviors that indicate management’s commitment to excellent requirements processes.
Resistance to process or culture change can indicate fear, uncertainty, or lack of knowledge. If you can discern the source of the resistance, you can confront it with facts, reassurance, clarification, and education. Show people how their constructive participation in the requirements process not only is in their personal best interest but also will lead to collectively better results.
Business agility is more important now than ever, according to a recent report by Forrester Research. In the report, they define business agility as “the quality that allows an enterprise to embrace market and operational changes as a matter of routine.” As Forrester astutely points out, seventy percent of the companies that existed on the Fortune 1000 list ten years ago are no longer in service—the number one cause being the inability to adapt to change.
Many organizations have adopted agile methods for software or product development. Agile methods have helped organizations deliver more rapidly, increase customer satisfaction, and improve quality. However, agile development alone does not make the enterprise agile. An agile business must be able to make rapid changes that affect people, processes, data, technology, and rules to support threats and opportunities in the market.
The Lean Business Agility Framework™ is here to guide you through choosing the methods that will enable change and achieve business agility in your organization.
There are many great existing frameworks and methodologies for implementing agile best practices. However, the Lean Business Agility Framework combines all best practices into one comprehensive guide. The Lean Business Agility Framework was developed by Enfocus Solutions to help organizations visualize what is needed to transform to an agile enterprise. The framework incorporates current trends and integrates various methods from sources such as the Scaled Agile Framework® (SAFe), ITIL®, Lean Thinking, and Lean Startup® into a cohesive approach for moving to business agility. The framework is intended to serve only as a guide and requires an organization to selectively choose the methods that best fit their organization based on their level of maturity and culture.
For a full-size version of the Lean Business Agility Framework, download the white paper.
Inspired by the Scaled Agile Framework, The Lean Business Agility Framework takes the three levels from SAFe®, front-ends them with a Strategy Level, and back-ends the SAFe® levels with Business Change. In total, there are five levels in the Lean Business Agility Framework:
This blog will summarize the five levels of the Framework and the suggested methods of achieving each level’s specific goals. For in-depth descriptions of each of these levels, download the white paper.
Before developing a service to be delivered to customers, we need to understand who our customers are and what they need (not just what they want). This requires developing a set of hypotheses and assumptions about our customers and the service offerings necessary to meet their needs. Then, we focus on designing services that are guaranteed to meet their needs, and develop value stream maps to visualize the value delivered by the designed services.
We need to ensure the solutions we innovate align with discovered customer needs. The goal of this level is to develop an Epic Backlog that satisfies customers’ unmet needs. After an Epic is defined, we must understand its associated impacts, gaps, and risks to ensure we can successfully deploy the new software to customers. These tasks are made easier with a supporting collaborative business architecture that establishes a common vocabulary, vision, and degree of transparency that is required to make agile work. At the Portfolio Level is also where we align budgeting and accounting tasks with our Lean and Agile goals by providing our accountants with special Lean tools.
We start at the Program Level with breaking up Epics into Features that meet customer needs and have the ability to be independently developed and deployed. As we do this, it’s important to keep in mind the Plan-Do-Inspect-Adapt cycle to iteratively and continuously improve our product or service. Our goal is to deliver a continuous stream of value to the customer throughout many releases.
At the Team Level, we focus on developing the software and assessing progress throughout the development lifecycle. We use an “inspect and adapt” approach to improve quality and reduce time to market.
Business Change Level
Agile change agents and Lean best practices such as the Lean Change Canvas replace the traditional organizational change approaches followed by waterfall or plan-driven organizations. We use the Lean Change method developed by Jeff Anderson, which is an approach based on learning, co-creation, and experimentation. We don’t leave stakeholders out of the loop—in fact, we negotiate changes with stakeholders that will be impacted by proposed changes.
Lean Change Canvas
All of the levels of the Lean Business Agility Framework, as well as the suggested methods for being successful on each level, are described together in our white paper, the Lean Business Agility Framework.
There is no single correct way to document specific requirements information. Every BA needs a rich tool kit of techniques at her disposal so that she can choose the most effective requirements view in each situation. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I offer some ideas about how to make that choice.
Often, it’s valuable to represent information at both high and low levels of abstraction. The high level offers a big-picture perspective, whereas the low level of abstraction presents the nitty-gritty details. Certain audiences only need the high-level view, whereas developers and testers do need to see all those specifics, as well. An effective requirements analysis technique is to create an alternative view of the requirements from the initial set of information and examine it for problems.
Here’s an actual example. I once reviewed a requirements specification for a client who was developing the firmware for a device for testing integrated circuit components. The spec contained a long table that listed the various states this device could be in and what behaviors lead to changes from one state to another. Table 1 shows a portion of this table. I needed to know if all possible states were described and that the allowed state changes were all correctly specified. But how could I judge that? Missing requirements are hard to spot precisely because they don’t exist.
I decided to draw a state-transition diagram from the information in the original table, which appears in Figure 1. A state-transition diagram is a simple analysis model that provides a high-abstraction view of such a system. It shows the various states the system could be in at a given time (rectangles), the permitted transitions between states (arrows), and the conditions and actions that lead to each transition (could be written on the arrows if desired). Other conventions have similar notations variously called a state machine diagram, statechart diagram, or simply a state diagram.
Sure enough, I found some problems with this diagram, shown with the dotted red lines in Figure 1. First, the table contained no functionality to get to the Off state! That is, I expected to see an arrow in the diagram going from Shutdown to Off, but I found no requirement to make this happen. Also, the table didn’t mention the possibility of an error occurring while in the Running state. Thus, by creating this second view as an analysis tool, I identified a couple of missing requirements. Better now than later, I always say.
Table 2 suggests techniques that are appropriate for representing various types of information at both high and low levels of abstraction. Chapter 12 of my book with Joy Beatty titled Software Requirements, 3rd Edition (Microsoft Press, 2013) provides more details on many of these methods and contains references to additional sources to learn about these techniques. Use this table to help you select appropriate techniques for documenting your requirements information.
An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable. This article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), briefly describes some alternative types of requirements views to consider.
Analysis models are diagrams that present information visually. The table below lists several of the graphical analysis models that are available to the BA. Some of these date back to the structured analysis movement of the 1970s and 1980s. Others are part of the Unified Modeling Language, which provides a rich set of conventions for object-oriented analysis and design. I don't have the space to describe these various techniques in detail here. See my book with Joy Beatty titled Software Requirements, 3rd Edition (Microsoft Press, 2013) for descriptions and examples of several of these—and other—modeling notations.
Note that some requirements authors use the term model to describe any method for representing requirements information, including a list of textual functional requirements. When I say model or analysis model, I’m referring to a diagram that represents requirements information visually, generally at a higher level of abstraction than written requirements offer. I highly recommend that you use standard notations when drawing these kinds of diagrams. There are enough types of models in the software literature to cover nearly every situation, so you should almost never have to invent a new kind of diagram. Remember that these are communication tools. If you make up your own kind of picture using some other language of symbols, no one else will know how to read it. This rather defeats the purpose of communication. Instead, take the time to learn about the various modeling notations. You can practice with them by documenting an existing system, so you learn which types of models are useful for showing certain kinds of information.
Decision Tables and Decision Trees
These are tabular and graphical techniques, respectively, for representing complex logical expressions (such as a sequence of if/then statements) and the associated system behaviors. They are a great way to ensure that you have written requirements to cover the system's behavior with all logical combinations of conditions. Complex logic often leads to missing requirements because certain combinations of ANDs, ORs, ELSEs, and NOTs were overlooked. Decision tables and trees are particularly good techniques to spot exceptions whose handling hasn’t been specified.
Functional requirements describe the behavior of the software to be built. Test cases describe ways to determine if the correct requirements have been implemented properly. Functional requirements and test cases represent two complementary ways of thinking about the software system. The first is from a constructive perspective (let me describe how to make it), and the second is from a destructive perspective (let me try to break it).
One school of thought maintains that detailed written requirements aren’t necessary; user acceptance tests provide an adequate description of what needs to be built. I prefer to think of specifications and test cases as being complementary views of the requirements. Thinking about the system from both perspectives often reveals inconsistencies and gaps in the BA’s and user’s knowledge.
Prototypes and Screen Designs
When prototyping, the BA is taking a tentative step from the requirements domain into the solution space. A prototype is like an experiment. It tests the hypothesis that the requirements you have developed to date are accurate and complete. Most people find it more insightful to work with a prototype than to read through a long list of functional requirements. A prototype serves as a tangible first cut at some portion of the possible product.
A low-resolution prototype, such as a wireframe, provides the gist of the proposed user interface, whereas a high-resolution prototype presents detailed screen designs. However, even a detailed visual prototype does not depict the details hidden behind the presentation layer. A prototype doesn’t show input field interactions or describe how the system processes input stimuli to produce output responses. As with analysis models, a prototype is a useful but insufficient means of “documenting” requirements; you still need to record the details somewhere.
Tables and Structured Lists
If multiple requirements are worded similarly except for a particular change from one requirement to the next, consider grouping them in the form of a table or a structured list. Grouped requirements are more maintainable because a global wording change need be made only once. This is more concise than writing out all the individual requirements in detail, and the differences between the similar requirements will be obvious. For traceability purposes, each item in a list should receive a unique identifier. Following is a set of similar requirements from an actual SRS, shown in the original style (bulky, repetitive, and eye-glazing) and then as a much more compact structured list. The list form more efficiently communicates the same information and still provides a unique label for each requirement.
SGML.Insert.23: The product shall provide a facility that will insert SGML data corresponding to signature block formats selected by the user from among a set of available boilerplate signature blocks.
SGML.Insert.24: The product shall provide a facility that will insert SGML data corresponding to leaveout formats selected by the user from among a set of available boilerplate leaveouts.
SGML.Insert.25: The product shall provide a facility that will insert SGML data corresponding to caption formats selected by the user from among a set of available boilerplate captions.
SGML.Insert: The product shall provide a facility that will insert SGML data selected by the user from among a set of available boilerplate formats for the following:
.23: Signature blocks
Mathematics provides a precise, concise, and unambiguous language for represent certain types of knowledge, particularly that associated with performing computations. Some types of computational information are better represented in the form of tables. Two examples are interest rates as a function of investment bond term and discount percentages applied to volume purchases of a product.
Always keep in mind that specifying requirements is a communication process. Every BA should develop a rich toolkit of techniques for representing information effectively. If natural language is the best technique in a particular situation, fine: use it. But first ask yourself whether some other method, either by itself or in conjunction with the text, will do the job better.
If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.” Unfortunately, we have no absolute “terrain” for requirements: every representation is a map! Even though you can’t tell which representation is correct, differences between them indicate problems. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I’ll explain the value of creating more than one view of your requirements.
Consider the figure below. A use case presents a high-level view of requirements from the user’s perspective. It describes some goal the user needs to accomplish with the help of the system, expressed as a sequence of interactions between a user and the system that leads to an outcome of value. A primary purpose of the use case technique is to help the BA derive the functional requirements that developers must implement to let users perform a use case. These functional requirements represent a second, more detailed view. The BA might also draw graphical analysis models, diagrams that represent additional views of the requirements. The BA should be able to relate the functional requirements to elements shown in the models to make sure that these complementary views agree.
Suppose a tester were to write some test cases—thereby creating yet another view of the requirements—based on the use case. Now the BA can compare the test cases with the functional requirements and the analysis models to look for mismatches. You might find that a particular test case cannot be “executed” with the current set of functional requirements. (Note that you don’t even have to have any executable software to benefit from this sort of conceptual testing.) Or you might discover that a specific functional requirement is not covered by any test case. Such disconnects can reveal missing and unnecessary requirements, as well as missing and incorrect test cases.
Ambiguities, assumptions, or missing information in the use case description can lead the BA and the tester to different conclusions, which they can find by comparing the various views derived from the use case. Every time I’ve performed this kind of comparison between test cases, functional requirements, and other views, I have discovered errors. Fixing those errors at this stage is a whole lot easier than fixing them much later in the project.
Pictures, such as graphical analysis models, represent information at a higher level of abstraction than detailed text. It’s often valuable to step back from the trees and see the forest as a whole—the big picture. This is a valuable way to find missing and incorrect requirements. A reviewer could examine two pages of detailed functional requirements that seem to make sense, but he might never detect the one requirement that isn’t there or the one that is simply wrong.
Suppose, however, you draw a picture—a model—based on your mental image of how that part of the system ought to function. Then you compare the model to the list of requirements, and you find that a line from one object in the diagram goes to a different destination than the corresponding requirement says it should. Which is correct? The BA might not be able to determine which is right, but the difference between the two views points out a problem you need to resolve.
This high level of abstraction allows the reader to see how pieces of information fit together without getting mired in the gory details immediately. Of course, developers and testers eventually will need the details so they can do their jobs. Early in the days of structured analysis, the philosophy was that diagrams could completely replace the need for a detailed requirements specification. This simply doesn’t work. Models, prototypes, and the like are highly valuable, but they don’t contain all the information developers and testers need. Use high-abstraction models to supplement—not replace—textual specifications with an alternative communication vehicle.
Different people learn and comprehend information in different ways. Some people like to read, others prefer pictures, while still others learn best by listening or while manipulating something with their hands. To accommodate these different learning styles, try to depict information in a variety of ways. It’s not obvious how to help tactile learners examine a requirements specification, but multimedia can provide a rich communication experience. You can embed hyperlinks in a word-processing document to other types of objects:
- Sound clips that explain a particular concept.
- Video clips that illustrate how something works or how a user performs a task.
- Photographs that depict views of an object from various angles.
I see little use of hypertext in the requirements documents I review, yet hypertext is an excellent way to provide your readers with easy access to other related information. Consider incorporating links to reusable sources of common data definitions, user class and actor descriptions, glossary entries, business rules, and the like.
As with every other requirements technique, creating multiple views incurs a cost. In addition to expending effort to create the different views, the BA must keep them all current as changes are made. If the views get out of sync with each other, readers won’t know which one to believe (if any). This reduces the value of the multiple views. You might not need to update a high-level model every time you change some detailed functionality description, but you’ll probably need to revise the corresponding test cases. Don’t become a slave to the modeling, caught in the analysis paralysis trap of endlessly perfecting the pictures. In many cases, though, the cost of creating and maintaining multiple representations is more than outweighed by the insights into the requirements that different views offer and the errors they reveal early in the game.
There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant. The first man wrapped his arms around the elephant’s leg and said, “Why, an elephant is just like a big tree.” “No,” said the man who held the elephant’s tail, “an elephant is like a rope.” The third man felt the side of the elephant and reported, “This elephant is like a big wall.” The fourth man gripped the elephant’s trunk and declared, “You’re all wrong. The elephant is like a giant snake.” The fifth man rubbed the elephant’s tusk and said, “I think an elephant resembles a spear.” “No, no, no!” said the final man, who touched the elephant’s ear. “An elephant is like a big fan.”
The blind men were all correct. The elephant has all the characteristics they described, but no single feature of the elephant provides a complete description of what an elephant is all about. Each man had but a limited view of the elephant and could draw conclusions only from that view.
There’s an analogy with software requirements. I learned long ago that no single view of the requirements tells us everything we need to know about them. Often it’s desirable to represent requirements in multiple ways, thereby giving the readers a richer, more holistic understanding of the requirements elephant. Unfortunately, nearly every requirements specification I have read contains just a single view: natural language text. The clever business analyst can do better than that.
Limitations of Natural Language
Natural language is, well, natural for people to use. We employ it every day of our lives in diverse forms. But natural language has some shortcomings. One of the biggest limitations is ambiguity. I once was talking with my father about cars. I said, “For my next car, I’d like to get one of those high-mileage gas-electric hybrids.” My father replied, “I don’t know if you’re going to be able to find a used one.” Used one? I didn’t say anything about buying a used car. When I said high-mileage, I meant, “gets many miles per gallon.” When my father heard high-mileage, he thought, “big number on the odometer.” These are both perfectly sensible interpretations of the phrase high mileage. Ordinary, natural language led to a miscommunication in a casual discussion with someone I knew rather well.
In conversation, we rely on context, body language, and the chance to ask questions for clarification to ensure that we understand what we heard. We have an opportunity during discussions to detect and quickly correct ambiguity. Written communication, such as a requirements specification, doesn’t allow for this opportunity. Confusion can result from misinterpretations and ambiguity, and ambiguity is one of the big risks that natural language poses for requirements. This is one reason why you should never expect an SRS to replace conversations among BAs, developers, and customer representatives. However, when collaborating on software development over long distances, you don’t have many opportunities for conversations. High-quality written communication becomes essential for success.
Writing in natural language also leads to bulky and verbose specifications. In an attempt to clarify what he’s trying to say, the BA might duplicate a piece of information or state it in more than one way. Redundancy often is not helpful in requirements specifications. It can introduce additional ambiguities and inconsistencies. And, frankly, long documents with page after page of text are boring to read and daunting to review. There’s a good chance that reviewers will glaze over and fail to find some of the problems in the document. This is unfortunate, because well-executed reviews of requirements documents are one of the highest-leverage quality practices you can perform on a software project. Detecting and removing defects while they are just ideas is much faster and cheaper than correcting problems in the code.
Another issue is that detailed textual requirement statements represent a low level of abstraction. Each requirement describes but a small fragment of the system’s functionality or characteristics, with little context. Specification readers can have a hard time grasping the big picture and seeing how each individual requirement contributes to it. This makes it difficult for them to judge whether each requirement is correct, complete, and necessary. So the ability to depict requirements knowledge at multiple levels of abstraction and from different perspectives provides a much richer understanding than can any single view.
In this series of four articles, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I will describe why it is so valuable to create various views of your requirements. I’ll tell you about some of the analysis models and other techniques you can use to represent requirements information and give you some ideas about how to choose an appropriate model.
With the PMI’s recent release of the new Professional in Business Analysis (PBA) certification, business analysts (BAs) in the community are asking what is the difference between this new PMI-PBA and the IIBA’s existing Certified Business Analysis Professional (CBAP)? Also, if we’re looking into getting certified, which one should we go after?
In their announcement to offer the new certification, the PMI quoted a statistic by the US Bureau of Labor Statistics that “business analysis jobs are predicted to increase 19 percent by 2022.” We agree that this is a good reason for more people to get certified in the field of business analysis. We’re looking at this new certification from the PMI as great news; business analysis as a profession needs to break through the lack of recognition and demand more respect from the global community so that we can all be more successful in our jobs. This certification is definitely a step in that direction.
But before you go and sign up for the PMI-PBA pilot program, we recommend making sure it’s the right certification for you. After looking at the available literature, including the PMI-PBA Examination Content Outline (ECO), it is apparent that this particular certification is focused on a very specific area of business analysis, and is developed for a very specific subset of business analysts.
According to the PMI’s literature on the new certification, “business analysis is a critical function that helps define business requirements in order to shape the output of projects and drive successful business outcomes. In order to ensure the quality of requirements and projects, it is crucial that individuals be skilled and knowledgeable in industry standards and best practices.” While at Enfocus Solutions we agree this is true, we’re also aware that there is a broader usage of business analysis than the PMI-PBA’s project- and program-focused definition.
There’s more to business analysis than just requirements. We’ve always preached that at Enfocus Solutions. While the PMI has acknowledged there are broader applications for business analysis, they do not focus on those topics as a part of the PMI-PBA certification. Their website is very clear that the focus of the PMI-PBA is business analysis in the context of project and program management.
The scope of the PMI-PBA is much narrower when compared to the CBAP offered by IIBA. The PMI makes it clear their BA certification significantly emphasizes requirements management, especially with the recent release of the Requirements Management Knowledge Center of Excellence. On the other hand, the IIBA’s Business Analysis Body of Knowledge (BABOK), a well-established resource for BAs, incorporates enterprise and strategic business analysis, as well as requirements management. Comparing BABOK’s Knowledge Areas to the PMI-PBA ECO’s Domains, you can see the PMI-PBA is centered around requirements development and management activities, whereas BABOK has much broader applications.
This isn’t necessarily a bad thing. It’s just something to keep in mind when looking for the right certification for yourself. In what ways will you need to use business analysis? Are you performing it on an enterprise-scale, or a project-scale?
When we compare the qualification requirements for the two certifications, it becomes apparent that the PMI-PBA leans toward a certain type of audience—that of project and program management. For applicants with a relevant bachelor’s degree, the PMI-PBA requires less hours of BA experience. The PMI-PBA requires 4500 hours over 8 years, versus the CBAP’s requirement of 7500 hours over 10 years. The PMI-PBA is actually more similar to the Certification of Competency in Business Analysis (CCBA) offered by IIBA, which only requires 3750 hours of BA experience over 7 years. What does this tell us? That people going after the PMI-PBA probably don’t spend all of their time on business analysis, and most likely have other project-related responsibilities.
Also, to renew the PMI-PBA every 3 years, you must complete 60 Professional Development Units (PDUs). These courses are created by education providers registered with the PMI, meaning the content is generally focused on project and program management. This is also something to keep in mind if trying to decide between one certification or the other. Are you planning on following a project management-focused path? Or, will you need to learn broader applications of business analysis?
While both certifications have their merits, the PMI-PBA is very obviously geared toward someone with an existing project management background. The IIBA’s CBAP is geared toward a broader audience by including enterprise and strategic business analysis activities. There is an existing, well-established body of knowledge developed by the IIBA, covering all areas of business analysis. However, some people don’t need all of that information. Business analysis is often only a part of what someone does. So, depending on your goals, either certification could be the right one for you. Generally, we suggest people who work in more of a project management capacity to apply for the PMI-PBA as a natural continuation of your project management skills development.
When it comes to software development projects, agility should be focused on delivering business value in increments, and not developing software in cycles. While software development is a major aspect, it’s not the end goal of our projects.
Too often when following agile development, the team is uncertain or unclear of what to build that will actually deliver the value set out for at project inception.
Then, what happens is the team starts coding before understanding what really needs to be built, which is a very expensive way to validate that the solution meets customer and business needs. If there is no feedback until the end of a big project, it might be too late or costly to adjust. Instead, it is prudent to get as much feedback as possible, as early in the project as possible.
As Eric Ries, author of Lean Startup, puts it, don’t we all want to “avoid building products that nobody wants?” Recent Standish Group research shows that 20% of Features are used regularly and 50% of Features are hardly ever or never used. According to the study, the gray area is the 30% of Features and functions that get used sometimes or infrequently. All of these Features and functions that are never or barely used are causing higher costs, lower value, and longer cycle times, resulting in lower customer satisfaction. Focusing on the 20% of the Features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction.
To focus on the 20% of Features that give the most value, you need to validate early. So instead of coding and then getting feedback from stakeholders, validation should be upfront in the project and follow Lean best practices, meaning performed with as little waste as possible. The Lean concept of Minimum Viable Product (MVP) is perfect for cost-effective product validation. The MVP is that version of a new product or service which allows a team to collect the maximum amount of learning and feedback with the least amount of effort required. MVPs help the project team to identify and focus on the issues and features that are important to customers before developing a fully working solution.
According to Eric Ries in his presentation on the “Minimal Viable Product,” there are several useful techniques for creating a MVP so that the team can prioritize and eliminate the Features and functions that provide little or no value to customers:
Smoke Testing—Determine whether users would actually pay for a product or service before developing it by creating landing pages where users can pre-order. Then, use Adwords to attract users to your site. A smoke test is a tried and true marketing technique that measures customer interest in the product or service.
Search Engine Marketing (SEM)—SEM is a Google innovation in which the advertiser decides how much a user’s click on an advertisement is worth. After setting the amount per day you’re willing to spend, sit back and watch the search engine bring visitors to your website. SEM is a great technique for startups and small businesses who don’t have much of a budget for marketing. Over time, through website optimization (i.e., tweaking landing pages, split-testing the payment system, etc.), those visitors will convert into customers.
In-product Split-Testing—Create hypotheses about an existing product or service and test your ideas out to determine whether your hypotheses about what customers really want are correct. Split Testing can be used to test out large and small changes, and it’s a good way to get regular feedback and avoid building something nobody wants.
Paper Prototypes—Draw a basic prototype on paper of how an application interface should work, and walk customers through what it will be like and how it will solve their pain points. Paper prototypes are good for identifying usability issues in software that hasn’t been built yet, meaning the team isn’t wasting time and money developing something that doesn’t work.
Customer Discovery/Validation—First, discover what customers need and want through various stakeholder engagement methods, such as personas, scenarios, and stakeholder needs. Then, create a repeatable sales roadmap and corroborate your business model with Customer Validation. Validate that you are offering a product that customers want to buy through the process you’ve devised to sell it. When Customer Validation is successful, continue on the roadmap as planned. When it isn’t successful, return to Discovery activities to determine what customers will pay for. Customer Discovery and Validation should be a no-brainer on every product and service, but often gets left out or done poorly, resulting in unsuccessful projects.
Removing Features—Remove unnecessary Features and focus on the single value proposition that outweighs all others. This is a good technique for new product development. When early users adopt your solution because of how awesomely you executed that value proposition, you’ll have the chance to add those Features and wow them again later. Removing Features can also be a useful technique for existing products and services when certain Features do nothing for user engagement or revenue.
The benefits of using this approach are quickly evident when the organization starts to receive value early in the project cycle. Using code to validate ideas is very expensive, but there are cheap methods available. Better, more cost-effective validation practices will eliminate working on Features that provide little or no value.
There were a few great questions asked at the end of our webinar yesterday, Agile Business Transformation. While I didn’t have time to answer them in the information-packed webinar, here are your answers.
Q: Does Enfocus know of publications on Agile transformations for business with products with HW as well as SW products?
A: --Agile Development has been used for both the development of hardware and software products. One of the best-known examples is the development of Nokia phones. In Enterprises, many infrastructure groups are also starting to use agile. Many organizations are starting to adopt DevOps which is an umbrella concept that refers to anything that facilitates a smoother interaction between development and operations. The best information for large agile transformations is at www.scaledagileframework.com. There is also a major movement toward integrating Lean with agile and there are several good books on this subject. A very good book on this subject is Implementing Lean Software Development: From Concept to Cash by Tom and Mary Poppendieck.
Q: I find it challenging to differentiate a Feature from An Epic! For example, how would you determine if a BR is a feature or an Epic?
A: -- Great Question. A feature has to be small enough to fit into a Release. An epic spans multiple releases. Epics are approved by Portfolio management, whereas Features are defined by program management and are used to decompose an Epic into manageable components. View an epic as a project and a feature as a component of a project.
Q: Most of the time, we find the stories changing to be a Feature or Epic!
A: --This is very common. Teams have to groom the backlog to ensure that stories are small enough to fit into a sprint. Some Scrum trainers recommend that Teams spend 10% of their time each week grooming the backlog. It is much better to have a separate backlog for Features and another backlog for Stories. The Feature backlog is maintained by Program management. The Features are validated and prioritized and given to Teams when ready. The Team Product Owner and Team Members break the Features into stories that comply with INVEST. One backlog for both does not work well for most teams. Many people refer to this problem as “user story hell.”
Q: Question: My team consists of system integrators. Before we can engage them, we need an SOW and they need requirements. With agile, there's no sets of requirements, how do you guys address this gap?
A: Enfocus Solutions fully addresses this gap. There are two basic ways to do this. It really depends on who provides the Product Owner.
If your organization provides the Product Owner, then the Product Owner defines stories for the backlog and works with development teams to negotiate what will be done for each sprint. You are basically negotiating for a fixed number of sprints. The Product Owner’s job is to define the user stories and associated tests in enough detail to maximize the velocity of the Team. The Product Owner will also need to serve as the SME for the team.
If the Product Owner is provided by the Systems Integrator. Then you will be defining a set of Features which represents the project scope. The validated set of Features is placed in a Statement of Work and are given to a System Integrator. The SOW is done for each Release. Our software fully supports both of these methods.
Q: Could you update the presentation so that on slide 11 with all those stats, could you provide the link to the source, or at least the dates of the report?
A: A copy of the updated slide is shown below. (Also note all slides will be sent to registrants and available in the archive within a few days.)
Q: Slide 13: Any stats on how many organizations actually use paper? Versus Word or other docs that are stored electronically.
A: -- I do not have stats on this. I think the number will grow continually as organizations become more agile. There is a huge growth in collaboration and agile development tools. Producing paper documents is slow and anti-agile.