Agile Project Management Part 2 Final V1.5

Agile Project ManagementPart 2
Matthew Hodgson & Maria Horrigan Murphy
Senior Consultants
SMS Management and Technology
1
May 2009

Why Agile as a Philosophy?
Shifting focus away from processes
2

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
3

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
4

Using DNA in our Project Solution
5
The skinny solution

Streams of analysis
Prioritised ‘features’
This is actually ISO13407
6

Iteration and sourcing the ‘right’ DNA
7
Context
Balancing human & business requirements
Validation
Solution design

Sourcing DNA
8

Sourcing DNA
9
Prototype
Benchmark
Comms Plan
User segmentation
Process
Media release
Personas
Sitemap

Sourcing DNA
10
Test/vallidate
Specify requirements
Ethnographic
research
Facilitate workshop
Contextual inquiry
Communicate to Steering Committee
Communicate lessons learned

Sourcing DNA
11
Elements of User Experience
Governance model
Standards eg ISO13407
Waterfall
Quality Assurance
Iterative design
Risk mitigation

Sourcing DNA
12
Analysis
Process Improvement
Business knowledge
Planning
Information management
User-experience engineering
Change management
Facilitation

Applying the DNA to the context
Applying DNA
13
Sourced from a library of components sets resourcing requirements incl. time and price
Choose a Team Leader
Built in validation into the DNA for the iteration to be complete

Applying the DNA to the context
Applying DNA
14
Lessons learned

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
15

Embedding knowledge in our DNA
16
Project log: risks, lessons learned, outcomes, resources
Lessons learned
Lessons learned

Next: Case studies
… let’s look at this after the break
17

Case studies
… Agile in Action
18

Agile projects in action
Improving government business processes
Outsourcing service management
Web 2.0 program delivery
19

1. Improving government business processes
20

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
21

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
22

First application of ISO13407 as ‘Agile’
23

Solutions in parallel
24

25
‘Things to Produce’ – lean documentation
Workshopped current processes and requirements
Iterated improvements to user interface prototypes
Refined processes through visual storyboarding
Mapped business processes(‘swim lane’ or cross-functional flow chart)
Refined visual storyboard mapping user experience and high level business processes

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
26

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
27

2. Outsourcing service management
28

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
29

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
30

User involvement
We promoted and encouraged user involvement:
Frequent “releases”
Employed fully-functional prototypes to set expectations

The project’s lifecycle
First iteration completed. Built the ‘skinny solution’
Pass on learnings
Pass on learnings
Second iteration. Refinined the solution
Fine tuning the solution. Still focussed on ‘adding value’
Planning and Analysis
Effort
Users helped to validate the solution
Time
Employed User Stories as first articulation of Project DNA

User Stories
Is a story:
Told by the user
Specifies:
How the system is supposed to work, written on a card
How long it will take to implement
Promises:
As much conversation to complete in the details of what is wanted and needed
Are used:
As tokens in the planning process after assessment of business value and risk
To set priorities and schedule for implementation

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
34
Documentation of Project DNA

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
35
Lean documentation is more economical than formal requirements

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
36

3. Web 2.0 program delivery
37

Web 2.0 program delivery
Project 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
38

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
39

DNA
Major project phases
Planned iterations between DNA
Things to produce
Iteration communication strategies
40

Balanced business and users’ needs
41
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

Iteration communication strategies
Regularly 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
42

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
43

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
44
What did you do yesterday?
What problems/issues do you have?
What are you going to do today?

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’
45

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’
46

Overall learnings from case studies
What did we learn?
47

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
48

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’
49

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
50

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
51

Agile environments need good governance
52
Signs off on major iteration cycles/milestones
Other business SMEs can assist with solution validation
Communicate key risks and scope issues to Steering Committee
Logging resources against iteration estimates

Agile environments need good governance
53
Project Leader is more effective if embedded in solution iterations as a practitioner
Lower overhead on projects by moving scheduling to here

Communicate to the Steering Committee during iterations
54

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
55

Conclusions
Take home messages
56

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!
57

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
58

Next Steps
59

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
60

Fin
Questions?
61

Agile Project Management
62
Matthew Hodgson
Regional-lead for Web and Information Management
Blog: magia3e.wordpress.com
Twitter: magia3e
Slideshare: www.slideshare.net/magia3e
Email: mhodgson@smsmt.comMobile: 0404 006695
Maria Horrigan Murphy
Regional-lead for Business Analysis
Blog: www.barocks.com
Twitter: miamurphs
Slideshare: www.slideshare.net/murph
Email: maria.murphs@gmail.comMobile: 0412 821852