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 problems.)  Conversely, towards the end of the iteration, automating the functional tests usually becomes a greater focus. It would not be uncommon for the QA person to call on the BA for help with this. The more flexibility the team members have in adapting to this kind of shifting demand, the more efficient the team will be.

On the best agile teams, the role of BA and QA merge to the extent that a single mechanism or document is used to express both requirements and tests. This means that customer team members (including the PM) need to be skilled both at requirements elicitation and testing. BAs must get better at learning how to think of tests for requirements, and QA testers must learn how to work with business owners who may not clearly understand exactly what they want. People in both roles need to develop strong interpersonal skills and enough technical understanding to be proficient with testing tools. Such a cross-functional individual, experienced in all facets of the development process, becomes the most valuable person on the agile team.

Project Visibility Enables PM Focus on Business Partnership
The role of the project manager also changes as a member of the customer team. A good agile project has mechanisms in place to provide instant visibility to all stakeholders. Walls are typically filled with project information including the backlog of features or stories, the status of current work, measures of work progress/velocity, and technical design artifacts. All of these artifacts are updated daily so that business owners, executives, and developer can each immediately assess the state of the project.

With the task of communicating and process management greatly simplified, the PM can shift her focus to business partnership and clearing roadblocks - higher value activities. While the PM retains many of the same job functions, the amount of time spent on different tasks changes greatly (see Figure 1). A PM on a well-functioning agile team can devote most of her time to fostering an environment that supports collaborating with the business and clearing roadblocks.

dm1006-2small

     Figure 1: Changing Project Manager Role         source: Digital Focus

Being the business partner also requires the PM to become adept at truly understanding business objectives and translating them to technical requirements. The PM's value is based upon her creativity in being able to solve such challenges. The continuous planning practices of agile development reinforce this focus on the business. As iterations are defined and developed, the team spends less time on scope management, resource management, and team management. Instead, the customer team, and in particular the PM, constantly evaluates current progress against the business's goals and objectives. Those tasks that add business value are pursued and those that do not are dropped by the team. For the PM, the key success criterion is the team's effectiveness at building a trusting partnership with the business owner.

Conclusion
For agile to truly succeed, everyone on the customer team needs to be able to perform all aspects of each role. The critical success factors for each person change to be their ability to work in a teaming environment.  Specifically, individuals need to:

  • Become cross functional experts,
  • Build their interpersonal skills, and
  • Focus on team goals versus individual recognition.

These changes in the responsibilities of PM, QA, and BA are significant and are often not understood by organizations attempting to transition to agile development. Both skills and incentives need to change. The ability to work in a team environment, collaborate with others, and perform multiple kinds of tasks become the most important aspects of individual performance. Agile development also necessitates a much stronger focus on business understanding and creativity. Until an organization alters its recruiting, training, and reward structures to reflect this shift, it will have a difficult time embracing the benefits of agile development.


[1] See the Agile Alliance, www.agilealliance.org, for the industry-accepted principles of Agile development.


About the Author: Dave leads the agile practice for Digital Focus.  Dave brings over 15 years of experience in organizational change management and project management. For the last 4 years, Dave has served as an agile coach and change leader in helping Digital Focus and our clients adopt agile practices. Dave specializes in helping client leadership adopt a different way of thinking about IT, focusing on delivering continuous value by working in short cycles that maximize ROI.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.