Agile Project Management Part 1 Final
11 likes2,672 views
The document provides an overview of an Agile project management training session. It includes an agenda that covers managing projects, what Agile is, why use Agile, a break, Agile as a philosophy, case studies, learnings and conclusions. It also discusses traditional project management methodologies like Prince2 and PMBOK and compares them to Agile approaches like Scrum, Extreme Programming (XP) and Feature Driven Development (FDD).
Agile Project Management Part 1 Final
- 1. Agile Project Management Part 1 Matthew Hodgson & Maria Horrigan Murphy Senior Consultants SMS Management and Technology 1 May 2009
- 2. An Agile Agenda 1. Managing projects 2. What is Agile? Questions as 3. Why Agile we go 4. Break – 10 minutes 5. Agile as a philosophy 6. Case studies 7. Learnings 8. Conclusions 2
- 3. Take-aways • Quick Reference Guide • Evaluation survey • Slides available on DNET 3
- 4. Managing projects From PM to Agile 4
- 5. Traditional PM Methodologies Prince2 VS PMBOK • Projects IN Controlled • Project Management Body Environments (PRINCE) of Knowledge • Tends to prescribe how • Generally describes project projects should be processes and activities controlled 5
- 6. Prince2 Developed by: • UK’s Office of Government Commerce • Structured approach, provides a method for managing projects within a clearly defined framework Describes: • Control and organisation of projects -- deliberately not restricted to IT projects. • Procedures to coordinate people and activities in a project • How to design and supervise the project • What to do if the project has to be adjusted if it doesn’t develop as planned Specifies: • Process with its key inputs and outputs • Goals and activities – gives automatic control over scope deviations
- 7. Prince2 Processes It’s more about how to manage, but not what activities to do Even though Prince2’s popularity makes it a de facto standard for project management , it is criticized for being too prescriptive, too big and not easily customisable. 7
- 8. PMBOK Developed by: • US-based Project Management Institute (PMI). • Internationally recognised standard providing the fundamentals of project management, not limited to IT-projects. Five process groups: • Initiating, Planning, Executing, Controlling and Monitoring, and Closing. Nine knowledge areas: • Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management, and Project Procurement Management.
- 10. Process success measures? Through management of a project: • On time • On budget • Mitigated risks • Met users’ expectations • Met business objectives 10
- 11. Process success measures (cont) • Are these the only measure of a successful project? • Can a project be considered successful if – NOT delivered on time, on budget, meeting specifications? 11
- 12. What if a project ... Budget: • Est $425M • Actual $2,435M Almost a decade late! Timeframe: • Est 1965 due date • Actual 1973 first finished 12
- 13. Sydney Opera House project successes Delivered : • Iconic identity to Sydney & Australia • Culture to Sydney • Computer modelling engineering firsts • Revolutionary pre-fabrication methods - 13
- 14. Sydney Opera House – an Agile project Iterative: • Design team went through twelve iterations before a workable solution was completed. Passed on lessons learned to engineering community: • New use of computer structural analysis to understand the complex forces to which the shells would be subjected 14
- 15. So what is ‘Agile’? “We can't know what the future's going to look like. We have to be agile enough to be able to respond to that uncertainty.” - Linton Wells II 15
- 16. When people talk about ‘Agile’ Iterative – 60% Test Driven – 20% No Documentation – 10% Collaboration & social engineering – 10% 16
- 17. feature-driven early stakeholder involvement fast moving light-weight adding-value continued integrations eliminate waste no documentation collaboration nimble flexible test driven development When people talk about ‘Agile’ the team sets their own priority communication small iterations accepting changes adapt to change adaptable the name coping with change About people working software people before process user-focus rapid iterations 17
- 18. feature-driven early stakeholder involvement fast moving light-weight adding-value continued integrations eliminate waste no documentation collaboration nimble flexible test driven development When people talk about ‘Agile’ the team sets their own priority communication small iterations accepting changes adapt to change adaptable the name coping with change About people working software people before process user-focus rapid iterations 18
- 19. Agile IS ISN’T • About people, teamwork, and • A “Silver Bullet” solution collaboration • About delivering real business • Just for IT projects value and outcomes • An excuse for poor requirement • Producing light-weight definition documentation to get the job done • An excuse for poor design • Managed iterations • Responding to business changes • An excuse for reducing quality • Managing change • About failure to control the scope • Simple, fast and efficient of a project, its about managed • Based on industry best practice change • Disciplined and structured • Doing more with fewer people • Built-in validation of solutions • Doing more with less resources or • Contingent workforce and budget activities • Complex • Chaotic and unstructured 19
- 20. Ultimately, Agile is a lot like life • Things change • We adapt • We learn from our mistakes (hopefully) • When one thing doesn't work we then try something else (mostly) 20
- 21. Life and processes It’s not about the process, otherwise we’d all be millionaires! 21
- 22. Where did Agile come from? • Originally developed as a software engineering methodology • Agile methods were originally called “lightweight” methods • Adapted from to project management • Evolved in the mid 1990s as a reaction against “heavyweight” methods, ie: heavily regulated, regimented, micro-managed use of waterfall project processes 22
- 23. Agile: a reaction against Waterfall • Idea that we have to complete it end-to-end • Know everything up front in order to cost and understand the what the solution will look like 23
- 24. The Waterfall Process • Sequential • One iteration • Linear process – little flexibility – limited ability to cope with change • Long timeframes • Doesn’t cater well for changing business environment • Must know all requirements and risks before proceeding 24
- 25. Can we really know all the requirements up front? I definitely Hmmm … know what I …that’s not want! what I want 25
- 26. The usual reaction It’s too Maybe we'll try and expensive to go train people how to back now use 'it' this way 26
- 27. The result More expen$e: • Training still costs time and money More change management required: • Broken expectations about solution/delivery • Contingencies have to suddenly be developed • Only partial delivery of the solution – “we’ll do it in phase 2!” • Strained business relationships • No one wants to be involved with a ‘failed’ project 27
- 28. Waterfall – the reality That’s 40-50% You could be wasted analysis trying to time! understand your requirements You’re only going for months or You typically only to find out if your years implement solution works 50-60% of all at the end requirements 28
- 29. Waterfall – it’s expen$ive to change Maybe we should be looking at adapting and change here? It’s too expensive to incorporate changes toward the end of the Cost of change project 29
- 30. Trying a different approach: early Agile adoption Case 0: Daimler Chrysler Comprehensive Compensation System (C3) payroll project 30
- 31. 2002: Agile Manifesto History of Agile released 2002: A Practical Guide to Feature- Driven Development 2001: Agile published Software Development with 2003: McBreen SCRUM published publishes Today Questioning Extreme 1999: Extreme Programming Programming Explained published 2008: Waterfall Lessons drops to 28% 1995: learned Agile used in 60% DaimlerChrysler 2006: Waterfall in of projects * uses Agile use only 55% projects * 31
- 32. Business drivers for change toward Agile A need to maximise: • Business value – Lean processes Reduce: • Waste/cost Improved: • Responsiveness to business • Service levels to business • Quality Minimise risk profile 32
- 33. Less risk • Easier to apply what you learn as you go • Encouraged to take things one step at a time • Build a ‘skinny solution’ to work out the basics of what you need • Base decisions on core requirements – the project’s DNA • Easier to change direction of scope as required when uncovering new issues 33
- 34. Less waste Means you could save up to 50% of • Encourages re-use project costs on things you don't need, • 90-95% of requirements built don't want, or don't rather than 50-60%* work properly! • Focus on documentation only when required • Less costly as a result 34
- 35. Promotes learning & innovation • Not locked into one way of doing things • Take learnings from previous iterations and previous projects and apply directly, instantly, rather than having to wait until the next project • Cross-functional teams – different perspectives an opportunity for learning 35
- 36. Disadvantages of Agile • It's relatively new (people aren't as familiar with Agile as they are with Waterfall) • People are afraid of what they don't know • People tend to want to know what they're getting up front before they commit budget • Tends toward fragmentation of solution • Without a baseline, different incompatible solutions may arise out of each iteration • Without communication, different people may produce divergent solutions 36
- 37. Issues with Agile? • Misconception that agile = no documentation and no rigour or discipline 37
- 38. Agile documentation and Storyboards with process maps, use-cases requirements storyboards use case reference user experience business process user-profiles (actors) system objects requirements lists
- 39. Formal Agile processes: Scrum, FDD, XP Agile Project Management Engineering FDD Scrum XP 39
- 40. Extreme Programming (XP) • Pitched as: Addressing “the specific needs of software development conducted by small teams in the face of vague or changing requirements” • Invented by: Kent Beck who preferred being a Technical Lead to being a Project Manager. • Year first used: 1995 • First used on: C3 project Chrysler • XP is a set of best practices of which some are Kent Beck taken to an "extreme" level • In the selection of its practices XP leans towards the daily software engineering activities of developers 40
- 41. Requirements in XP • As with other agile processes, XP regards ongoing changes to requirements as a natural and desirable aspect of software development. • XP view of requirements: – Onsite customer (implied singular customer) – Recognition that customer could be a team of people – Recognition of the role of a customer representative 41
- 42. XP Lifecycle 42
- 43. Scrum • “Management and control process that cuts through complexity" • Invented by: Jeff Sutherland, Ken Schwaber, Mike Beedle. Senior managers wanting to get product out faster. • Year first used: 1994 • First used on: Advanced Development Methods - process automation software • Scrum is a skeleton that includes a small set of practices and predefined roles • De facto standard for managing agile software development projects Jeff Sutherland • Consists of a few common sense practices that can be applied in many situations • Scrum by itself is never enough, and that development teams have to shop in other methods (usually XP) for additional practices 43
- 44. Scrum: Roles • Alternative Name: User, Customer • Role Definition: The Product Owner represents the customer/user/sponsor of the project, and is part of the team which will deliver the product. • Main Activities: Define the vision for the product, manage the Return On Investment (ROI), present the needed requirements to the team for the product delivery, prioritize requirements, manage Product Owner addition/changes to requirements, plan releases, assure the Domain Experts are available to the team. • Alternative Names: Project Manager/Leader, Coach • Role Definition: The role of Scrum Master, unlike a Project Manager in many practices and methodologies, differ from the traditional “command and control”. In Scrum, the Scrum Master works with and, more important, for the team. • Main Activities: Allow the team to be self-managed, guide and help the team to correctly follow Scrum Master Scrum practices, remove any impediment found by the team, protect the team from external interference, facilitate the daily meetings. • Alternative Names: Developers, Technicians, Testers • Role Definition: A team member is someone committed to do the necessary work to achieve the Sprint goal. • Main Activities: Define the Sprint goal, be committed to the work and to the high quality, work towards the product vision and the Sprint goal, estimate items on the Product Backlog, attend the Team members daily meetings.
- 45. Communicate Scrum: Lifecycle lessons learned 6. Day 7. Daily Standup Meeting 5. Sprint 4. Tasks (2-4 weeks) detailed 8. Product Increment 3. Sprint Backlog by the team (potentially shippable) 1. Vision 2. Product Backlog, with features (ROI, milestones, releases) prioritized by the Product Owner 9. Inspect and Adapt
- 46. Feature Driven Development (FDD) • “A framework of controls and best practice to enable and enforce the repeatable delivery of working software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project” • Invented by: Peter Coad, Jeff De Luca, Steven Palmer • Year first used: 1997 • First used on: Hong Kong Banking Corp on a large 200 person Java project • Blends a number of industry-recognized best practices into a cohesive whole • Practices are all driven from a client-valued functionality (feature) perspective • Main purpose to deliver tangible, working software repeatedly in a timely manner. 46
- 47. and there are others . . . • Crystal Methods • Dynamic Systems Development Method (DSDM) • Lean Development (LD) • Adaptive Software Development (ASD) • ... etc ... 47
- 48. SCRUM, XP, FDD: Commonalities • Equally applicable principles across any project, regardless of technology component • Iterative • Evolutionary, not revolutionary (big bang) • Continuous learning • Focus on: – User-focus - what will add value to the 'end-user‘? – Adding value, not 'deliverables' or 'products‘ – Effective communication – Multi-disciplinary teams – Re-use 48
- 49. But XP, SCRUM, etc are still just processes These won't teach us: • How to be Agile They'll only teach us: • Yet more processes 49
- 50. Solution: apply Agile as a philosophy not a process • A set of values & practices • Identifies need and develops features/solutions to match • Documentation is a placeholder for a conversation • Multidisciplinary approach • Chooses the best people and the best approach for the right job Ivar Jacobson Agile Evangelist 50
- 51. Fin Questions? 51
- 52. Agile Project Management Maria Horrigan Murphy Matthew Hodgson Regional-lead for Business Analysis Regional-lead for Web and Information Management Blog: www.barocks.com Blog: magia3e.wordpress.com Twitter: miamurphs Twitter: magia3e Slideshare: www.slideshare.net/murph Slideshare: www.slideshare.net/magia3e Email: maria.murphs@gmail.com Email: mhodgson@smsmt.com Mobile: 0412 821852 Mobile: 0404 006695 52