Agile pm v2
-
date post
14-Sep-2014 -
Category
Technology
-
view
1.807 -
download
3
description
Transcript of Agile pm v2
1
Agile Project Management
Maria Horrigan and Matthew HodgsonSenior Consultants
SMS Management and Technology
Traditional PM Methodologies
• Prince2 - PRojects IN Controlled Environments (PRINCE)• PMBOK - Project Management Body of Knowledge • PMBOK describes many processes and
activities, though the PMBOK can be seen as being descriptive (what), while in contrast Prince2 is more prescriptive (how).
Prince2• Developed by the UK’s Office of Government Commerce • Prince2 describes many processes and activities
covering the management, control and organization of projects, and is deliberately not restricted to IT projects.
• Structured approach, provides a method for managing projects within a clearly defined framework
• Describes procedures to coordinate people and activities in a project, how to design and supervise the project, and what to do if the project has to be adjusted if it doesn’t develop as planned
• Each process is specified with its key inputs and outputs, specific goals and activities, which gives an automatic control of any deviations from the plan
4
Processes involved in Managing Prince2 Projects
Even though Prince2’s popularity makes it a de facto standard for project management , it is criticized for being too prescriptive, too big and not easily customisable.
PMBOK• Developed by the US-based Project Management
Institute (PMI). • Internationally recognized standard providing the
fundamentals of PM, not limited to IT-projects. • Five process groups: Initiating, Planning, Executing,
Controlling and Monitoring, and Closing. • Nine knowledge areas: Project Integration Management,
Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management, and Project Procurement Management.
6
7
What is a Successful Project ?
• On time?• On budget?• Met users' expectations?• Met business objectives?• Are these the only measure of a successful
project?• Can a project be considered successful if it is
NOT delivered on time, on budget, meeting specifications?
- 8
What about the Sydney Opera House?
Budget• Est $425M to build• Actual $2435MTimeframe• Est 1965 due date• Actual 1973 first openedDelivered
– Changed the face of Sydney Harbour– Most iconic, recognised symbol of Australia– Leading edge engineering invented– Revolutionised pre-fabrication
9
Sydney Opera House – an agile project
• Design team went through twelve iterations before a workable solution was completed.
• Use of structural analysis to understand the complex forces to which the shells would be subjected
• 2400 precast ribs and 4000 roof panels prefabricated on the ground in an on-site factory, instead of being stuck on individually at height.
10
What is Agile?
11
When we think about ‘agile’ it is..
• Light• Fast moving• Nimble• Flexible• Iterative• Changes direction easily• like a Cheetah
12
What ‘agile’ is not
• Slow moving• Hard to move/change direction• Heavy• Laborious• like an Elephant
13
When people talk about ‘agile’
“rapid iterations”, “working software”, “coping with change”, “communication”, “flexible”, “adaptable”, “eliminate waste”, “accepting changes”, “small iterations”, “feature-driven”, “continued integrations”, “test driven development”, “no documentation”, “people before process”, “adapt to change”, “the name”, “the team sets their own priority”, “early stakeholder involvement”.
People, not process make projects work
Individuals & Interactions over Processes & 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.”
http://www.agilemanifesto.org
What Agile “IS and ISN’T”
• A “Silver Bullet” solution • An excuse for poor requirement
definition• An excuse for poor design • An excuse for reducing quality• About failure to control the scope
of a project, its about managed change
• Doing more with fewer people• Doing more with less resources
or budget• Complex• Chaotic• Unstructured
• About people and collaboration• About mutual respect and
ownership• About actions rather than
discussions• Focused on delivery and outcomes• About delivering real business value• Producing “just enough”
documentation to get the job done • Managed iterations • Responding to business changes• Managing change • Simple, fast and efficient• Based on industry best practice• Disciplined and structured
Agile Is Agile Isn’t
16
Agile is a lot like life
• Things change• We adapt• We learn from our mistakes (hopefully)• When one thing doesn't work we then try
something else (mostly)
17
(Application of) Agile as a philosophy
• A set of values (or practices as Ivar Jacobson suggests), rather than a process
• Identify need/features• Prioritise features• Documentation is a placeholder for a
conversation• Choosing the best people and the best approach
for the right job• Multidisciplinary approach
Agile not Fragile• Developing by feature with business
involvement• Use of teams with business involvement• Individual class ownership• Regular iterations • Regular Inspections of design • Configuration Management• Reporting / High visibility of results• Clearly defined roles• Encourage culture that embraces change
and innovation
19
Where did Agile come from?
• Originally developed as a software engineering methodology
• Evolved in the mid 1990s as part of a reaction against “heavyweight” methods, as typified by a heavily regulated, regimented, micro-managed use of waterfall model of development
• Initially agile methods were call “lightweight” methods
• Adapted to project management
20
Reaction against Waterfall• Idea that we have to complete it from end-
to-end and know everything up front in order to cost and understand the what the solution will look like
• and if we don't then somehow we've failed?!
21
Waterfall• Sequential process• “Analysis Paralysis”• One iteration• Long timeframes• Doesn’t cater for changing business
environment.• linear process
– little flexibility– limited ability to cope with change
22
Do we know all the requirements up front?
• people often say they know what they want• but people often don't actually know what they want until
they see it– "that's not what I want!"– too expensive to go back now– maybe we'll try and train people how to use 'it' this
way• more expense• more change management• broken expectations about solution/delivery
23
Waterfall – takes time and $$$$
• In this appraoch, you could be trying to understand your requirements (design phase) for years before anything gets implemented– (Project example)
• Only ever end up incorporating 50-60% of your requirements anyhow
• means wastage of time (40-50% of requirements work becomes useless)
• That’s expensive!
Business Drivers - So why do Agile?• Maximise business value• Reduced time to market• Improved quality• Reduce waste/cost• Minimise risk profile• Improve responsiveness to business• Improve service levels to business
25
Agile Today
Formal methodologies• Takes from the best of a number of
practices from the disciplines of Project Management and Engineering
• But these won't teach us how to be Agile, they'll only teach us yet another process
Scrum, FDD, XPAgile Methodologies
Project Management Engineering
FDD
XPScrum
28
Early Agile Case studies
• Case 0: Daimler Chrysler Chrysler Comprehensive Compensation System (C3) payroll project
29
Extreme Programming (XP)
• Pitched as: Addressing “the specific needs of software development conducted by small teams in the face of vague or changing requirements”
• Invented by: Kent Beck who preferred being a Technical Lead to being a Project Manager.
• Year first used: Pre-2000• First used on: C3 project Chrysler• XP is a set of best practices of which some are taken to an
"extreme" level. • In the selection of its practices XP leans towards the daily
software engineering activities of developers• Now used on: All over the place by different groups/people
30
Requirments in XP
• As with other agile methods, XP regards ongoing changes to requirements as a natural and desirable aspect of software development.
• XP view of requirements– Onsite customer (implied singular customer)– Recognition that customer could be a team of
people– Recognition of the role of a customer
representative
31
Scrum• “Management and control process that cuts through complexity" • Invented by: Jeff Sutherland, Ken Schwaber, Mike Beedle. Senior
managers wanting to get product out faster. • Year first used: 1994 - now used all over the place with different
groups/people• First used on: Advanced Development Methods - process
automation software • Scrum is a skeleton that includes a small set of practices and
predefined roles • Scrum is becoming a de facto standard for managing agile software
development projects• Consists of a few common sense practices that can be applied in
many situations• Scrum by itself is never enough, and that development teams have
to shop in other methods (usually XP) for additional practices
Scrum: Roles• Alternative Name: User, Customer• Role Definition: The Product Owner represents the custumer/user/sponsor of the project, and is part
of the team which will deliver the product.•Main Activities: Define the vision for the product, manage the Return On Investment (ROI), present
the needed requirements to the team for the product delivery, prioritize requirements, manage addition/changes to requirements, plan releases, assure the Domain Experts are available to the team.
• Alternative Names: Project Manager/Leader, Coach• Role Definition: The role of Scrum Master, unlike a Project Manager in many practices and
methodologies, differ from the traditional “command and control”. In Scrum, the Scrum Master works with and, more important, for the team.•Main Activities: Allow the team to be self-managed, guide and help the team to correctly follow
Scrum practices, remove any impediment found by the team, protect the team from external interference, facilitate the daily meetings.
• Alternative Names: Developers, Technicians, Testers• Role Definition: A team member is someone committed to do the necessary work to achieve the
Sprint goal.•Main Activities: Define the Sprint goal, be committed to the work and to the high quality, work
towards the product vision and the Sprint goal, estimate items on the Product Backlog, attend the daily meetings.
Product Owner
Scrum Master
Team members
Scrum: Lifecycle
8. Product Increment(potentially shippable)
6. Day
5. Sprint(2-4 weeks)4. Tasks
detailedby the team
1. Vision(ROI, milestones,
releases)
2. Product Backlog, with featuresprioritized by the Product Owner
3. Sprint Backlog
7. Daily StandupMeeting
9. Inspect and Adapt
34
Feature Driven Development • “A framework of controls and best practice to enable and enforce
the repeatable delivery of working software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project”
• Invented by: Peter Coad, Jeff De Luca, Steven Palmer• Year first used: 1997• First used on: Hong Kong Banking Corp on a large 200 person Java
project• FDD blends a number of industry-recognized best practices into a
cohesive whole• These practices are all driven from a client-valued functionality
(feature) perspective• Its main purpose is to deliver tangible, working software repeatedly
in a timely manner.
35
and there are others . . .
• Crystal Methods• Dynamic Systems Development Method
(DSDM)• Lean Development (LD)• Adaptive Software Development (ASD)• ... etc ...
36
Commonalities
• Iterative• Evolutionary, not revolutionary (big bang)• Continuous learning• Focus on
– Effective communication– Multi-disciplinary teams– Adding value, not 'deliverables' or 'products'– What will add value to the 'end-user'
37
Why Agile?
38
Underlying Principles• Continuous improvement is the cornerstone of Agile • Focus is not on perfection but just getting better.• Conversation is the most effective way to clarify what
may seem to be a complex requirement• Need to provide clarity and answer the question “when
are we done”?• Prototyping mitigates risk by focusing on just enough to
gain the understanding needed• Iteration is the heart-beat of Agile • Estimation of all requirements before a project starts is
unrealistic - learn over time, refine and update plans • Prioritise to deliver the most business critical pieces
39
Key Features of Agile
• Breakdown of work into small, incremental work packages delivered in 2-4 week cycles
• Adaptability to new or changed requirements• Close involvement of end users and business
owners• Highly business and end user focussed
activities and outputs• Focus on face-to-face workshops and
communications• Proactive Change Management to embed
business change
40
Benefits of Agile
• Smarter way of working - innovative• Cross-functional teams• Contingent outcomes• Contingent processes and methodologies• Is about users and adding value, rather
than 'managing deliverables/products• Less risk• Less waste
41
How Agile Promotes Innovation
• Not locked into one way of doing things• Take learnings from previous iterations
and previous projects and apply directly, instantly, rather than having to wait til the next project
42
Less risk
• Easier to apply what you learn as you go• Encouraged to take things one step at a
time• Build a skinny 'system' to work out the
basics of what you need• Base decisions on light-weight requirements• Easier to change direction of scope as
required when uncovering new issues
43
Less waste
• Encourages re-use• 90-59% of requirements built rather than 50-60%
– Means you could waste up to 50% of project costs on things you don't need, don't want, or don't work properly
• Focus on documentation only when required• Less costly as a result
Cost to Change Curve
Cost of Change
Lifecycle Stage
$
$
$
$
$
45
Use of Cross Functional Teams
• Choose the best skills for specific jobs• Incorporate best knowledge from across
an organisation, not from within a single team
• utilise network-information flow inherent in new information transfer
46
Change management is built into the process
• Users involved in developing solution – increased ownership– develops 'champions'
• Users validate solution• means the result better aligns to what people want (they
get to be involved with each iteration and see the results i.e.: what they'll get)– not as much training required– not as much change management required
JIT Requirements Elaboration vs Up front elaboratio
• JIT (Just in Time)– Rapid progress early– Earlier customer feedback– Could get blind-sided
• Up front Elaboration– More up front effort, more time till customer feedback– Clarify overall scope and size sooner
• Considerations– Cost\Effort of development– Governance framework, funding model– Uniqueness
The Agile Lifecycle
Planning and AnalysisEffort
Time
Project Duration
49
Disadvantages of Agile
• It's relatively 'new' (people aren't as familiar with it as they are with Waterfall)
• People are afraid of what they don't know• People tend to want to know what they're getting
up front before they commit budget• Tends toward fragmentation of solution• Different people working on different
components means UX suffers• Different incompatible solutions may arise out of
each component/iteration
50
Agile is a standards based approach
51
ISO 13407
• Understand context in which solution needs to operate
• Involve users in developing a solution• Refine solution• Test solution with users• If solution validates, implement/build it• Roll onto next user need/feature
52
User centered design
Context
• Good Requirements (IEEE definitions)– Set is complete– Set is consistent– Set is modifiable
• Decomposition– Organize stories by relating to higher level
artifacts
“If you lose a card, and if the customer does not detect that loss, then the card wasn’t very important.”Robert C. Martin
User Involvement• Agile characteristics to promote user
involvement– Frequent “releases”– Daily stand up
55
Analysis of Business and User Needs
User Stories“A User Story is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement. The User Story promises as much subsequent conversation as necessary to fill in the details of what is wanted. The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. The customer prioritizes the stories and schedules them for implementation.”
57
User Stories• Three Cs• Card – encourages brevity, format easily used in prioritising• Promise for a conversation, not a fully-articulated
requirement• Confirmation details enable us to know when we are done
58
Stakeholder segmentation
• Main target audience• Who can influence the main target audience• Who are the (community) gatekeepers who also
need influencing to share what they know or lobby on your behalf?
• Channel identification– What channels do we use to communicate
most effectively with these people?– What messages to use
• identifying user need/value – user stories
59
Kernel Approach from Ivar Jacobson (UML God)
• Things to produce• Things to apply• Things to do• Competencies to perform• Concept, Feature problem, Work package
iteration, but its not a deliverable or a product
• Your Own Best Practices
60
Other Practice from many other sources
• Use Cases• Architecture• Iterative approach• Waterfall approach• Team• User Stories• Process Maps• Storyboards• Card Sorting• Personas• Non-functional HTML prototypes• Fully-functional prototypes• Contextual inquiry
61
Misconception that agile = no documentation and no
rigour/discipline
62
A "place-holder" for conversations
• Story cards• Personas• Storyboards• Interaction design maps• Card sorting• Conversations become formalised to tell the story
for those who follow– User requirements– Business requirements– System requirements
63
Build a skeleton solution first
• Assess need for parallel iterations– establish baseline – assess solutions according to baseline
• Biggest/first major iteration cycle is about 6-8 weeks
• End with fully-functional solution at the end• forms the baseline• Add bits to the skeleton, as identified by
prioritisation/value proposition/need/funds
64
Stand-up meetings
• Risks• Scope• Change management• Reporting
Sprint Planning Meeting• Turns product backlog into the sprint backlog• Gets the Team to commit to a level of delivery during the
Sprint• Product Owner, Scrum Master &Team attend• Elaborate the features in the product backlog
– Refine understanding & acceptance criteria– Create sub-tasks – Re-estimate
• Features the Team commits to delivering form the Sprint Backlog.
• Once formed the Sprint Backlog should not change
Daily Scrum & Impediments List
• Quick meeting to synchronize Team – Chance to escalate to Scrum Master
• 15 mins, 3 questions each– What did you do yesterday?– What are you going to do today?– What problems/issues do you have?
• Issues go on an Impediments List– The Scrum Master is responsible for removing
items from the Impediments List
67
Adoption of Agile within Prince2 environment
Allowed client to address scope and requirements one piece at a time, which allowed the project to evolve and change on a ‘just-in-time’ basis, with risks identified and mitigated as required
68
69
70
Key Agile activities• Discovery of current processes and end user needs, issues and
requirements through workshops• Collaborative development of process refinements and end user
experience improvements through visual storyboarding from the point of view of different users
• Business process modelling derived from validated storyboards• Detailed user interface prototypes derived from business process
maps• Iterative improvement of prototypes through validation with
business owners• The prototypes form the basis of the features that will drive the
strategic, business and user requirements specification for the resulting technology
71
Iterative improvements to user interface prototypes
business process map (‘swim lane’ or cross-functional flow chart) Refined visual storyboard mapping user
experience and high level business processes
Process refinement through visual storyboarding
Workshopping current processes and requirements
72
Build
Agile Delivery Methodology and ‘Elements of User-Experience’
Strategy Scope Structure Skeleton Surface
IA D
eliv
erab
les
Tim
eD
eliv
erin
g th
e pr
ojec
tIA
Act
iviti
es
Understand context
Analyse business processes
Analyse user’s needs
Understand site objectives
Personas Want Maps
Business process maps “as-is”
User segmentation
Understand technology limitations
Content audit
Content requirements
Functional specification
Gap analysis for content
Storyboards(as-is)
Business process maps “to-be”
PrototypeSite mapSite taxonomy
Card-sorting IA Solution(system metaphor)
Latest version
Bugs
Nextiteration
Certain estimates
Uncertainestimates
Iteration & release planning Iterate prototype
Performacceptance
testing
Usersign-off
Storyboards(to-be)
New functionalityidentified as missingSignificant
new functionality Non-significant changeAssess new functionality
Designinteraction paradigm
Navigation design
Agile XPiteration
TestscenariosInterface design
Graphic design
IA Final Report
Week 1 Week 2 Week 3 Week 4 Week 5 Week 5+
Project setup: Develop project plan
Develop stakeholder segmentation maps, governance model and user-engagement strategy.
Understand how to engage and involve IT vendor
Analysis phase: Examine context and understand the path to the “to-be” environment
Project planning: Assess risks, develop deliverables timelines
Begin analysis: Assess risks, develop deliverables timelines. Understand the context in which the project occurs, politics, corporate culture. Determine the “What’s in it for me” factors.
Change management plan: Develop ways in which users understand the changes they will need to go through in order to achieve the desired outcomes
Workshops: Ensure workshop activities draw users into the future state and ‘own’ it.
Workshops: Assess initial concepts with users.
1. Personas2. Card-sorting to understand how users think about information3. Front-page design
Surveys: Elicit pain points from users about the current state and understand their desired future state
IA Solution: Bring together all of the user-feedback into a single solution
Socialisation: Start to raise awareness of the end-state with stakeholders and users. Draw attention to the user-contribution and where it meets and complements best-practice. Raise awareness of how their input allows achievement of end-state.
Prototyping (Agile phase): Create the look and feel for end-to-end processes identified in the analysis phases. Incorporate all individual IA elements from the solution into this working model
Test the prototypes: Using actual user work-tasks:
1. Ask users to complete a task with their current IT support/environment. Time how long it takes. 2. Ask them to complete the task using the prototype. Time how long it takes.3. Reverse the order with another group4. Ask them to complete a survey: 4-point Likert scale noting how difficult the task was in each environment – v difficult, difficult, easy, v easy5. Collate results and analyse to determine whether solution results in improvement
Socialisation: Introduce users and stakeholders to results
Socialisation: Raise awareness of the final outcome to be delivered by the IT Vendor
Draft Report: As socialisation of report components draws to a close, incorporate elements into final report
Deliver Report: As acceptance of report content grows, finalise the elements and sign-off the report
73
Stakeholder Communication is Key
• Don't underestimate the value of face-to-face conversations• Leveraging web 2.0 for responsive communication (a vehicle for
getting quick feedback and collaboration)• Project blogs
– Project status, Lessons learned, Comments, Criticisms and Discoveries
• Announcements – Milestones, Blog posts, Media releases, Locations for system
prototypes and Locations of solutions to• review• comment• share• Critique
74
Communicate - formally or informally
Formal• group workshops
– card sorting– personas– collaborative design
• individuals– contextual inquiry– interviews– surveys/questionnaires– prototype testing
Informal• over coffee• over lunch
75
76
Flickr
• Photographs demonstrating engagement with stakeholders
77
Delicious
• Sharing 'discoveries'
78
Dopplr
• Sharing project milestones• Calendar/workshop dates
79
Wikis
• Benchmark project documentation• Iterate project documentation• Store for stencils, prototypes and templates• Features to manage projects
– User sign-ons– Version control– Roll-backs– Audit trails
80
Agile governance
• Report lessons – Out of each major iteration– When reaching major milestones
• Obtain sign-off/approval– When major solution components are identified– To pass major milestones– When new user-groups are identified and require
involvement in requirements/validation– Major scope changes
81
How to budget for Agile
• Kernel/contingency project model?• How many parallel iterations?
– How many people– What process– What practices– Payment on first iteration then delivery of
each subsequent identified 'feature‘ • Payment decisions/perceived value• Assessment of time/materials/iteration
requirements
82
So what is agile really about and how can we use it on our projects?
83
One size does not fit all• Not all projects (or iterations) are suited to Agile techniques
– Agile doesn’t fix every problem– Agile doesn’t work on every project
• Choose the right combination of techniques• Look for opportunities to be more agile• Analysis techniques are important, but as a means to actively elicit
information rather than document• Constant evolution of process can be difficult
– 2 steps forward, 1 step back– Avoid stagnation
• Verbal communication and interpersonal skills become more important in co-located team environments
• Training and mentoring are the key
84
Work smarter
• Become creative with the documentation we do create
• Leverage existing practices within your teams/divisions
• Leveraging existing expertise• Leverage existing knowledge
85
Pass on learnings
• Add through issues logs– Risks– Scope changes– Knowledge gained
• Capturing resourcing requirements per iteration
• Pass on experience
86
Next Steps
87
Workshops
• Presentation will be available on slideshare • QRG (quick reference guide) is being developed
and will be available• Workshops with teams
– Work through project issues – real cases and situations
• One-on-one coaching – Tailor training requirement to individual team needs
and level of familiarity with agile