This document provides an overview of agile project management practices for traditional project managers. It discusses how the context for management has changed in an age of accelerating change, rendering traditional management tools and mindsets less effective. Agile principles emphasize problem-solution co-evolution, solution co-creation, and simplicity. Common agile practices like iterations in sprints and emphasis on working software aim to increase learning and reduce the cost of change. The roles of product owner, scrum master, and self-organizing teams are described. Information radiators like burn-up charts and team boards promote transparency.
3. Today’s focus
• Digital Product delivery effort (software development/evolution)
• Single team
Today focus is not on:
• Non-IT projects
• Multi-Team effort
• Programme
• Portfolio
5. HISTORY OF TRADITIONAL MANAGEMENT
Main traditional management tools invented before 1920
from people born around 1850
during the second industrial revolution
6. HISTORICAL CONTEXT OF TRADITIONAL MANGEMENT
• Workforce: mainly unschooled, illiterate
• Companies, functions, requirements: Loosely connected, mostly independent
• Info to process: Moderate amount, no time-pressure to process it
• Rate of change: Slow, with minor consequences
• Uncertainty/Unknowns: High degree of certainty, very few unknowns
7. MANAGEMENT CONTEXT IN
THE AGE OF ACCELERATING CHANGE
• Workforce: Unschooled, illiterate
Well trained, motivated knowledge-workers
• Companies, departments, requirements: Loosely connected, mostly independent
Highly connected, inter-dependent, with frequent interactions
• Info to process: Moderate amount, moderate time pressure to process it
Large amount, insufficient time to process it, ambiguity
• Rate of change: Slow, with minor consequences
Fast, with unpredictable consequences and limited control
• Uncertainty/Unknowns: High degree of certainty, very few unknowns
High degree of uncertainty, many unknowns, diminished capacity to predict
8. IMPACT OF TRADITIONAL MANGEMENT’S TOOLS
IN THE AGE OF ACCELERATING CHANGE
• Defined, all-inclusive, prescriptive processes
→Separation of Thinkers vs Doers, Heavy-weight slow blind processes
• Capital budgeting
→Up-front planning, slow/late reaction-time, rigidity or chaos
• Task Design
→Outcome/end-goal fragmentation, loss of meaning and feedback
9. • Divisionalisation
→ Ineffective cross-function collaboration, late integration, defects, re-work, delays
• Pay for performance
→Teamwork and collaboration discouraged, bad news ceiling / watermelon reporting
IMPACT OF TRADITIONAL MANGEMENT’S TOOLS
IN THE AGE OF ACCELERATING CHANGE
10. ELEMENTS OF TRADITIONAL MANAGEMENT
MINDSET
Unschooled, illiterate
workforce
If you are smart enough,
experienced enough,
and work hard enough,
you can plan everything upfront
11. ELEMENTS OF TRADITIONAL MANAGEMENT
MINDSET
Unschooled, illiterate
workforce
If you are smart enough,
experienced enough,
and work hard enough,
you can plan everything upfront
The tyranny of the
omniscient designer
Thinkers Vs Doers
13. ELEMENTS OF THE AGILE MINDSET
Video Link: https://youtu.be/y885_5tE170
14. The understanding of the
problem and the discovery
of a solution gradually
evolve together, in concert.
ELEMENTS OF THE AGILE MINDSET
Well trained, motivated
knowledge-workers,
and problems that require
multiple points of view
15. The understanding of the
problem and the discovery
of a solution gradually
evolve together, in concert.
ELEMENTS OF THE AGILE MINDSET
Well trained, motivated
knowledge-workers,
and problems that require
multiple points of view
Thinkers Vs Doers
The tyranny of the
omniscient designer
Co-evolution
Co-creation
16. PMI: embracing adaptive management
Source: Improving Performance: The PMI/IEEE Computer Society Software Development Extension, 2013
Modern PM
Knowledge-work
Traditional PM
Task-work
User Story
Product Backlog
Co-evolution
Product Owner
Backlog refinement
Sprint Review
Co-creation
18. AGILE AS UMBRELLA TERM
Scrum Kanban
Extreme Programming (XP) Lean Software Development
Crystal Clear Dynamic Systems Development Method (DSDM)
Adaptive Software Development Feature Driven Development (FDD)
19. THE AGILE MANIFESTO
OF SOFTWARE DEVELOPMENT
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
www.agilemanifesto.org
20. LEAN SOFTWARE DEVELOPMENT PRINCIPLES
1. Energise Teams Members
2. Enhance Learning
3. Deliver as Fast as Possible
4. Decide as Late as Possible
5. Optimize the whole
6. Build quality in
7. Eliminate waste
22. AGILITY DEFINITION (Complexity Science)
Agility is:
- a new way of thinking about and preparing for the unanticipated
- the ability to successfully effect, cope with, and exploit changes in
circumstances.
Meta-Agility is:
- the ability to recognise the approach appropriate for the
circumstances, and to transition in a timely manner to this approach.
23. AGILITY PILLARS (Social Complexity)
1) PROBLEM-SOLUTION CO-EVOLUTION
PROBLEM SPACE
SOLUTION SPACE
25. AGILITY (Social Complexity)
1) PROBLEM-SOLUTION CO-EVOLUTION
2) SOLUTION CO-CREATION
- HOLISTIC END-TO-END APPROACH -
Busines
s
Product
Vision
Requirements
Specification
Design
& Dev
Test
PROBLEM SPACE
SOLUTION SPACE
29. AGILE PROD DEV PRACTICES - GOALS
A. Increase the speed of learning
B. Reduce the cost of change
C. Make decisions and mistakes easy, fast, and cheap to reverse
30. AGILE PROD DEV PRACTICES – IRREVERSIBILITY
Video Link: https://youtu.be/EufUAres_-o
31. AGILE PROD DEV PRACTICES – IRREVERSIBILITY
Irreversibility is
one of the prime drivers of complexity
and so of costs & risks.
Professor of Economics and Management Enrico Zaninotto, 2002
Quoted by Kent Beck & Martin Fowler
32. AGILE PROD DEV PRACTICES - GUIDELINES
1. Search specific solutions (not general)
2. Search local solutions (not global)
3. Start simple (not all-inclusive)
4. Be just-good-enough just-in-time (not perfect upfront)
5. Focus on one thing at the time (no multi-tasking)
6. If something is hard, do it more often (not less often)
34. DIFFERENT ”INCEPTIONS”
• ThoughtWorks (Agile) Inception (about 1÷4 weeks, 1 week x 3 months delivery)
• ThoughtWorks Lean Inception (1 week)
• Google Design Sprint (1 week)
• No Inceptions
• Lean Value Tree
• Directly into Scrum Sprint Planning (2 hours x 1 week of work)
35. WHAT IS AN AGILE/LEAN INCEPTON
THERE IS AN INNOVATIVE
IDEA WORTH PURSUING
(OR A PROBLEM
WORTH SOLVING)
THERE IS BUDGET FOR
EXPLORING THE IDEA, AND
BUDGET POTENTIALLY AVAILABLE
FOR REALISING THE IDEA
WE WANT TO KNOW
IF THE IDEA IS …
Technically
Feasible
Businesswise
Viable
Userswise
Desirable
36. WHAT IS AN AGILE/LEAN INCEPTON
Vision of
Goals, Product,
Success
High level
Scope
discovery
Technical
envisioning and
sizing
Prioritization,
and roadmap
The idea is to spend the minimal amount of time to establish :
- the vision of the delivery initiative,
- a feeling for the amount of work to be done,
- an alignment between everyone in the team, the sponsors, and all
the stakeholders
½ day 2 ½ days 1 day ½ day
37. WHAT IS AN AGILE/LEAN INCEPTON
Vision of
Goals, Product,
Success
High level
Scope
discovery
Technical
envisioning and
sizing
Prioritization,
and roadmap
½ day 2 ½ days 1 day ½ day
38. WHAT IS AN AGILE/LEAN INCEPTON
Technology
Delivery
Product Tech
estimates
Delivery
roadmap
Product/Business
priorities
Co-Create
Co-Evolve
Technically
Feasible
Businesswise
Viable
Userswise
Desirable
48. AGILE GOALS ARE OBLIQUE
• Pursue ways of working efficiency over resources mobilization & efficiency
• Manage the workflow over managing tasks schedule and maximizing utilization
• Focus on speed and frequency of delivery over reducing costs of delivery
• Align authority to responsibility over aligning authority to the orgchart
• Move authority to the information over moving information to authority
51. SHARED & DYNAMIC RESPONSIBILITIES
ROLE A ROLE B
PRIMARY
RESPONSIBILITIES
PRIMARY
RESPONSIBILITIES
SECONDARY/SHARED
RESPONSIBILITIES
52. EXAMPLE OF AN INDICATIVE TEAM COMPOSITION
Agile Team
Product Owner
Tech Lead
Developer
Tester
Scrum Master
Business
Analyst
CX/UX Designer
IT Ops
53. FIRSTS AMONG EQUALS
The three areas equally accountable, in the team:
Tech
Way of
Working/
Delivery
Product/
Business
Agile
Leadership
Agile
Leadership
Agile
Leadership
54. FIRSTS AMONG EQUALS
Leaders promotes self-organisation instead of command & control:
Facilitates
Collective sense-making
Facilitates
Continuous Improvement
& Personal development Promotes
Autonomy and accountability,
Delegation & Empowerment
Nurtures
Interpersonal &
Communication skills
Facilitates
Conflict resolution and
Consensus building
Facilitates
Participatory decision-making
55. THE PRODUCT OWNER
• Provides the vision for the product
• Is responsible for maximising the commercial &
financial success of the product
• Is responsible for ensuring customers and users
satisfaction about the product
• Has the final call on the items in the Product Backlog
and in their ordering
• Is responsible for keeping the Product Backlog
updated, ordered, clear, visible, transparent
56. THE SCRUM MASTER
• Supports the team and the PO understanding and
adoption of modern ways of working, and
continuously improving their way of working
• Supports good team’s dynamic and collaboration,
and facilitates team’s ceremonies/rituals/events
• Facilitates the collaboration between the agile team
and the rest of the organisation and helps the rest
of the organisation’s understanding of agile
• Facilitates transparency, visualisation and
communication of progress of the delivery effort
57. THE DEVELOPMENT TEAM
• They are collectively accountable for the delivery of
high-quality, running, and tested product increments
delivered at the end of each Sprint
• They are collectively responsible for technical
excellence, reliability and functionality of the Product
• They are cross-functional and self-organising, full-time
long-standing team’s members
• They are responsible for and have the freedom to
decide and improve their way of working
59. “Working software is the primary measure of progress”
–7th principle of the Agile Manifesto
~
“Don’t move information to authority, move authority to the information”
- David Marquet
69. PROJECTS OR PRODUCT
Project Product
End Predefined When retired
Outcome/result Predefined Refined overtime
Scope Prevalently predefined Refined overtime
Constraints (Scope, Schedule, Cost) Predefined May change overtime inside ranges
Organization (people, teams) Temporary, people who don’t
normally work together
Long-lived, mainly dedicated and
permanent, people that usually work
together
Focus Delivery End-to-end: Ideation, delivery,
operation, support, maintenance,
evolution
Driven by Plan Business outcome and value
71. You
traditional PM
1) You are comfortable with
uncertainty & ambiguity
2) You like to work in
team among equals
3) You like to be flexible,
adaptable, resilient and
responsive
OPTIONS FOR THE PM’S AGILE CAREER, A HEURISTIC
72. 1) You are a people person,
and love to facilitate,
coach, mentor and teach others
2) You love continuous improvement
and modern ways of working
3) You understand Digital Products
delivery & support
1) You love Digital Products
2) You love to delight Users
3) You understand Marketing,
Business models, Financing,
and P&L
OPTIONS FOR THE PM’S AGILE CAREER, A HEURISTIC
You may start the
journey to become a
Product Owner
You may start the
journey to become a
Scrum Master
73. ADDITIONAL TIPS
• Agile Training
• Lot of practice (pairing, shadowing)
• Reading
• Community involvement
76. SUGGESTED READINGS
THOSE WITH A SCIENTIFIC
BACKGROUND MAY LIKE THIS
(SEARCH ONLINE CHAPTER 1
ON WICKED PROBLEMS)
THOSE WITH
A HUMANISTIC BACKGROUND
MAY LIKE THIS
The goal of this session
provide the attendees with a basic vocabulary and the key concepts that will enable them to attend and benefit from attending other Agile events, meetup, and conferences.
The session will also explore career options for a traditional project manager in the Agile age, as well as training and certification options.
Working with agile since the beginning 2001/2002 when it was an underground movement
tech background, where agile started
Learning and trying bits and pieces of agile, practice by practice
Struggling to convince a co-worker or the team about trying out one practice because paradoxical, counter intuitive
Nowadays in mainstream
Genuine, authentic, truthful, reliable source of expertise
What are the most important inventions in human history ?
Management is one of those invention
that enable us to face those challenges
that require a
coordinated effort and collaboration
among a large number of people
Ask, which does not hold for you now?
Ask, which does not hold for you now?
Ask, which does not hold for you now?
Ask, which does not hold for you now?
Thinkers vs Doers
Told what to do AND told how
Told the deadline (others do the estimate)
Omniscient designers
Plan is always right if planner is up to the job
Mistakes originates from the execution
Thinkers vs Doers
Told what to do AND told how
Told the deadline (others do the estimate)
Omniscient designers
Plan is always right if planner is up to the job
Mistakes originates from the execution
whole Frederick Taylor http://paulgibbons.net/leadership-vuca-world-harish-manwani/
VIDEO – The intrinsic nature of the problem
Co-evolution: because the nature of the problem
Co-creation: sharing a creative space and deep collaboration, info from ppl from different parts of the org, from different points of view
Co-evolution: because the nature of the problem
Co-creation: sharing a creative space and deep collaboration, info from ppl from different parts of the org, from different points of view
Look at requirements & Stakeholders
PO is opposite of Single Point of Contact
Research the principles
Ask for more manifestos
NEW MANIFESTO
More generic, less specific on software development
Look at the principles
Many Lean sw schools.
Lean and agile are deeply intertwined in the software world. You can't really talk about them being alternatives, if you are doing agile you are doing lean and vice-versa
http://martinfowler.com/bliki/AgileVersusLean.html
#3 because we are working with complex systems and people, not machines
The nature of the problems: Different types of problems
- Wicked problems
Broader that SW
Because the nature of the problem : Unknowns, uncertainty => unanticipated, change
And ability to transition your way of working during the initiative to adapt to circumstances
Which one seems a good idea for the type of projects you are managing or part of?
Everyone is a thinker: the team decides how to work – no straight jacked processes
Simplest, intentionally incomplete
No Separation thinker - doers
Wisdom of the crowd
They deeply collaborate across silos on a shared artefact
Continuously integrate and have a holistic view of the progress
Change management and Risk management are not distinct activities or roles
They are part of daily work, for everyone to be responsible
Video 2 - Joy, Inc. Rich Sheridan
https://youtu.be/Oe8VTi3m8U8
Min 1.01- 2.42
Min 4.48 – 6.45
They deeply collaborate across silos on a shared artefact
Continuously integrate and have a holistic view of the progress
Change management and Risk management are not distinct activities or roles
They are part of daily work, for everyone to be responsible
Video 2 - Joy, Inc. Rich Sheridan
https://youtu.be/Oe8VTi3m8U8
Min 1.01- 2.42
Min 4.48 – 6.45
starting with the simplest possible, even incomplete, approach
continuous experimentation => learning => adapted / evolved
Empiric instead of prescriptive
Team experiment, learn, evolve their ways of working
Practices used to implement the requirements
What is needed to make your Tech/production practices depend on your business/industry.
In IT we have many of them described in Extreme Program methodology
I cannot talk about practices in each one of your industries, but I can share some principles and and example
F1 Stamps
Lean last responsible moment ... but after that => reversibility
Facebook, Kent Back, article
https://www.facebook.com/notes/kent-beck/taming-complexity-with-reversibility/1000330413333156/
F1 car creation timeline
The F1 stamps examples
Facebook, Kent Back, article
https://www.facebook.com/notes/kent-beck/taming-complexity-with-reversibility/1000330413333156/
Reduce the cost of change, increase the speed of learning
Facebook, Kent Back, article
https://www.facebook.com/notes/kent-beck/taming-complexity-with-reversibility/1000330413333156/
PROJECT initiation ('kick-off' or start)+ PROJECT definition, planning and development
3 months = 1 week
12 months = 4 weeks
Team doing the work involved
Alignment, co-creation, co-evolution
COLLECT DOCUMNENBT KNOWNS, WISDOM OF THE CROWD, TOOLS TO DEAL WITH UNKNOWNS, ELEPHANT STACY
- Connecting dots and
- feedback learnings from refinements
3 months = 1 week
12 months = 4 weeks
No hand-over and collaboration
PROJECT launch or implementation (sometimes known as project execution)
- Artefacts / Rituals events ceremonies meeting (recurring, time-boxed instead of ad-hoc)
all the PM/Requirements work happens during the rituals
the iterations, + evolution (inspection, learning, adaptation)
Scrum
From the inception: High level requirements (requirement repository)
Ordered by value and risk (plan)
Status of each requirement (to do or done: current status of execution/reporting)
Each item deliver value and learning: refined to be small enough to be done in 1 sprint, big enough to deliver value
work breakdown
Scope/requirements => User Stories / Epics
a project plan,
Estimates => Size
Schedule => priorities + estimates
identify and manage risks => priorities
Resources (team members volunteer and team self organise)
create the project budget => stable team = schedule
define and allocate resources => stable team
Sprint backlog: requirements refined and ready to start the design-development-test-deploy-accept
Work is not assigned, team members volounteer
Bas, devs, tester work together to maximize the work completed, visualising the progress and updating the backlog.
Dev, testers, Bas can talk with the client or show things
Team members update and visualise the progress (no one assign the work)
Every day visualising the progress and updating the backlog. coordinating the collaboration, helping each other to tackle blockers
Backlog refinement
Sprint review: requirements and priorities may change in order to create the right product and maximise the value
Sprint retrospective: Team reflect on improving the way of working
Tailor to suit the environment => Evolve to suite the environment
All artefacts are shared between the team, for transparency and alignment
http://www.stigasoft.com/images/agile-development-process.png
PROJECT launch or implementation (sometimes known as project execution)
- the iterations, + evolution (inspection, learning, adaptation)
Scrum
Big changes here
Shout out if you have questions and concerns
Full-time dedicated members, long-standing teams
Roles not individuals
Example very effective team Vs overgrown team
1st three areas equally accountable, not one boss
2nd biggest area (# ppl) the team, share collectively accountability
3rd the SM but also the PO uses agile leadership not command and control
Ordered = PrioritisedBAs CX/UX support the PODevs in small teams take up the work of BAs and CX/UX
No single point of contact
Last point one of the most commonly misunderstood
Long-standing => move work to the team, don’t move people to the work
RESOURCE management, mobilisation less less important
Budgeting simplified
project monitoring and controlling
When tasks are not fragmented and outcome in created continuously, the reporting / monitoring can be lightweight.
Most reliable, relevant, important: start from here. Add profit, market shares, customers satisfaction
Transparency, unintrusive inspection, reports automation
When tasks are not fragmented and outcome in created continuously, the reporting / monitoring can be lightweight.
Most reliable, relevant, important: start from here. Add profit, market shares, customers satisfaction
Transparency, unintrusive inspection, reports automation
That fifth lever is the team.
In our industry the team you assemble and how that team gels has a profound impact on the success of the project.
The trick now is to produce metrics that support team’s understanding
Actual Now + Updated forecast Vs Original Plan
90% done syndrome
Status of delivery
Status of delivery
Status of delivery
Status of delivery
Status of delivery
project close
What do you think?
Consultancy, construction work
Traditonal PMs won’t disappear that there may be less of
And if you miss some skills, pair
Training (PMI-ACP, Scrum org, ScrumAlliance, Agile Fundamentals) no scaled framework
MORE THAT PROCESS
Is one of those intangibles, including mindset, that are very powerful and have a big impact in an agile transformation/adoption.