Part two of this presentation looks at case studies where we applied agile as a philosophy and used a Prince2 methodology basis for our zenagile framework

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

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

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 3

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 4

5. Using DNA in our Project Solution 5 The skinny solution

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

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

8. Sourcing DNA 8

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

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

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

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

13. 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

14. Applying the DNA to the context Applying DNA 14 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 15

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

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

18. Case studies … Agile in Action 18

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

20. 1. Improving government business processes 20

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 21

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 22

23. First application of ISO13407 as ‘Agile’ 23

24. Solutions in parallel 24

25. 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

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 26

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 27

28. 2. Outsourcing service management 28

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 29

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 30

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

32. 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

33. 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

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 34 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 35 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 36

37. 3. Web 2.0 program delivery 37

38. 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

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 39

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

41. 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

42. 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

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 43

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

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

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

47. Overall learnings from case studies What did we learn? 47

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 48

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

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 50

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 51

52. 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

53. 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

54. Communicate to the Steering Committee during iterations 54

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 55

56. Conclusions Take home messages 56

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

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 58

59. Next Steps 59

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 60

61. Fin Questions? 61

62. 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