Agile Project Management Part 2 Final V1.5
-
Upload
mia-horrigan -
Category
Business
-
view
1.859 -
download
3
description
Transcript of Agile Project Management Part 2 Final V1.5
1
Agile Project ManagementPart 2
Matthew Hodgson & Maria Horrigan MurphySenior Consultants
SMS Management and Technology
May 2009
2
Why Agile as a Philosophy?
Shifting focus away from processes
3
Underlying principles• Lean and free of prescriptive methodologies• Concentrate on contingency approach to practices, team members,
outputs• Continuous improvement is its cornerstone – add value not
documentation• Iteration is its heart-beat – improvement not perfection• Conversation is the most effective way to clarify what may seem to be a
complex requirement• Provide clarity and answer the question “are we there yet”?• Prototyping mitigates risk by focusing on just enough to gain the
understanding needed – its about validation of the solution before we implement it
• Estimation of all requirements before a project starts is unrealistic - learn over time, refine and update plans
4
Where did we learn them?
• Learning by doing, not knowing it was called ‘Agile’
• Iterative exploration of solutions, validating with users, light-weight documentation
• Adapting to change with changes in overarching policy, changes to team members, major technology changes
• Freely and openly sharing our knowledge
5
Using DNA in our Project Solution
Project DNA
+ Project DNA + Project
DNA
Project End-Solution
= +...
The skinny solution
Streams of analysis
Project DNAProject
DNA
Identify users’ needs
Implement Solution
Directing
Understand context of use
Produce design solution
Specify user andstrategic
requirements
Evaluate/validatewith users
Start up DeliveryInitiation Closing
Planning
Project DNA
6
Prioritised ‘features’
This is actually ISO13407
7
Iteration and sourcing the ‘right’ DNA
Project DNA
Context Balancing human & business
requirements
Solution design
Validation
8
Sourcing DNA
Project DNA
Things to produce
Patterns to apply
Things to do
Competencies to perform
9
Sourcing DNA
Project DNA
Things to produce
Patterns to apply
Things to do
Competencies to perform
Prototype
Comms Plan
Benchmark
Process
PersonasSitemap
Media release
User segmentation
10
Sourcing DNA
Project DNA
Things to produce
Patterns to apply
Things to do
Competencies to perform
Test/vallidateSpecify requirements
Ethnographicresearch
Contextual inquiry
Facilitate workshop
Communicate lessons learned
Communicate to Steering Committee
11
Sourcing DNA
Project DNA
Things to produce
Patterns to apply
Things to do
Competencies to perform
Risk mitigationIterative design
Waterfall
Governance model
Quality Assurance
Standards eg ISO13407
Elements of User
Experience
12
Sourcing DNA
Project DNA
Things to produce
Patterns to apply
Things to do
Competencies to perform
Planning
Facilitation
Change management
User-experience engineering
Business knowledge
Analysis Process Improvement
Information management
13
Applying the DNA to the context
Project DNA
+ Project DNA + Project
DNA
Project End-Solution
= +...
Project DNA
Storyboarding
Prototype
Analysis
Team
Contextual inquiry
Iterative
Applying DNA
Team
Business analyst
DesignArchitect
Media
Comms
Project Sponsor
ChangeManager
Built in validation into the DNA for
the iteration to be complete
Sourced from a library of
components sets resourcing
requirements incl. time and price
Choose a Team Leader
14
Applying the DNA to the context
Project DNA
+ Project DNA + Project
DNA
Project End-Solution
= +...
Project DNA
Storyboarding
Prototype
Analysis
Team
Contextual inquiry
Iterative
Applying DNA
Team
Develper
Business Analyst
Business Analyst
Info offcier
DesignArchitect
Graphic designer
Team
Business analyst
DesignArchitect
Media
Comms
Project Sponsor
ChangeManager
Lessons learned
15
Used Multidisciplinary Teams
• Choose: 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
Team
Business analyst
DesignArchitect
Media
Comms
Project Sponsor
ChangeManager
16
Embedding knowledge in our DNA
Project DNA
+ Project DNA + Project
DNA
Project End-Solution
= +...
Lessons learned
Lessons learned
Project log: risks, lessons learned, outcomes, resources
17
Next: Case studies
… let’s look at this after the break
18
Case studies
… Agile in Action
19
Agile projects in action
1. Improving government business processes2. Outsourcing service management3. Web 2.0 program delivery
20
1. Improving government business processes
21
Improving government business processes
Project context:• Started with waterfall analysis• No idea what the end solution would be like• No one knowing their own processes• PM focus on products rather than value• Large organisational change project• Multiple stakeholders across silos• External industry pressure for it to happen
22
What did we do
• Focussed on what ‘functions’ added value to the business
• Prioritised functions• Contingent approach to resourcing, deliverables,
validation, user-centred requirements elicitation activities
• Weekly stand-up meetings• Re-use of solutions between iterations• Prototyping the end solution• Shared knowledge from iterations in a wiki
First application of ISO13407 as ‘Agile’
Project DNAProject
DNA
Identify users’ needs
Implement Solution
Directing
Understand context of use
Produce design solution
Specify user andstrategic
requirements
Evaluate/validatewith users
Start up DeliveryInitiation Closing
Planning
Project DNA
23
24
Project DNA
Project DNA
Project DNA
Project End-Solution
=Business analyst
Business analyst
InformationArchitect
ChangeManager
BusinessOwner
BusinessOwner
BusinessOwner
Solutions in parallel
25
Iterated improvements to user interface prototypes
Mapped business processes (‘swim lane’ or cross-functional flow chart)
Refined visual storyboard mapping user experience and high level business processes
Refined processes through visual storyboarding
Workshopped current processes and requirements
‘Things to Produce’ – lean documentation
26
Key activities
• Breakdown DNA: small, incremental work packages delivered in 2-4 week cycles
• Involved: end-users and business owners in analysis and validation
• Focussed: high value, lean business and end-user activities
• Communicated: face-to-face thru workshops• Embedded: change management into the solution as
each iteration and user-involvement lead people toward the final solution
27
What did we learn• Agile can lead to fragmentation (iterations can get out of
sync)• Need someone to be responsible for the baseline – embed
one person across all teams was our solution• Getting the right people and right resources can mean the
difference between success and failure• Build the team based on JIT assessment of what’s needed,
rather than what the ‘process’ tells you should be doing next with whom
• Involving users in validation meant increased adoption of and buy-in to the final solution
28
2. Outsourcing service management
29
Outsourcing service management
Project context:• 23 independently funded programs of work with
different business owners• 23 projects working in isolation• Projects shared same end-users and the same
business area• Outsourced some program services but not others• No sharing of knowledge between projects/programs
30
What did we do• “You guys are my risk mitigation strategy”• Investigated: 23 different services to be delivered• Analysed: common business processes in the first iteration cycle (8
weeks)• Identified: core features of each service• Iterated the solution: worked at unknowns of implementation one
piece at a time (2 weeks)• Operated: across multiple service-lines at a time• Reused: UI across all business support features• Engaged: specific people with specific knowledge/skills for different
iterations• Shared experiences: at weekly meetings between team
User involvement
We promoted and encouraged user involvement:• Frequent “releases”• Employed fully-functional prototypes to set
expectations
The project’s lifecycle
Planning and AnalysisEffort
First iteration completed. Built
the ‘skinny solution’
Second iteration. Refinined the
solutionFine tuning the solution. Still focussed on
‘adding value’
Time
Pass on learnings Pass on learnings
Employed User Stories as first articulation of Project DNA
Users helped to validate the
solution
User StoriesIs a story:• Told by the userSpecifies:• How the system is supposed to work, written on a card• How long it will take to implementPromises:• As much conversation to complete in the details of what is
wanted and neededAre used:• As tokens in the planning process after assessment of business
value and risk• To set priorities and schedule for implementation
34
User Stories (cont)
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
Documentation of Project DNA
35
Other "place-holders" for conversations
• Personas• Storyboards• Interaction design maps• Card sorting• Conversations become formalised to tell the
story for those who follow – e.g. user requirements, business requirements, system requirements
Lean documentation is more economical
than formal requirements
36
What did we learn
• Learned to save time: first iteration was longest, but subsequent iteration length was decreased thru re-use of knowledge
• Communication is key: to shared understanding of goals, risks and outcomes
• Documentation: is meant to be purpose-built for communication with specific audiences
• How to save money: first service solution $300k, subsequent service solutions $150K
37
3. Web 2.0 program delivery
38
Web 2.0 program deliveryProject context:• $50M program• High-profile project, politically sensitive• Introduce new Web 2.0 technologies for communication and
collaboration with the public• Create central community hub to share knowledge amongst
citizens and expert public servants• Communicate government programs in plain-English• Never succeeded with this external stakeholder group before –
all projects seen as failure to deliver to end-users• Politically very high-risk project
39
What did we do• Prioritised: activities to deliver project• Identified: iterations and interconnections between
outcomes• Produced: means for communicating project outcomes to
stakeholders and steering committee with Web 2.0• Encouraged: re-use of project materials to reduce costs of
final solution• Built: change into the process – highly visible communication
of activities and outcomes resulted in higher awareness of project goals
• Adapted: existing iteration cycle for web projects
40
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
DNAMajor
project phases
Iteration communication
strategies
Things to produce
Planned iterations between
DNA
41
Balanced business and users’ needs
The solution wasn’t all about
just Web 2.0 technology!
Considering these issues
helps to identify project’s DNA
Don’t forget to consider BAU
42
Iteration communication strategiesRegularly met to discuss and plan iterations:• Examined: DNA backlog, future iterations• Discussed: future DNA requirements,
relationships between iterations, resource requirements, timing against projected schedule
• Adjusted/recorded: baseline log of issues, resource estimations, etc.
• Reported issues to Steering Committee
43
Stand-up meetings
Each morning, discussed:• Risks – are they being mitigated or any new ones?• Scope – any unexpected features popping up?• Change management – setting users’ expectations• Reporting – to the Steering Committee
. . . discussed in relation to immediate and next iteration
44
Stand-up meetings (cont)
Why stand-up meetings?• Quick meeting to synchronize the Team - chance
to escalate to the owner of the risk log
Keeping it quick, simple and straight to the point:• 15 mins, 3 questions each
Watch out for:• Meeting fatigue
What did you do yesterday?
What are you going to do
today?
What problems/issues
do you have?
45
What did we learn
Keeping the Steering Committee engaged is hard:• Don’t assume they understand project activities
and outcomes• They’re not as involved in activities as other
end-users – education is still important (even if they don’t want it)
• Report to them often, but don’t overload them with ‘technobable’
46
What did we learn (cont)
• Communication: is best done through multiple channels, from blogs, wikis, twitter and delicious to public presentations, email and video
• Keep it simple: light-weight briefings work best for everyone (incl. at stand-up meetings)
• Be transparent: lessons learned need to be both good and bad
• Know the language: speak to the right audience with the right ‘language’
47
Overall learnings from case studies
What did we learn?
48
Learning is critical to agile
• Take learnings from the first project and introduce them into the next one
• Apply learnings from project to project• Take ‘practices’ from different disciplines and
use them within the Agile Philosophy (add them to our toolkit)
• Improve delivery value to users as we went along
49
Learning is critical to agile (cont)
Agile learning results:• Greater success in the future • Quantify and qualify what works and when • Efficient application of DNA-practices in
contingent ways rather than being dictated to by a ‘process’
50
Build a skeleton solution first
• The skeleton forms the baseline – revisit/assess after each iteration
• Assess need for parallel iterations• Biggest/first major iteration cycle is about 6-8
weeks• End with fully-functional solution at the end• Add bits to the skeleton, as identified by
prioritisation/value proposition/need/funds – about 2-3 weeks each subsequent iteration
51
Stakeholder Communication is Key
• Don't underestimate the value of face-to-face conversations
• Leveraging Web 2.0 technologies for responsive communication – a vehicle for getting quick feedback and collaboration
• E.g. Project blogs – project status, announcements, lessons learned, risks, comments, criticisms and discoveries
• E.g. Team Sites (or wikis) to share documents, review them, collaborate, share learnings
52
Agile environments need good governance
Steering
Committee
Project Leader
IT Group
Project Assurance
Project Team
Solution Iteration Team 1
Solution Iteration Team 2
Solution Iteration Team N
Project Support
Other business SMEs can assist
with solution validation
Communicate key risks and scope
issues to Steering Committee
Signs off on major iteration
cycles/milestones
Logging resources
against iteration estimates
53
Agile environments need good governance
Steering
Committee
Project Leader
IT Group
Project Assurance
Project Team
Solution Iteration Team 1
Solution Iteration Team 2
Solution Iteration Team N
Project Support
Project Leader is more effective if
embedded in solution iterations as a practitioner
Lower overhead on projects by
moving scheduling to
here
54
Communicate to the Steering Committee during iterations
55
Communication and governance
• Report upwards out of each major iteration• Regular light-weight documentation helps
alleviate information overload: video blogs, one page Minutes, DNET dashboards, all help to share project progress
• Sign-off to approve movement beyond major iteration milestones ensures appropriate delegation of responsibilities
56
Conclusions
Take home messages
57
Work smarter
Become creative:• With the documentation you produce
Leverage existing:• Practices within your teams/divisions – use them in your
DNA, log them, benchmark them• Expertise• Knowledge
. . . reuse and learn!
58
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 for your project’s DNA• Analysis techniques are important, but as a means to actively elicit
information rather than document• Constant change, adapting, iterating can be difficult:
– 2 steps forward, 1 step back• Communication and interpersonal skills are equally important in co-
located team as they are in virtual teams• Sharing knowledge is central to success – training and mentoring
are the key
59
Next Steps
60
Workshops
• Presentation will be available • 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 needs and
level of familiarity with the Agile philosophy
61
Fin
Questions?
62
Agile Project Management
Matthew HodgsonRegional-lead for Web and Information Management
Blog: magia3e.wordpress.comTwitter: magia3e
Slideshare: www.slideshare.net/magia3eEmail: [email protected]
Mobile: 0404 006695
Maria Horrigan MurphyRegional-lead for Business Analysis
Blog: www.barocks.comTwitter: miamurphs
Slideshare: www.slideshare.net/murphEmail: [email protected]
Mobile: 0412 821852