(PPROJEKTURA) pmi agile for corporation
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

(PPROJEKTURA) pmi agile for corporation

on

  • 295 views

Presentation for PMI FORUM 2013, describing the role of Agile methodologies in corporations.

Presentation for PMI FORUM 2013, describing the role of Agile methodologies in corporations.

Statistics

Views

Total Views
295
Views on SlideShare
291
Embed Views
4

Actions

Likes
0
Downloads
5
Comments
0

3 Embeds 4

http://www.linkedin.com 2
https://www.linkedin.com 1
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Progressive Elaboration speaks to the need to refine scope and evolve plans as more information becomesavailable.The related concept of Rolling Wave planning which states planning should be iterative and ongoing basedon short time horizons.But Also the tools used to create them do not readily support wholesale refactoring
  • The majority of software projects managed with traditional techniques do not undertake the rigorous plan refactoring required to keeppace with the true project work. Either detailed task oriented plans become outdated, or high-level, phase orientedplans are produced that offer little value in way of project tracking or forecasting.
  • The majority of software projects managed with traditional techniques do not undertake the rigorous plan refactoring required to keeppace with the true project work. Either detailed task oriented plans become outdated, or high-level, phase orientedplans are produced that offer little value in way of project tracking or forecasting.

(PPROJEKTURA) pmi agile for corporation Presentation Transcript

  • 1. AGILE CORPORATION: MISSION IMPOSSIBLE? Ratko Mutavdžić, PMP, PROJEKTURA
  • 2. PODSJETNIK! 14.11.2013.
  • 3. HVALA SPONZORIMA 14.11.2013.
  • 4. SADRŽAJ  uvod  zaplet  rasplet  pogovor  zaključak  pitanja i odgovori 14.11.2013.
  • 5. FEW ASSUMPTIONS just to be in the same book, if not on the same page... • • • • you know what the agile methodology is all about you know what the plan driven methodology is all about you think that agile works way better than plan driven you still have hard time to explain to your boss that you should move everything to agile and drop that money sucking, morale destroying, never under control thing that people are calling „project management” so, if we all nod our heads... we can continue... note: if most of the people nod their heads, it is safe to continue...
  • 6. IF YOU THINK YOU ARE NOT USING AGILE... like, you heard about the thing but you think that you are not ready... 1. 2. 3. 4. 5. 6. 7. 8. Requirements Analysis Functional Design Technical Design Product Development System Integration Quality Testing User Acceptance Testing Deployment project timeline (initial) does this look’s like your current plan? all good plans start this way. we are safeguarding against uncertanities and risk events note: read more about Parkinsons Law: „work expand so as to fill the time available for its completion”
  • 7. THINK AGAIN. actually you are on a good track to recognize most of your projects 1. 2. 3. 4. 5. 6. 7. 8. Requirements Analysis Functional Design Technical Design Product Development System Integration Quality Testing User Acceptance Testing Deployment project timeline (crushed number of times) the plan after the meeting with the customer scope same (will increase later), same resources, less time, less money note: there are some good movies filmed on this topic
  • 8. WELCOME TO CORPORATION there ‘s no right to free speech in the workplace • standard elements and barriers to overcome: • resistance to collaboration internally and externally • waterfall culture, not only in project management • low-trust environment • unwillingness to change • rigid management hierarchy why beign too smart in not too smart „human resources is not rhere to help you, but to protect the company from you” note: for more info, read a book „Corporate Confidential: 50 secrets your company does not want you to know”
  • 9. now, you ask a agile guy to give you an estimate...
  • 10. … and his manager needs some concrete numbers…
  • 11. WHAT CORPORATION WANTS FROM AGILE you know what I am talking about • • • • • • to understand where is ROI to understand how you going to be faster and more predictable to understand how they can be more responsive to market to understand how to enable strategic flexibility to understand how to achieve shorter dev cycles and better quality to understand how to improve team morale to understand the business benefits of agile regardless of investment, leadership and time needed www.agilemanifesto.org
  • 12. AGILE IS DESIGNED TO DEAL WITH... some really nasty laws and lemma’s • software projects are not predictable: specifications will never be fully understood (Ziv’s Law) • requirements uncertainty makes scope an inadequate starting point: the user will never know what they want until after the production (Humphrey’s Law) • the stakeholders will change requirements, change direction, or stop the project at any time: the interactive system can never be fully specified nor it can be fully tested (Wegner’s Lemma) agile is here to <insert_logical_reason_here> note: also good ones: Parkinson’s Law, Murphy’s Law, Segal’s Law (two watch, no clue of right time thing)
  • 13. LOOK AT THE MANIFESTO you know what I am talking about... • we are uncovering better ways of developing software by doing it and helping others do it: • individuals and interations over processes and tools • working software over comprehensive documentation • customer collaboration over contract negotiation • responding to change over following a plan this is not the great way to introduce the concept to the board we are confusing CXO’s even if we can do a great job in a first place note: www.agilemanifesto.org
  • 14. WHY AGILE WORKS? there are some theories that you want to read through • • • • Theory of Constraints and Lean Thinking Complex adaptive systems: the science of uncertainty Cognitive science: the nature of human decision making Evolutionary psychology & Anthropology: the origins of social interaction & its nature humanistic, goal directed approach that utilize people’s ability to manage complexity note: your manager will be lost, but at least you know why
  • 15. ISSUES WITH AGILE you know what I am talking about • to manage large-scale programs with highly dependant, sequential components (infrastructure, facilites) • to manage concurrent projects: status, backlog, decisions, risks (overall picture) • to manage multi-vendor environment with no agile experience • to manage context-switching due to allocation of the groups into small teams • to introduce organizational transformation and cultural changes? agile is great for software development, but... regardless of investment, leadership and time needed www.agilemanifesto.org
  • 16. plan driven, waterfall, used to be your best friend...
  • 17. ISSUES WITH WATERFALL TRUE stories why we have issues with waterfall • SERIALIZED PROCESS: longer time to market; devs isolated from customer needs • PLANNING FAR IN ADVANCE: plans no longer march reality by the implementation time • LACK OF VISIBILITY INTO RATE OF PROGRESS: teams don’t realize they’re behind schedule until too late; features slashed very late to compensate • LONG TIME TO PROJECT COMPLETION: customers get acccess infrequently • PROJECTS FALL BEHIND THE SCHEDULE: project miss market window but that can happen to any methodology ... / note: this is very seriously noted at ALM 2012 Conference in Seattle
  • 18. WHEN TO USE AGILE AND WHEN PLAN DRIVEN 10.000 ft view on the difference, and I am not saying this is guideline • AGILE • PLAN-DRIVEN • low criticality • high criticality • senior developers • junior developers • requirements change often • requirements don’t change often • small number of developers • large number of developers • culture that thrives on chaos • culture that demands order beware: plan driven can also be „half-agile” :) for example at planning we use „Progressive Elaboration” and „Rolling Wave Planning” source: „Balancing Agility and Discipline”, Boehm & Turner
  • 19. WATERFALL vs. AGILE I LOOOOVE those comparisons... like the following: „waterfall projects rarely deliver according to a plan” • • • • • • • occassional „customer” involvement VS. frequent „customer” involvement potentially large team size VS. teams of 3-9 people resistant to change VS. change is expected requirements docs VS. just-in-time, informal requirements task are assigned VS. assigned task are a bottleneck multiple phases, eventual delivery VS. working software each Sprint/Iteration contract says what we build, deliver VS. contract is a lot closer to T&E let me tell you a secret... people at „plan-driven” methodologies also want to succeed at project delivery note: this is very seriously noted at ALM 2012 Conference in Seattle
  • 20. so you assemble a team to implement the agile
  • 21. STILL THE SAME OLD QUESTIONS but with different approach... AGILE • Deliver working product in short cycles • Keep the evolving product highly visible • Inspect outcomes frequently • Change our product or processes as we learn more to ensure acceptable outcomes • Do less work that will change APPROACH • Focus less on predictive up front planning • Focus more on delivering value • Focus more on collaboration with the business • Focus more on engaging the team „when the project will be done? how much it will cost? what will be delivered? what are the risks?” note: there are some additional questions, but you already know them...
  • 22. MAPPING PMI KA vs. AGILE i mean, not really, but to external people, it might look like that we did exactly that... • PMI KNOWLEDGE AREAS • integration • scope, time, cost • quality • people • communication • risk • AGILE • manifesto • principles • best practices agile is „numbers and charts” like any other methodology note: we are still waiting for a formal adoption of agile in PMI world, regardless of ACP
  • 23. PROJECT MANAGEMENT @CORP one can find all forms of mix/match orgchart projects at the corporation Business Management System PROJECT1 PROJECT 2 PROGRAM1 • Agile must comply with the „Business Management System” • Agile requires some type of Project Management System tailored to methodology AGILE SUBPR 1 SUBPR2 PROJECT3 PROJECT4 NONAGILE PROJECT MANAGEMENT IS STILL REQUIRED Note: „Agile & Project Management”, Michael Milch, 2011
  • 24. ANOTHER VIEW... of functional mapping between PMI processes and agile involvement PROJECT INITIATION Release Release PLANNING EXECUTING MONTORING AND CONTROL CLOSING PROJECT Planning Business case or Feasibility Study Project kickoff and visioning meeting Release roadmap planning Iterative and incremental delivery of working software Regular review of deliverables, progress and process Project retrospective RELEASE Roadmap and release definition Release planning meeting Iterative and incremental delivery of working software Regular review of deliverables, progress and process Release retrospective ITERATION Iteration planning meeting Iteration planning meeting Work features through to completion (including testing) Task boards, burndown charts, daily standups, acceptance of completed features Iteration demo, review and retrospective Retrospective RELEASE Release Planning Iteration Iteration Retrospective Daily Work Daily Work Retrospective ITERATION Iteration Planning Like the project life cycle, we can map the process groups to the agile fractal – at the overall project level, at the release level and at the iteration level. plan driven hidden inside the agile :) the process groups are not phases, but rather they are integrated set of processes applied iteratively throughout the project and revised as needed paper: „Agile Project Management and PMBoK Guide”, PMI Global Congress Proceedings, Michele Sliger, 2008
  • 25. ANOTHER VIEW... of functional mapping between PMI processes and agile involvement Initiating USE AS IS • • • chartering and identifying perliminary socpe explain where you will use agile to stakeholders organize workshops, seminars, presentations on agile thinking Planning USE W/ MODIFICATIONS • • • • move to iterative planning use plan refactoring to keep the pace with the project HIGH: switch from task to feature themes LOW: use iteration Executing USE AGILE • • • develop iteratively and mitigate technical risks as we progress use meaningful metrics (features delivered and project time remaining) empower the team Controlling USE AGILE • • • iterations review, assist with project steering change requests, defects and risks prioritization controlling flow, look at the holistic view of the project to maximize the delivery Closing USE AS IS • closing processes as defined in PMBoK to be considered plan driven, plan modified, agile, agile, plan driven paper: „Utilizing Agile Principles Alongside the PMBOK”, Mike Griffiths, 2004
  • 26. OR, JUST USE PMI – ACP ? big guns understand PMI and PM methodology. can PMI help us here? DOMAIN I VALUE DRIVEN DELIVERY • • • • defining positive value incremental development avoid potential downsides prioritization DOMAIN II STAKEHOLDER ENGAGEMENT • • • stakeholder needs stakeholder involvement stakeholder expectations DOMAIN III BOOSTING TEAM PERFORMANCE PRACTICES • • • • team formation team empowerment team collaboration team commitment DOMAIN IV ADAPTIVE PLANNING • • • • • • levels of planning adaptation estimation velocity throughput cycle time DOMAIN V PROBLEM DETECTION AND RESOLUTION DOMAIN VI CONTINOUS IMPROVEMENT this is just a certification: agile certified practitioner beware, on PMI PMBoK ver 5, January 2013, 616 pages, not too many agile ideas note: again this is just a cert, one need to implement agile project management @the house
  • 27. so, how can corporations survive agile? send them to the movies... (or, three movies that they have to see...)
  • 28. MOVIE No.1: JERRY MAGUIRE AGILE is about changing the way people work • it is not about the tools people use • it is not about sequences or units of work • it will take some time to accept the org change • people will yell at you „SHOW ME THE MONEY” • crucial: help team develop best practices, define DONE you eat elephant one bite at the time there will be no support for a sudden changes to org practices note: have some friends help you out
  • 29. MOVIE No.2: DUDE, WHERE’S MY CAR? PLEASE, explain stakeholders HOW you measure the progress • primary performance indicators on an agile project: backlog size and velocity • please, explain that to the people in layman’s terms: • Intervals to Complete (Backlog Size/Estimate Per Interval) EQ. Time • Burndown Chart EQ. Scope Delivery • Integration Management EQ. Steel Threads • Scope Management EQ. Working Software Demonstrations • HR Management EQ. Self Managed Teams • Communication Management EQ. Daily Stand-Ups dont expect that CXO’s will understand that there are no milestones and project phases on the project layman’s terms of layman’s terms: „describe a issue using words that the average individual can understand”
  • 30. MOVIE No.3: BACK TO THE FUTURE even project managers are human, think what would be their role at next agile project • now, it is all about people • most project / sales roadblocks are controlled by people that don’t see their future implementing your project • can we find the role for good ol’ „corporate people at pmo”? • but in general, can we move people from Gantt chart? • remember: from authoritarian approach to leading from within project manager’s next career step unfortunatelly, some of your team won’t fit agile note: you cannot develop company-wide plan to retire all project managers at once
  • 31. and a book for THE END there is one book that could help you also • and this one enterprise understands. Messages like: • create a continuous process flow to bring problems to the surface • level out the workload • build a culture of stopping to fix problems, to get quality right the first time • become a learning organization through relentless reflection and continous improvement this is special edition for leadership development executives must drive organizational expectations, build teams and set priorities layman’s terms of layman’s terms: „describe a issue using words that the average individual can understand
  • 32. no time for: appendix?
  • 33. MAPPING PMI KA vs. AGILE i mean, not really, but to external people, it might look like that we did exactly that... • PMI KNOWLEDGE AREAS • integration • scope, time, cost • quality • people • communication • risk • AGILE • manifesto • principles • best practices Let’s look at PMI KA to see how best practices apply
  • 34. Q&A all the burning issues and questions BIG THANKS!
  • 35. PMI INTEGRATION MANAGEMENT • • • • • Start very simple and integrate at each defined milestone Integration is high risk, so dont wait for things to happen Plan for integration as quickly as possible Keep momentum with partner by agreeing to frequent integration with demos Treat interfaces like contracts, define early and manage change carefully • Enable teams to work independetly • Cover positive and false tests • Use automation AGILE: integrate early and often and simulate system note: PMI Global Congress North America
  • 36. PMI SCOPE MANAGEMENT • • • • • • • “Working software over comprehensive documentation” (Agile Manifesto) Require business participation. Listen for new requirements. Break-through design and functionality can evolve form these. “Responding to change over following a plan” (Agile Manifesto) Expect change and design a process and team’s mindset to adapt quickly. Frequent Releases and Short iterations allow for quick reaction to change. AGILE: working software demonstrations, embrace change note: PMI Global Congress North America
  • 37. PMI TIME MANAGEMENT • Determine team’s velocity • Velocity w/ Product Backlog can determine: • Project completion date • How project is tracking to goal • Track and measure team accuracy • Use retrospectives to identify how to improve estimates • Smaller deliverables are easier to estimate • Shorter not longer iterations AGILE: iterations can predict success, estimation accuracy note: PMI Global Congress North America
  • 38. PMI COST MANAGEMENT SCOPE • Business can balance feature richness with Go-To Market opportunity. • Allow scope (feature richness) to be a variable $$ / Resources TIME AGILE: shippable software every iteration note: PMI Global Congress North America
  • 39. PMI QUALITY MANAGEMENT • Auto Build, Deploy, Test • Deployment and validation should happen frequently and be very inexpensive. • If new features break existing features, team knows right away. AGILE: continous integration, note: PMI Global Congress North America
  • 40. PMI HR MANAGEMENT • • • • • • • • Please call this „Human Capital Management” Sprints are not anaerobic The team’s velocity is based on a pace that can be maintained each iteration. Staff Retention & Morale Daily meetings used to identify blocking issues. The team assists. Rotate the Scrum Master Role amongst team members. No de-facto leader Reflect & Learn with each iteration. Encourage critical and honest feedback. AGILE: sustainable pace, self-managed team, retrospectives note: PMI Global Congress North America
  • 41. PMI COMMUNICATION MANAGEMENT 15 min, don’t let them go long! Review progress and identify blocking issues Use a ‘parking lot’ for topics that can’t be covered quickly. Both provide stakeholders great opportunity to track progress and provide input. • Regularly scheduled demos provide a predictable communication plan for stakeholders. • • • • AGILE: daily stand-ups, demos, product backlog review note: PMI Global Congress North America
  • 42. PMI RISK MANAGEMENT • Use SPIKE to uncover unknown items • Integrate early & often • Get feedback from stakeholders as quickly as possible AGILE: mitigate risks as early as possible note: PMI Global Congress North America
  • 43. INTRO just a few words about me so, if • Ratko Mutavdzic is founder of PROJEKTURA, consulting company that work with new and emerging technologies and introduce them to the corporate and enterprise environments. Prior to this one, he spent 15 years Microsoft, starting in a consulting practice and then leading several different sales and technology teams. • He is the author of number of published papers on different aspects of the technology, successful blogs on new technologies and project management, and active contributor in a number of social networks exploring the use and advance of new ways to connect and share innovation and invention. • He frequently speaks on conferences, meetings, workshops, coffee shops and generally at every place where people like to explore, challenge, investigate, think and our heads... we can continue... we all nodinnovate. • Keywords: change, project, program, portfolio, innovation, startup note: more contact info on a last slide
  • 44. more info ... if you feel like you want to know more or just for fun • • • • WWW FBOOK TWEET EMAIL www.projektura.org www.facebook.com/projektura www.twitter.com/projektura info@projektura.org • but if it is really, really, really urgent and you really need to connect to people at projektura ... • SKYPE projektura ratko.mutavdzic@projektura.org dont bite, dont yell at you at all, so please, add me to your ... think network. tnx.