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 sally@agiletransformation.com

1. Comparing Agile vs.
Traditional Roles
Presenter: Sally Elatta
1

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. 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.
• Sally@AgileTransformation.com
• 402 212-3211
3
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com

4. Sample Team Structures
Committed
Interested
4
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)
Copyright(c) Sally Elatta 2009 6

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

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

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

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

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

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

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

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!
Copyright(c) Sally Elatta 2009 www.AgileTransformation.com 14

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

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

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

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

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

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 20

21. 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/

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

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

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

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

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

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
28