In traditional organizations, people know what Business Analysts do: They work with their business partners to understand strategy and goals, and they communicate business requirements to the teams that develop and test software.
The Business Analyst role has long been crucial to delivering high-quality software. It has a well-defined and understood role in any IT project. It was, at least, until Agile methods entered the picture.
The “traditional” Business Analyst doesn’t have a role on a “pure” Agile team. Instead, a Product Owner represents the voice of the customer, creating and prioritizing user stories and collaborating with the development team to deliver software.
So where does a Business Analyst fit as organizations shift toward more Agile approaches?
Agile forces CIOs to rethink the Business Analyst role.
People want well-defined roles with familiar titles. They care about job descriptions. Clear roles align expectations and drive responsibility and accountability within a team.
Consequently, as CIOs embrace Agile, they have to answer some serious questions: Do Business Analysts have a place in Agile? Do they become Product Owners? Do they have the right skills? Is there some hybrid role or does the role simply disappear?
The challenge deepens as CIOs try to expand the use of Agile across the enterprise.
Agile at scale forces them to rethink the Product Owner.
A single Product Owner defining and managing all requirements works well in some companies, like software vendors (where Agile originated) and young companies that lack deeply entrenched, conventional IT roles.
Larger, more traditional enterprises have also found success with a single Product Owner on certain teams and for certain project types, like those with few stakeholders and low levels of technical complexity.
When enterprises try to apply Agile to large, or “at scale,” initiatives, however, Product Owners struggle. A single Product Owner simply can’t manage input from numerous business stakeholders with varying – and often conflicting – viewpoints. Technical complexity and external dependencies complicate matters further. A Product Owner quickly becomes a bottleneck, slowing down delivery.
Enterprise Agile requires a new way of thinking about roles and titles.
To scale Agile, IT leaders must think differently about how Business Analysts and Product Owners participate in the Agile process. They have to let go of traditional assumptions about roles and titles and focus more on skills. And they have to become more flexible and adaptive in shorter timeframes – more “Agile” so to speak.
Here are 7 steps you can take to optimize the use of Business Analysts or Product Owners – or whatever you call the people with the right skills – as you seek to expand and mature Agile across the enterprise:
- Ignore titles and focus on tasks. What tasks do requirements analysts need to perform in an “at scale” Agile initiative? What traditional, cumbersome tasks can they eliminate? What new tasks do they need to take on? Document a comprehensive list of tasks that maintain the necessary level of enterprise control while leveraging the benefits of Agile methods.
- Consider the skills needed. What skills do your requirements analysts need to perform this evolved set of tasks? Do your Business Analysts have those skills? Are they teachable? Do you need to hire experienced Product Owners to gain Agile’s benefits? Most importantly, emphasize the strong communication, collaboration, and analytical skills needed to define and manage requirements on large, complex projects with many stakeholders.
- Match skills to the tasks at hand. Assign people to tasks based on their skills, not their titles. Assign a role name if you must, but roles and titles should not drive your resource assignment decisions.
- Proactively manage bottlenecks. Pull in people with the right skills to address resource constraints that may be slowing delivery. Additionally, look for ways to funnel requirements to the development team without Business Analyst or Product Owner participation. There’s great opportunity for standardization and reuse of many requirements, like the constraints related to security, regulations, and business rules.
- Nurture collaboration. Given Agile’s swift pace, robust collaboration among business and IT stakeholders is critical for business-IT alignment. In large organizations with many stakeholders, however, it’s difficult, because most collaboration is, by necessity, virtual and asynchronous. To support it, promote a culture of open, honest collaboration and build strong communication channels within and between teams.
- Consider tools. We live in a tech-enabled world where people use technology to reinforce and execute processes. Modern requirements tools provide requirements analysts with visualization, analysis, traceability, and reuse capabilities. They simplify requirements review and refinement processes for busy stakeholders. They also integrate with the tools business and development teams use every day, enabling the robust collaboration required in an organization seeking to expand its Agile footprint.
Strong business analysis skills are important in software development, regardless of project characteristics or the methodology used. As initiative size and risk grow, however, they become essential. By leveraging individuals’ skills in a more flexible, continuous way and supporting them with practices and tools, you can realize the benefits of Agile at scale.
