Agile Vs Traditional Roles


Published on

Have you wondered how different your role would be if you were adopting Agile and Scrum methods in your organization? 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 being part of an Agile team. We will explore the following 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
6. Architect vs. Agile Architect
7. Resource Manager vs. Agile Resource Manager
Want this seminar presented at YOUR organization? just email

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The duties above can generally apply to QA or User testers. If you do have QA testers on the project then they may have the following additional duties: Develop automated user testing scripts for each story. Run daily or nightly automated regression testing scripts to ensure the overall health of the system is stable. Perform ‘Smoke Testing’ for key stories to ensure all is well when automated regression testing is not feasible. Work ahead of the next iteration to setup test data. Develop easy to understand visual reports or daily emails of the current testing state of things. Results driven, quality focused, good communicator of issues, detailed and organized, flexible, business value driven, uses automation to maximize efficiency, knowledgeable of testing methods and tools. All these are qualities of a strong Agile tester.
  • The developer should also raise issues or impediments as soon as they encounter them. They can let the team know they want to work on the issue first, but at least make the team aware of it.They know how to communicate openly and ask questions of the business. They openly communicate any technical concerns or issues they have so they can be addressed.They aim for 0 bugs and are proud when they achieve this on a story!  The adhere to standards like creating unit tests, passing code review, using TDD and ask for help when they are not familiar with How to do something.
  • The architect needs to be business driven. Instead of only focusing on technical designs and solutions, they really need to work closely with the product owner to understand their needs and design a solution that fits that need. For example, no need to develop a complex architecture built to support the next 10 years of changes if that is not the product owner’s or sponsor’s requirement. Balance simplicity and flexibility. Try to find simple yet powerful solutions instead of extravagant ones that are hard to maintain by the organization. Educate the team, be their coach, help them understand the technical vision so they can apply these principles each day. If you are an architect who wants to learn more about the Agile Architect role, you MUST visit this site:
  • Agile Vs Traditional Roles

    1. 1. Comparing Agile vs. Traditional Roles Presenter: Sally Elatta 1
    2. 2. • Explore and contrast the Agile vs. Traditional Roles and discuss new skills needed. • We will explore the following roles: - Sponsor vs. Product Owner - Project Manager vs. ScrumMaster - BA vs. Agile BA - Tester vs. Agile Tester - Developer vs. Agile Developer - Architect vs. Agile Architect - Resource Manager vs. Agile Resource Manager • Complete survey and receive the full Agile Roles and Responsibilities handout! 2 Copyright(c) Sally Elatta 2009
    3. 3. About the Speaker • Sally Elatta • Founder of • Enterprise Process Improvement Coach, Architect, Trainer • Coached over 18 teams on adopting more Agile methods. • Taught over 600+ students • Certified ScrumMaster, Scrum Practitioner, IBM, Sun, and Microsoft Certifications. • • 402 212-3211 3 Copyright(c) Sally Elatta 2009
    4. 4. Sample Team Structures Committed Interested 4 Copyright(c) Sally Elatta 2009
    5. 5. Traditional Sponsor and Business Stakeholder  Projects may 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.  Often, there is no one decision maker.  Engaged at the front 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. (Red, Green) Copyright(c) Sally Elatta 2009 6
    6. 6. Who is the Product Owner?  1 Person in charge of the backlog!  Prioritizes the backlog stories for highest ROI. Product  Most likely from the business. Has the most Backlog to loose/gain from project outcome.  Accepts or rejects work completed.  Knowledgeable, Empowered, Engaged  Only one who can add or remove stories from the backlog.  Assigns knowledgeable users and SMEs to the project team.  The Captain of the Ship! Owns final success or failure of project. 7 7 Copyright(c) Sally Elatta 2009
    7. 7. Traditional Project Manager • Manages the project through developing detailed project plans upfront at the task level. • Heavy use of project management tools. • Heavy upfront planning, may engage key SMEs and resource managers for estimates or provide ones themselves. • Manages tasks, holds weekly status meetings and may visit team members at desk to find out where everyone is at. • Takes care of addressing any major team issues. Copyright(c) Sally Elatta 2009 8
    8. 8. Traditional Project Manager .. • Spends a lot of time using tools and developing reports to management and business folks. • Maybe managing several (possibly 7) projects at a time. • Accountable for project success and failure. • May use Command and Control to tell team what to work on next and when to get it done by. • May be involved in the daily decision making related to the requirements, architecture and other aspects of the project. • More experience with Waterfall development as apposed to Iterative development. • May hold PMBOK certification. Copyright(c) Sally Elatta 2009 9
    9. 9. The ScrumMaster • Is a ‘Leader’ of the team who creates a culture of high collaboration, team empowerment, and high visibility and accountability. Orchestrates and owns the ‘Process’. • Engages the product owner and business SMEs upfront to develop the project 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 iteration. • Interested in measuring and tracking Stories getting to ‘Done’ state. Does this by monitoring daily Tasks and removing daily impediments. • Holds daily 15 minutes standup meeting with all team members involved including the business. 10 Copyright(c) Sally Elatta 2009
    10. 10. The ScrumMaster .. • 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. Business value driven. • Measures and reports progress frequently using easy to understand earned value charts. Brings high visibility into the team’s progress. • May hold PMBOK certification in addition to a ScrumMaster certification. Copyright(c) Sally Elatta 2009 11
    11. 11. 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 apposed 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. Copyright(c) Sally Elatta 2009 12
    12. 12. 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. • They will make sure that all scope changes have been appropriately captured and documented on the backlog.
    13. 13. The Agile BA .. • During the iteration, the BA works on making sure the requirements and test cases are understood by developers for all stories. (Not just documented well!) • 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. • A strong BA is usually the ScrumMaster’s right hand person and the team’s ‘Glue’ that holds everything together! Copyright(c) Sally Elatta 2009 14
    14. 14. 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. Copyright(c) Sally Elatta 2009 15
    15. 15. 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. • User automated testing whenever feasible. • User acceptance testers are responsible for helping the product owner develop the list of User Acceptance Tests for stories schedule in the next iteration. • 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.
    16. 16. 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 write automated unit tests for each method. • 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. Copyright(c) Sally Elatta 2009 17
    17. 17. 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.
    18. 18. The Agile Developer .. • 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. Copyright(c) Sally Elatta 2009 19
    19. 19. The Agile Architect • An Agile Architect is driven to deliver business value. • Instead of only being driven to use elaborate designs, new patterns and technologies, they work closely with the product owner to understand their needs and design a solution that fits that need. • They balance simplicity and flexibility. Try to find simple yet powerful solutions instead of extravagant ones that are hard to maintain by the organization. • They educate the team, be their coach, help them understand the technical vision so they can apply these principles each day. • They aim to mitigate risk during early iterations by identifying proof concept stories or dedicate specific ‘spike’ iterations for this purpose. Copyright(c) Sally Elaotta 2009 20
    20. 20. The Agile Architect • During the iteration, the architect needs to make sure the team has a good idea of the technical designs and approach to be used. They may setup a short design meeting after the iteration planning meeting day. • If the team has a tech lead then the architect works closely with that person before and during the iteration to clarify any ambiguity. • They also need to insure the team is adopting daily practices that align with organization goals. • Be available, not necessarily at every standup, but when needed. • Be a servant leader, not a dictator. Coach the team on Why we do what we do, not just tell them what to do.
    21. 21. Resource Managers • Manage resources assignment and allocation to each project. • Develop and support resources by providing the right tools, training and coaching when needed. • Assign the right folks to the projects based on skills needed and urgency. • May play a gatekeeper role for their team by being the one who assigns work to them and interfaces with the project. • Develop standard processes to be followed in that area. Develop policies and guidelines that ensure consistent and quality delivery. • May be a SME in the area and make technical decisions on projects. Copyright(c) Sally Elatta 2009 22
    22. 22. The Agile Resource Manager • Similar to the traditional with these differences: – Is not involved in tasking of individuals. Their resources are members of a team managed by the Project Manager. – Is a key partner to the ScrumMaster for removing impediments. Must have a high sense of urgency. – Uses Servant Leadership instead of command and control. – Engages when needed, does not interfere with project and empowers their team to collaborate with other cross functional team members. – Reduces resource shuffling and multi-tasking. Key role is to provide resource stability. Copyright(c) Sally Elatta 2009 23
    23. 23. New Skills Are Needed! • IT:  Effective Facilitation and Agile Requirements Gathering with ‘Just Enough’ Documentation  Leadership, Teamwork and Collaboration.  Ability to breakdown stories into small manageable tasks.  Ability to focus on getting stories completed with low/no bugs by incorporating Test Driven Development.  Ability to work and collaborate within the IT department (cross functional).  Communication, synchronization between multiple teams.  Foucs more on business value (ROI) than technical implementation. (Cool Cost Me Money!) 24 Copyright(c) Sally Elatta 2009
    24. 24. New Skills Are Needed! • Business:  Leadership, Teamwork and Collaboration  Ability to define stories and user test cases  Ability to perform acceptance testing  Ability to truly prioritize what is needed now and what provides value. Understand ROI  Better understanding of the technical world  Time management and commitment.  Support and stay positive 25 Copyright(c) Sally Elatta 2009
    25. 25. Training & Coaching Training Coaching & Consulting •Mastering the Art of • Project Management Facilitation Skills Assessments •Effective Requirements • Troubled Project Gathering Assessment & • Servant Leadership Recovery • Real World Agile and • Agile Project Initiation Scrum team training + and Planning Project Jump Start • End to End Project • Executive and Business Execution Overview of Agile/Lean • Process Improvement • … More! Roadmap Execution
    26. 26. 27 Copyright(c) Sally Elatta 2009 27
    27. 27. • My Article: • FAQ: • Read this Scrum in 5 Minutes article: • Watch the 10 minute video intro to Scrum: 28