Agile Vs Traditional Roles

1

Presenter: Sally Elatta

Comparing Agile vs. Traditional Roles

Copyright(c) Sally Elatta 2009

• 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

About the Speaker

• Sally Elatta• Founder of AgileTransformation.com

• 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.

• [email protected]

• 402 212-3211

Copyright(c) Sally Elatta 2009 www.AgileTransformation.com3

mailto:[email protected]

4

Sample Team Structures


Committed

Interested

Copyright(c) Sally Elatta 2009 6

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)

77

Who is the Product Owner?

1 Person in charge of the backlog! Prioritizes the backlog stories for highest ROI. Most likely from the business. Has the most

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.

Product Backlog



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.


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.

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.


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.


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.

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.

Copyright(c) Sally Elatta 2009 www.AgileTransformation.com 14

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!


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.

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.


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.

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.


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.

20

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

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.

http://www.agilearchitect.org/


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.


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.

24

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!)Copyright(c) Sally Elatta 2009

25

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


Training & Coaching

Training• Mastering the Art of

Facilitation • Effective Requirements

Gathering• Servant Leadership•

Real World Agile and Scrum team training + Project Jump Start

• Executive and Business Overview of Agile/Lean

• … More!

Coaching & Consulting• Project Management

Skills Assessments• Troubled Project

Assessment & Recovery

• Agile Project Initiation and Planning

• End to End Project Execution

• Process Improvement Roadmap Execution

WWW.AGILETRANSFORMATION.COM

http://agiletransformation.com/index.php/training/agile-training/mastering-the-art-of-facilitation/

http://agiletransformation.com/index.php/training/agile-training/mastering-the-art-of-facilitation/

http://agiletransformation.com/index.php/training/agile-training/effective-requirements-gathering/

http://agiletransformation.com/index.php/training/agile-training/effective-requirements-gathering/

http://agiletransformation.com/index.php/training/agile-training/becoming-a-servant-leader/

http://agiletransformation.com/index.php/training/agile-training/real-world-agile-and-scrum/



THANK YOU FOR ATTENDING!

Copyright(c) Sally Elatta 2009 www.AgileTransformation.com 272727

PLEASE COMPLETE YOUR EVALUATIONS

28

• My Article: http://tinyurl.com/6h5mam • FAQ:

http://agiletransformation.com/index.php/faq/

• Read this Scrum in 5 Minutes article: http://tinyurl.com/ob76kc

• Watch the 10 minute video intro to Scrum: http://tinyurl.com/5py7ct

http://tinyurl.com/6h5mam

http://tinyurl.com/6h5mam




http://tinyurl.com/ob76kc

http://tinyurl.com/ob76kc