The business analyst (BA) has played a key role in software development. But within a modern agile context, the role of the BA is less clear, and there is some confusion as to whether the product owner role subsumes that of the traditional BA. Let’s look at the roles the BA can play with agile teams and how to fully leverage their expertise to supplement or augment that of the product owner.
Agile software development is no longer about a better way to develop software. Agile is about changing the way digital technologies, products, and services are created to take advantage of enhanced CPU power and the tools that power has made possible. Here's how digitalization is reshaping agile teams, projects, and the very definition of success.
The dream of any product owner is fully customizable production software without the expense of the hardware it rests upon. While not completely free of infrastructure, serverless infrastructure significantly reduces overhead costs by abstracting away physical hosting, physical security, server maintenance, and OS patching. Here's what you need to know to decide if serverless infrastructure is right for you.
The first principle of the Agile Manifesto states, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Early and frequent delivery gets value to customers quickly and helps you figure out whether you understand what your customers really want. Here are five tips for how you can follow the first agile principle and provide customer value continuously.
There are those agilists who believe there is no place for a business analyst on their team. Joy Beatty and James Hulgan, both experienced agile consultants, refute this belief and explain how business analysts can enhance the effectiveness of most any agile team.
If you are considering leaving the nest to self-fund your own endeavor, you may want to read about Mike Botsko's experience creating a cloud-based, bug-tracking app called Snowy Evening. What started out as a lot of fun quickly turned into a tough journey. Don't worry—it has a happy ending!
By emphasizing better communication and collaboration between software development and IT, this article explores ways to establish trust by focusing on customer value. For example, Manoj Khanna suggests continuous integration and validation as techniques that helps build that trust.
Software development teams think nothing about reusing code, but what about requirements? The benefits include faster delivery, lower development costs, consistency across and within applications, fewer defects, and reduced rework.
In this interview, Michael Harris, the president and CEO of David Consulting Group, explains his five-step Value Visualization Framework. He discusses how he came up with the idea, how it can help your team right now, and its similarities to the agile methodology.
In this interview, Rob Sabourin talks about his STAREAST presentations. These cover how to elicit effective usability requirements with storyboarding and task analysis, and how to blend the requirements, design, and test cycles into a tight feedback loop.
In this interview, principal consultant and Agile Artisans founder, Jared Richardson, explains how misunderstanding requirements can cause major issues within an organization. He covers why team members need to communicate, how big projects are often mishandled, and the value of agile.
Diane Zajac-Woodie sat down to discuss her upcoming presentation at Agile Development and Better Software Conference West 2014, why the business analyst role doesn't get the attention it deserves, how the BA role can make a difference on agile teams, and her alter ego as the Agile Squirrel.
In today's competitive market, employers increasingly depend on business analysts to act as change agents. This puts BAs in the powerful position of influencers—providing the analysis and evidence needed to support an organization’s strategic direction and decision-making. In their book...
Are you a business analyst, wondering how you fit into agile projects? Are you a ScrumMaster who wants to work with business analysts for a stronger project team? Are you a product owner who needs to supercharge your product backlog? Mark Layton introduces you to the critical role of the...
During the past ten years, static analysis tools have become a vital part of software development for many organizations. However, the question arises, “Can we quantify the benefits of static analysis?” William Oliver presents the results of a Lawrence Livermore National Laboratory study...
William Oliver, Lawrence Livermore National Laboratory
How often have you gone down the road of developing software almost to completion only to discover new requirements that require significant design and coding changes at the last minute? Requirements analysis is not just writing down what customers say they want. It's about digging down and discovering what they need. Without real analysis, our requirements often end up as poorly defined lists, anemic mock-ups, and incomplete or inconsistent models. Jack Jones spotlights one simple technique to discover these needs: Ask "why?" When the customer states a requirement, ask "why?" to delve down a level to discover their real problem, need, or opportunity. You may find you need to repeat "why?" a number of times. Join Jack to explore the very real consequences of not comprehending customer needs early in the process, and practice better communications techniques to avoid unnecessary requirements and scope changes.