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.

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

• Cross functional knowledge and skill over individual technical expertise,

• Interpersonal/verbal skill over writing and documentation, and

• Goal accomplishment over individual task accomplishment.

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.

                                                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.

Error, missing joomlaboard config file!

Comments (6)

François Beauregard: ... Mike, have a look at www.greenpeppersoftware.com. We are currently looking for feedback on our approach. 1 February 14, 2007 Mike K.: ... I would be very interested in seeing some practical examples of how "...the role of BA and QA merge to the extent that a single mechanism or document is used to express both requirements and tests." 2 February 14, 2007 François Beauregard: ... I really liked your article. Merging BA/QA role has been an interesting area of research for our company. As you mention: "having a single mechanism or document is used to express both requirements and tests" is particularly interesting. If you are interested in learning about our approache, have a look at http://www.greenpeppersoftware.com. Please do not hesitate, feedback is much apprepciated. 3 February 13, 2007 Manikandan Krishnamurthy: ... This is a Good article. I like the idea of Cross-Training (both functional and technical) experts and establishing Team goals rather than individual recognition. There are long-term benefits for everyone and this is better recognition any individual can get. Once experts are cross-trained, Clear management guidance should facilitate the transition of roles between team members. This helps those who feel "who moved my cheese" to settle down quickly. The classic fall-out on team effectiveness happens when management retains the same people in a role for too long, like say an Architect. This is good for individual recognition but kills creativity and innovation among other young team members when Mr.experience does not accept their views. And management seconds him! Well, am not denying the fact we need Mr.experiences in every team but am just saying there should be oppurtunities for everyone to make the team effective. After a few failed attempts, team work disintegrates since everyone loses interest. And management still cannot understand this simple reason is causing them a lot of money, aggravation, ineffective results and unhappy customers. Irrespective of technological advances in this space - call it Agile today and could be Fragile a few years later, companies need to continuous adjustments for such innovative methods to work! 4 November 13, 2006 Sajin Kokkad: ... Hi all, I am working as a SQA person. I am working in an agile project. As stated in this text, I found the agile development method is very useful in producing complex, time critical and low-bug-rate builds. As to work in a agile team, I would recomment - the ability to work in a team - sharing of responsibility, risk, and at the end, success - knowledge in multi domains and technologies As the distance between various functional roles are very low, the ability to understand the system and work as a group is the most important, as I cite. Regards, Sajin Kokkad 5 November 07, 2006 Wayne M.: ... I think Dave has nicely summarized the way that agile development leads to role changes throughout the development organization. There is a transition from a specialized skill per role model to a generalized multiple skills per role model. This leads to some emotional issues that also must be addressed in order to reap benefit from an agile development approach. Typically, there has been a hierarchy with tasks performed early in a waterfall approach being viewed as "better" than those performed late. Business Analysts and Architects were at the top and testers were at the bottom. It is often difficult to convince developers, architects, and analysts that testing is not "beneath" them. It is not that they are necessarily bad people, but the flattening from a hierarchical struture into a team structure can be unsettling, especially if done without proper management guidance. I feel agile development provides an improved model for software development, but the affects of agile development on current organizations is not well understood. Aticles like this one help explain how the social dynamics of an organization also will change. 6 October 16, 2006

Write comment

Name

Comment

Write the displayed characters

Add Comment

Tags:

Click to add your tags...,

or Close