Agile Methods

The benefits of Agile methods are becoming more obvious and compelling. While the most popular practices were developed and proven in small team environments, the interest and need for using Agile in the enterprise is growing rapidly. That's largely because Agile provides quantifiable, "step-change" improvements in the "big three" software development measures - quality, productivity and morale. Confirming Agile's benefits, hundreds of large enterprises, many with more than 1,000 software developers, are adopting the methodology.

Regarding software architecture, it's interesting to note that it is the "lighter-weight" Agile methods, specifically Scrum and XP, that are seeing the broadest adoption in the enterprise.

The product backlog is a beautifully simple artifact – a prioritized list of the outstanding work necessary to bring the product to life. To work with the product backlog effectively, it needs regular attention and care; it needs to be carefully managed, or groomed. Business analysts can play an important role to ensure that this is done well.

Today’s business systems aren’t agile – even when agile software methods are used to develop them. Companies need business agility, and in most cases we simply aren’t delivering it. 

Here’s an example from recent experience. I visited a very large health care organization and had conversations there with a variety of people.

The purpose of companies creating Business Analyst positions is to improve IT quality and efficiency while reducing project failures. When I first started as an Analyst, coming previously from the position of Software QA and having an education in technical writing (think documentation), I thought I was the perfect mix for the position. I quickly learned that having a job where I prove my worth through project success can be stressful.

Through development and beyond we hope not to have show stoppers, anticipate builds and releases on time, expect teams to portray efficiency, want our customers to be happy, and hope that boss coming to work and singing melody. Sounds like a perfect five-course scrum, isn’t it?

If you ask Business Analysts what they think about ‘Agile’, you’re likely to get a mixed bag of answers... With so many different ideas on what Agile is and how Agile impacts the Business Analysis profession, we decided to talk with leading experts in the Agile field and get their opinions on the subject.

Extreme Inspections are a low-cost, high-improvement way to assure specification quality, effectively teach good specification practice, and make informed decisions about the requirements specification process and its output, in any project. The method is not restricted to be used on requirements analysis related material; this article however is limited to requirements specification. It gives firsthand experience and hard data to support the above claim. Using an industry case study I conducted with one of my clients I will give information about the Extreme Inspection method - sufficient to understand what it is and why its use is almost mandatory, but not how to do it. I will also give evidence of its strengths and limitations, as well as recommendations for its use and other applications.

I'm hearing the word "value" a lot lately. This is partly because the economic downturn has us looking to get the most for our money. But that's not all. More and more managers, business analysts, programmers and testers are talking to me about value. They are concerned that their products provide value for their end users. Many of them express a kind of process or tool fatigue. They are tired of being told that using a particular process or toolset is the key to their success. To them, value is a more important concept.

It is unfortunate, but not surprising, that the elegant and relatively simple view of SOA has become bloated with a bewildering array of methodologies and products, leading to confusion and bafflement by many of its proponents and potential converts.

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.