1. Navigating an Agile Transformation
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Agile, loosely defined, is the “ability to move and think quickly and easily” or “to move in a quick, coordinated fashion”
Customer collaboration over contract negotiation
Responding to change over following a plan
Navigating an Agile Transformation
Beth Taylor, PMP, MBA
July 18, 2017

2. Why Change?

3. From the Symposium...
cultural change

4. Agile – Values, principles guiding self- organizing, collaborative teams supporting products over projects
An alternative to traditional project management
Scrum – team framework, how the team works
Ceremonies – 4 formal events for inspection and adaptation: Planning, Daily Scrum, Review, Retrospective
Kanban – method to visualize workflow
Scrumban – Best of Scrum and Kanban
Kaizen – Continuous Improvement
Sprints - time boxed work completion
Stories – small, concrete deliverables to complete a feature
SAFe – Scaled Agile Framework for enterprise
Velocity – measuring how much work can be completed in a sprint
Terminology
Agile
Scrum
Kanban
Scrumban
Kaizen
Sprints
Stories
SAFe
Velocity

5. Scrum Master:
Manages the process for how information is exchanged, helping teams self-organize and be “Agile”
Product Owner:
Content authority for the team, responsible for backlog, prioritizing, accepting stories and representing the business
Roles
Scrum Master
Product Owner
Team
Team:
An Agile team includes a Dev Team of developers, testers, BA’s who deliver functionality; along with Scrum Master and Product Owner

6. Scrum

7. Kanban
Japanese for “visual signal” or “card”; initially used in to facilitate JIT manufacturing - matching inventory with demand or to pull, not push
Visualize Work
Limit Work in Process
Focus on Flow
Continuous Improvement (Kaizen)
bottlenecks are apparent

8. Scrumban
Scrumban is a management framework where teams employ Scrum as their chosen way of working and Kanban as the method to view, understand and continuously improve how they work
Scrum – Teams organized sprints, stories, estimated effort, retrospectives
Kanban – Visualize work; WIP limits based on team velocity (rate at which teams can deliver – not a contest!)
Scrum
Scrumban
Kanban

9. Scrumban
The process...
Visualizing the work...

10. Or “How Fragile is your Agile?”
Organizational Resistance
Need top down buy-in and support, bottom up training and acceptance
Unstructured Agile implementation
Forgetting Project Management Good Practices
Vision, complexity, risk, budget and teams are still the same!
Using Agile when project is unsuitable
Best for fluid requirements, aggressive timelines
Not following Agile principles
Terminology only
Reducing governance and oversight
Requires more executive involvement
Bypassing change management processes
Product owners cannot bypass the process
Break in flow of requirements
Poor or non-existent forecasting
SAFe Program Increment planning
Pitfalls
Or “How Fragile is your Agile?”
PMO not trained; hiring expertise and not taking it,

11. Other Obstacles What makes Agile fail?
Team dynamics – lack of participation, going off course
Insufficient training, coaching
Insufficient resources
Undefined acceptance criteria
Teams over or under committing to work
Priority shifts (change management)
Bottlenecks
What makes Agile fail?
Overly political cultures and lack of trust
Command and control leadership
Micromanagement
Lack of Empowerment

12. Challenges for Project Manager as Scrum Master
There is no role for a Project Manager on a Scrum team; yet the project is still a time boxed, temporary endeavor with progressive elaboration of a unique product or service
Both roles need to coexist – Project Managers manage teams, Agile teams are self-managed
Project Managers are responsible for outcome of the project; the Scrum Masters role is the authority over the process
Project Managers own communication, scheduling, risk and budget, the Product Owner is responsible for product costs and burn rate, the Scrum Master does not have ownership of these

13. PM’s as Scrum Master
Scrum ceremonies should not be conducted as status review meetings
There is no concept of percentage complete in Agile
Acceptance criteria verses detailed business requirements
No changes within a sprint – backlog or sprint termination
Teams are self managed, not task driven
Agile work should not be DATE driven
Project Managers need to be adaptable!

14. New Endeavor... Scrum Master: Will manage process for 2 solution teams
Product Owner:
Truly the business owner, empowered to make decisions, prioritizes
New Endeavor...
IT Lead:
To make decisions on design, integrations and direction
Enterprise Systems - 3
Vendor Project
Configuration
Moving from Development Support to Business Support
Collaborative IT & Business Effort
Enterprise support and changes in SAFe organization
Vendor uses Waterfall approach
Team:
Agile teams including Developers, SME’s from IT & Business, BSA’s, Testers, SM & PO
Release Train Engineer:
(Program/Project Manager) Manages Agile Release Train within Value Streams

15. Bridge from PMI to Agile
PMBOK 6th edition release estimated
Sept 2017
Will contain numerous references to adaptive and iterative practices including agile
Each knowledge area will have a section for Agile Approaches, Iterative and Adaptive Environments
Bridge from PMI to Agile
PMI-ACP formally recognizes knowledge of Agile principles and skill with Agile techniques

16. citations http://agilemanifesto.org www.scrumalliance.org
14.pdf
PMICAC Symposium: An Agile Transformation / Culture Shifts, Mechanics, and PMO