Agile Methods

In a series of conversations, Kevin Brennan and I discussed the new role of the business analyst and what the future holds for people who build careers in this field. To structure our conversation, we articulated a central idea or axiom and then defined four key propositions that flow from that axiom. Presented below are that axiom and our thoughts related to the four key propositions.

In agile projects, you deliver the product in a series of successive and sensibly staged releases. Each release represents the culmination of a series of requirements decisions... One of your biggest challenges is ongoing-how to group and sequence requirements for optimal delivery. Let's take a look at adapting requirements workshops to meet that challenge.

The business analyst's job has changed this year -- and so have the critical skills that companies demand. New research shows that while communication is still key, knowledge of Lean and Agile methods is a must-have as well.

In Part 1 of  this article, I talked about the new skills and attitudes business analysts need to bring to agile development... Now it's time to talk specifics. What exactly do BAs do in agile development? How will your activities differ from those of traditional development? Let's take a look at agile business analysis from the perspective of the activities that make up requirements development and management, comparing traditional with agile analysis.
 

Quality requirements contribute to the success of agile and traditional project management projects. The requirements definition process followed in a traditional project management framework and the features-based storyboarding that is typical of agile approaches are different, but they also have many similarities. The actual process used to define and gather requirements may be different, but the criteria for quality requirements remain constant. What are these similarities and differences in the process of gathering requirements? What happens to the role of the business analyst in an agile environment?

Agile development practices introduced, adopted and extended the XP-originated "User Story" as the primary currency for expressing application requirements within the agile enterprise. The just-in-time application of the user story simplified software development and eliminated the prior waterfall like practices of overly burdensome and overly constraining requirements specifications for agile teams.

However, as powerful as this innovative concept is, the user story by itself does not provide an adequate, nor sufficiently lean, construct for reasoning about investment, system-level requirements and acceptance testing across the larger software enterprises project team, program and portfolio organizational levels. In this whitepaper, we describe a Lean and Scalable Agile Enterprise Requirements Information Model that scales to the full needs of the largest software enterprise, while still providing a quintessentially lean and agile subset for the agile project teams that do most of the work.

Agile is here, and it's coming soon to an organization near you-if it's not already there. As a business analyst, are you ready to make the transition to this value-centered development approach? How will your role change? What will you do differently? What will you actually do as part of an agile team? What agile analysis practices might you adapt if you're working on a traditional (waterfall-style) project?

In short, how can you make yourself more valuable to your agile team and organization using your business analysis skills and abilities?
 

Business analysis is an important aspect of agile software development projects, but the agile approach is significantly different than the traditional, serial approach of yesteryear. Because the agile approach to business analysis is different the approach to requirements specification is also different, for many traditionalists this will prove to be a significant cultural shock to them at first. In this article I briefly overview how business analysis activities fit into an agile approach, question some of the dogma around documentation within the traditional community, summarize some of the evidence showing that agile approaches are more effective in practice than traditional approaches, and end with strategies for specifying requirements on an agile project.

As an agile analyst, you know how easy it is to get lost in a blizzard of project details. The way to keep focused is to remind yourself of the chief reason for using agile processes: to deliver business value for your organization. With that in mind, we’ll look at specific ways you can combine two approaches: agile and lean.

If Agile is to become the next zeitgeist for development, what will become of the traditional Business Analyst?

We all know the traditional waterfall mantra: analyze, design, build then test... underpinned by the common belief that the more you analyze up front the more you save in maintenance later on. This has had a huge impact on the way we organize our teams: separating functions and putting a heavy emphasis on theoretical modeling.

When a project kicks off, the classic Gantt chart dictates that analysts are on-boarded early for a lengthy requirements analysis stage. Once the requirements specification is 'signed off' the analysts are often relieved of their posts for the design crew to take over. The 'sign off' fest continues until eventually the user community is (invariably) force fed a UAT phase and the fledgling product is launched; all the while resources are inhaled and exhaled as the project plan demands. The project then becomes more of a way to co-ordinate a set of individual skill sets and activities.

Why has it been necessary to write so many different, book-length treatises about requirements management on software projects? Is it not possible to develop an approach to handling software requirements that is simple enough to express concisely -- and yet can work with large, complex projects as well as smaller efforts?

At the risk of using a word that disturbs many in the field of software engineering, requirements management is just a process. The more simply this process can be described, the more likely it will be to work in real software organizations. So rather than consider every possible nuance relating to managing software requirements, this article will attempt to express the essence of an approach that can work well on virtually any Agile software development project. In the appendix, I include a detailed example illustrating the key ideas.

Author: Theodore F. Rivera, Software Group Strategist, IBM

Across North America, businesses in all sectors are adopting standard development methodologies to turn out a higher quality of goods and services. The tried and true approaches that have yielded such great results for competitors are heralded as best practices. But here is the sad news: no one methodology fits all. In fact, different methodologies are appropriate in fitting diverse projects. Some projects are so unique, future-thinking Business Analysts (BAs) are finding that the adoption of new hybrid concepts is the only smart way to go in problem solving tomorrow’s projects.

The word ‘fresh’ describes that feeling of turning over a new leaf when January 1 rolls around each year – and the sentiment we as individuals strive to maintain all year long when we set New Year’s resolutions. Much in the same vein as these annual goals, BAs seeking an innovative means by which they can see their requirements come to fruition are increasingly interested in the study of the existing methods that are in place within the industry, as well as fresh methods established through modeling and fusion.

The real world is a complex place, resulting in complex requirements for any system that has to work there. This is true regardless of development paradigm. Although "agile in the small" methodologies such as Scrum and Extreme Programming (XP) have done much to show us how to improve our approach, too many people have thrown out the requirements management baby with the bureaucracy bathwater after putting too much faith in the overly simplistic strategies of those processes. Luckily, with a bit of discipline, it is straightforward to address the inherent challenges of complex requirements in an agile manner without resorting to the documentation-heavy practices favored by the traditional community.

The Scrum method has popularized the idea of managing requirements as a stack of small, functional chunks, captured in a prioritized stack called a "product backlog". The idea is that at the beginning of each iteration/sprint, you pull an iteration's worth of work off the top of the stack. If only it were that easy. Although Scrum has helped us to get away from the onerous change prevention strategies (oops, I mean change management strategies) of traditional methods, it has blinded a generation of developers to the inherent complexities and nuances of understanding and implementing requirements.

Author: Scott Ambler

Study after study has shown poor requirements management is the leading cause of failure for traditional software development teams. When it comes to requirements, agile software developers typically focus on functional ones that describe something of value to end users—a screen, report, feature, or business rule. Most often these functional requirements are captured in the form of user stories, although use cases or usage scenarios are also common, and more advanced teams will iteratively capture the details as customer acceptance tests. Over the years, agilists have developed many strategies for dealing with functional requirements effectively, likely one of the factors leading to the higher success rates enjoyed by agile teams. Disciplined agile teams go even further, realizing that there is far more to requirements than just this, that we also need to consider nonfunctional requirements and constraints.

Nonfunctional requirements (NFRs), also known as "technical requirements" or "quality of service" (QoS) requirements, focus on aspects that typically cross-cut functional requirements. Common NFRs include accuracy, availability, concurrency, consumability (a superset of usability), environmental/green concerns, internationalization, operations issues, performance, regulatory concerns, reliability, security, serviceability, support, and timeliness.

A constraint defines a restriction on your solution, such as being required to store all corporate data in DB2 per your enterprise architecture, or only being allowed to use open source software (OSS), which conforms to a certain level of OSS license. Constraints can often impact your technical choices by restricting specific aspects of your architecture, defining suggested opportunities for reuse, and even architectural customization points. Although many developers will bridle at this, the reality is that constraints often make things much easier for your team because some technical decisions have already been made for you. I like to think of it like this—agilists will have the courage to make tomorrow's decisions tomorrow, disciplined agilists have the humility to respect yesterday's decisions as well.

Although agile teams have pretty much figured out how to effectively address functional requirements, most are still struggling with NFRs and constraints.

Author: Scott Ambler

Whether you’ve never heard of Agile or you just finished your nth Agile project, you need to understand that Agile is here to stay! Are you, the Business Analyst, an extinct species in this new world? Is your career changing? Do you need new skills?

Agile guru and visionary Scott Ambler talked with Adrian Marchis, ModernAnalyst.com's Publishing Editor, and shared his vision on what’s next for Agile and his thoughts on the role of the business analyst in the Agile world.