Published on March 1, 2014
Traditional Roles vs. Agile Roles
Agenda Compare the Traditional Roles vs. Agile Roles 1. Sponsor vs. Product Owner 2. Project Manager vs. ScrumMaster 3. BA vs. Agile BA 4. Tester vs. Agile Tester 5. Developer vs. Agile Developer 2
Agile Team Structure 3
Traditional Sponsor Projects have one sponsor, usually higher in the organization chart, funds the project but is not involved in the details. Multiple business stakeholders are involved to provide input and requirements. No one decision maker. Engaged at the start of the project and then towards the end during testing. Usually receive weekly status reports from PM on how the project is doing and if any issues need their attention. 4
Product Owner Person in charge of the product backlog i.e. requirements. Prioritizes the backlog stories based on business value. Most likely from the business. Accepts or rejects work completed. Knowledgeable, Empowered and Engaged. Only one who can add or remove stories from the backlog. Owns final success or failure of project. 5
Traditional Project Manager Manages the project through developing detailed project plans upfront at the task level. Heavy upfront planning, may engage key SMEs for estimates or provide ones themselves. Manages tasks, holds weekly status meetings. Takes care of addressing any major team issues. Maybe managing several projects at a time. Accountable for project success and failure. May use Command and Control to tell team what to work on next and by when to get it done. 6
The ScrumMaster Is a ‘Leader’ of the team who creates a culture of high collaboration, team empowerment, and high visibility and accountability. Owns the ‘Process’. Engages the product owner and business SMEs upfront to develop the product backlog. Holds product owner accountable for owning the backlog. Is knowledgeable on Agile Requirements Gathering methods and Story identification, breakdown and estimation techniques. Very light use of project management tools. Spends most of their time with the team and removing impediments. Heavy initial release planning then continuously engages team to update the plan each sprint. Holds daily 15 minutes standup meeting with all team members involved including the product owner. 7
The ScrumMaster…cont’d May manage only one large project or a couple of smaller projects at one time. Is not accountable for project success and failure. Uses a Servant Leader style for leading the team. This results in self organizing, empowered and accountable teams. Empowers the committed team members from Business and IT to make decisions. Does not make business or technical decisions on behalf of them. Understands and has experience with iterative delivery of projects with focus on Business value. Measures and reports progress frequently using easy to understand burn down charts. May hold Certified ScrumMaster certification. 8
Traditional Business Analyst Analyze business need to help identify business problems and proposed solutions. Acts as liaison between the business and IT. Will meet with various stakeholders at the beginning of a project to elicit requirements in detail. May use Use Case specifications or other type of documentation to capture all requirements. May require business to sign off on requirements upfront on a project. Probably trained on upfront detailed requirements gathering as opposed to iterative requirements elaboration. Collaborates on the project heavily upfront then again during testing to validate requirements were met and possibly during development to clarify ambiguity. 9
The Agile BA The BA/SA is the owner of requirements documentation and elicitation. They are a master of Agile Requirements Gathering and know how to break down stories into small valuable chunks. Understand how to capture stories, user test cases, business rules, process diagrams, UI prototypes and other artifacts. An Agile BA engages the business SMEs and product owner with the team instead of acting as a liaison/middleman to the business. They manage the backlog of stories by adding, removing, updating stories there (after Product Owner approval) and keeping it up to date. They will schedule and facilitate requirements elicitation sessions and make sure the right SMEs are invited. 10
The Agile BA…cont’d They will make sure that all scope changes have been appropriately captured and documented on the backlog. During the iteration, the BA works on making sure the requirements and acceptance criteria are understood by developers for all stories. They are very effective Facilitators and know how to bring the team to their goals from any session. They work ahead with the product owner to define stories and test cases for the next iteration. The work closely with testers (IT or business) to track testing progress. Use light weight, easy to read, and accessible documentation. They make sure the right individuals are using the artifacts produced. 11
Traditional Tester The testing group is usually engaged towards the end of the project. This group may require upfront complete documentation on requirements in order for them to develop test cases. Work closely with the BAs to clarify missing requirements. Use of issue tracking tools to log bugs and get them assigned to developers in addition to tracking their status. May use heavy weight testing tools to document and manage all test cases and track progress on each one. May use automated testing and load testing tools. Traditionally they have final say on if the software is ready to be tested by the customer or move into production. 12
The Agile Tester Engaged early during the project, part of the core team. Could be a business user tester or a QA test engineer or have both. Uses automated testing whenever feasible. QA test engineers work ahead of the next iteration to help setup test data, help identify additional test cases needed. During each iteration QA testers work closely with developers to know when stories are ready for their initial testing. They perform testing, log and track issues and provide feedback to developers. They keep track of where each story is at in terms of testing and how close it is to ‘Done’ and may send out daily emails with progress. They collaborate with the team daily during the 15 minute standup. 13
Traditional Developer Engaged on the project after planning has been completed and the project is ready for development. Is expected to read the documentation on requirements to understand what the software needs to do. Goes through BA for additional questions. Works of the upfront designs produced by the architect. Does not usually have access or care about test cases. Driven more by requirements documented by BA. May or may not be aware and follow company coding standards and architecture best practices. Mostly works independently. May get assigned tasks from PM with specific due dates. Mostly works vertically focusing on ‘Front end’ ‘Business logic’ ‘Data logic’ areas instead of horizontally focusing on each business story. 14
The Agile Developer Engaged from the beginning of the project. Helps story sizing, dependency identification and initial release planning. During each iteration, the developer is working on understanding requirements and using Test Driven Development as a method of implementing them. They create automated unit tests for each test cases and may use mock data when real data is not readily available or to reduce dependencies. They frequently check in their code and aim for continuous integration. They must focus on one story at a time and work Horizontally instead of the typical Vertical way we worked in waterfall. 15
The Agile Developer…cont’d They follow the company’s coding standards and recommended designs. They work closely with the user on testing each story as it passes a few test cases or become ‘Done’. They raise issues and impediments daily and only work on the most valuable stories and tasks. They are engaged, flexible, collaborative, quality driven and focused on the iteration goal. 16
Thank You! Prepared by: Sumit Mahajan 17
Agile Roles vs. Traditional Copyright© Agile Transformation Inc. About Me ... Copyright© Agile Transformation Inc. Traditional Developer
Comparing Agile vs Traditional Roles ... Agile vs. Traditional Roles in addition to outlining the new skills needed for being part of an Agile ...
Many organizations, which have embarked on the Agile adoption path, have to tackle the challenge of mapping traditional software development roles to the ...
The goal of this seminar is to explore and contrast the Agile vs. Traditional Roles and Responsibilities in addition to outlining the new skills needed for ...
Traditional SDLC Vs Scrum Methodology – A Comparative ... SCRUM Roles, Meetings, Artifacts ... Comparison between Traditional (Waterfall) and SCRUM (Agile)
There are several key differences between the agile approach to team organization and the traditional approach. Agile teams are "whole teams".
Agile, in product development terms, is a description for project management methods that focus on people, communications, the product, and flexibility.
Each of the Agile methods includes defined roles which is good because people need to know what their role is and the roles of their peers.