Agile Project Management Part 2 Final V1.5

1,634 views

Published on

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

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,634
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
119
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Bridge between technology, business, and the outsourced service managers.Voice of reason
  • When doing an iteration we have to think about the people, processes, structure and technology. Maybe this is part of the kernel?
  • “Agile” 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
  • Agile Project Management Part 2 Final V1.5

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

    ×