Business Analysis with Agile Software Development

BA with Agile Development.jpg

A Software Development Revolution

On February 11, 2001, 17 software development leaders met at Snowbird Ski Resort in Utah to pioneer an alternative to traditional software development. The heavyweight approaches at the time struggled to keep up with changing requirements. The leaders wanted to give the new approach a more descriptive name than “lightweight” development, agreeing to call it agile software development.

Since then, agile software development has gained wide acceptance, enabling delivery of software that adapts to changing customer needs. Salesforce adopted agile software development in 2006 after they projected new releases taking up to 15 months - too slow for a fast-growing company. You could say Salesforce bet the company on agile, but staying the course was riskier. Agile software development reduced their release cycle to 4 months, enabling three major releases a year. Salesforce has sustained that pace since they adopted agile.

What Does Agile Have to Do with Business Analysis?

The 17 software development leaders wrote an Agile Manifesto with the first principle:

Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.

Sounds great! Then came the fourth principle:

Business people and developers must work together daily throughout the project.

Wait - where does a business analyst fit when business people work directly with developers? The leaders implied that developers would take on the business analyst role, eliminating a layer of communication. They also assumed developers had the skills motivation and capacity to take on the business analyst role. 

Not So Fast

A talented person can take on the business analyst / architect / developer roles in a startup with no customers. As demand for new software capabilities grows, this person focuses on creating and managing a development team, leaving less and less time for business analysis.

While the development manager sets up an agile team who can handle changing requirements, someone in a business analysis role needs to maintain a backlog of requirements. The business analyst organizes the requirements backlog primarily by business value. He or she understands the requirements and accepts that some will come in and out of the backlog on short notice. 

Agile is a Mindset, not a Halo

I have seen “agile business analyst” defined as a business analyst who works with an agile development team. That does not make the business analyst agile. Neither does sprinkling agile buzzwords in conversations with stakeholders.

Agile is a mindset based on fine-grained analysis, collaboration, and value delivery. The business analyst collaborates with business stakeholders to break business requirements into specific user stories and rank them by business value. He or she collaborates with developers and architects to deliver small increments of working software to show the business stakeholders a sample of their solution. Business stakeholders often change the requirements or create new ones based on the sample software demonstration, making the software better fit the business's needs.

A Critical Look at Agile Development

A good business analyst looks at agile software development critically, asking what value it brings to the development process vs. the cost. Agile development delivers better software sooner to business stakeholders willing to invest their attention and energy into the process. These stakeholders need to invest in more frequent and shorter discovery sessions. They also need to review working samples of the software and provide feedback, all the way through acceptance testing. If business stakeholders refuse to make that investment, agile development will not likely work for them.

On the other hand, a business that needs rapid software delivery to keep up with their customer needs can benefit from agile development with the investment of attention and energy from their stakeholders. Agile development requires a good business analyst to mitigate its demands on business stakeholders, quickly showing its benefits. Once stakeholders recognize the benefits of agile development, especially when it saves them time and energy, they will invest more into the process, creating a virtuous cycle that delivers higher value in less time.

A good business analyst optimizes requirements for an agile development team to maximize the value and timeliness of software.

Previous
Previous

Adopting and Improving Agile Development

Next
Next

Accelerated Expectations