How Agile Changes the Role of Project Managers, Business Analysts, and Testers

[article]
Summary:
On a recent engagement, my company walked into an organization that was struggling to adopt agile software development practices. There was clearly energy and willingness on the part of the development team to try new practices. However, the confusion around new responsibilities of the project manager (PM), business analyst (BA), and quality assurance tester (QA) was preventing progress.

On a recent engagement, my company walked into an organization that was struggling to adopt agile software development practices. There was clearly energy and willingness on the part of the development team to try new practices. However, the confusion around new responsibilities of the project manager (PM), business analyst (BA), and quality assurance tester (QA) was preventing progress. While the developers and architects were being challenged to adopt some different practices, the main responsibilities of their "roles" remained the same–to design, code, and unit test. In contrast, the responsibilities of the PM, BA, and QA were undergoing change that was in conflict with the organization's traditional expectations. The training, skill development, and management structure were not aligned to the new demands of supporting an agile development process. This article discusses how the roles of PM, BA, and QA change with agile development, and the implications that shift has for people and organizations.

Traditional Phase-Based Software Development
In traditional phased-based or waterfall projects, the roles of the BA, QA, and PM are clearly defined and delineated. The BA collaborates with the application's business owner to capture and document the detailed requirements. The QA tester develops test plans and writes tests cases to verify that the requirements are implemented correctly. Meanwhile, the PM focuses on tracking progress against the project plan, documenting and managing the project risks, controlling scope/change so that the team has a reasonable chance of delivering on-time and within budget, and communicating the overall status of the project to the rest of the organization. While some collaboration is obviously necessary, each of these roles can be seen as having distinct responsibilities within the development team.

This emphasis on specific roles in traditional software development usually drives people to work independently. Individuals have the incentive to develop expertise only within their specific niche. Different metrics are typically captured for each role, and teamwork and interpersonal skills are often de-valued.

Roles on an Agile Project
On an agile {sidebar id=1} project, the roles of PM, BA, and QA (together with the business owner) form the customer team . The concept of a team is important as it directly supports the key values underlying agile development: "individuals and interactions over processes and tools" and "customer collaboration over contract negotiation." [1] As a customer team, its focus shifts from individuals and individual task completion by role to how well everyone can work together to translate business needs into a testable/verifiable working piece of software.

This is a critical distinction. In this style of working the primary skill that is needed is the ability for an individual to work within a team. Effective teamwork requires each individual team member to work on the critical path tasks. For example, if requirements definition is the current critical path item, everyone on the customer team needs to have the skills necessary to do the job. What we value most in members of the customer team are:

  • Cross functional knowledge and skill over individual technical expertise,
  • Interpersonal/verbal skill over writing and documentation, and
  • Goal accomplishment over individual task accomplishment.

Example: BA/QA Roles Merge
As an example of how responsibilities on an agile team blur the distinction between traditional roles, consider how a BA and a QA resource work together during an agile iteration. In the first few days of an iteration, requirements definition is typically more intense. The QA resource will collaborate heavily with the BA to understand and document the detailed requirements on the user stories being built. (Indeed, QA people are often the best at understanding the "edge cases" where a given feature is likely to cause

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09