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


Prototype

Comms Plan

Benchmark

Process

PersonasSitemap

Media release

User segmentation

10

Sourcing DNA

Project DNA

Things to produce

Patterns to apply

Things to do


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


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


Planning

Facilitation

Change management

User-experience engineering

Business knowledge

Analysis Process Improvement

Information management

13

Applying the DNA to the context

Project DNA


DNA


= +...

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


DNA


= +...

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


DNA


= +...

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


=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 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 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