The agile pmp teaching an old dog new tricks

959 views

Published on

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

No Downloads
Views
Total views
959
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • 1/8/2008
  • 1/8/2008
  • Talk a bit about traditional Project Management and its fundamental mission Understand its limitations and make a case that agile methodologies can help fill in some gaps. Make a case that agile does not replace what you know about project management but gives you a new set of tools to manage uncertainty Help you understand the principles behind agile project management and talk about how they fit in with the PMI framework Explore how we can use terminology that the business understands to introduce agile principles I am not here to be an agile purists, and agilista. I am here to take a pragmatic look at the agile movement, how we can draw some practical tools that help us in our current projects, and how to get us on the road to delivering more reliable project performance.
  • Do the whole agile elevator speech thing. Main point is to lay the foundation for agile discussion. Provide a point of context to make the link between agile dev practices, project management, and leadership. Not one specific methodology, but a family. We can pick and choose between components. 1/8/2008
  • Provide a common baseline for what is the core activity of project management. This is a setup to show that agile addresses these things too.
  • Transition slide. Want to explicitly state we are talking now about traditional project management. Again, we are laying a framework to contrast agile methodologies and highlight the problems it solves.
  • Talk to the triple constraints, focus on the dynamic relationship between the three project variables. Don’t hit yet on the whole locking the three yet, that will come later.
  • Now we are going to hit each of the three in detail. First we start with scope. This is the starting point for a traditionally managed projects. I can take about how the business decides they want something and they have some idea of when they want it and how much they want to spend.
  • We begin the process of figuring out what how much capital expenditure, contractor dollars, and employee effort it will take to deliver the project.
  • Typical Waterfall 1/8/2008
  • The answer is that we are almost always asked to do it in less time and for less money. This involves doing one of three things: De-scope the project or deliver in phases Fast track it by doing work in parallel
  • 1/8/2008
  • Phasing gets product to market faster Reduces 1/8/2008
  • 1/8/2008
  • Main point is that we now have a schedule and we want to lock the triple constraints. Reinforce that we are putting a lot of faith in our planning. Early in software projects we know the least about what we want to build. Highly uncertain projects we know it is going to change.
  • The answer is that we are almost always asked to do it in less time and for less money. This involves doing one of three things: De-scope the project or deliver in phases Fast track it by doing work in parallel
  • Now we need to indentify those things that lead to change. What are the things that could negatively impact or delivery date? Our project budget? Our project scope? Talk about risk ranking, prioritization, and mitigation strategy.
  • Traditional project management starts with scope as the primary constraint Sure… if the project scope proves to be too big for the organization to deliver, we may descope. But we have done analysis and some design to determine it was too big. This is wasted effort build into the process What this negotiation really tells us, is that in many software projects, scope wasn’t the primary constraint after all. Time and cost were the primary project drivers. What agile is going to do is elevate time and cost as the primary constraints and get real about what we are able to build
  • The planning model assumes we have a good ability to predict what it is we are going to build It assumes we have stable teams It assumes that any other projects we are working on are on scheduel Sure we talk about risk management, and all these things are risks What is our mitigation strategy?
  • The answer is that we are almost always asked to do it in less time and for less money. This involves doing one of three things: De-scope the project or deliver in phases Fast track it by doing work in parallel
  • 1/8/2008
  • Remember, we talked about agile being a project management methodology and a leadership frame work… So… from a project management perspective… let’s look at agile planning
  • This next step is an evolution of our project planning model but does not solve any more of our fundamental scheduling problems. It does allow us more focus on delivery and learn from the process of delivering working software. The thinking goes, if shorter phases are better, and overlapping phases make work go faster, then let's put this approach on steroids. This approach is where I came to know iterative and incremental development. Early in my time as a software project manager, I understood iterative and incremental delivery as a series of shorter, overlapping waterfall projects. As a project manager on these projects, one of my main jobs was to manage that overlap and make sure that people understood what we were working on and when they needed to be available. Even with this level of sophistication in our project planning, even with the resource utilization and timeline gains we have realized, our projects are still going to suffer when requirements change and schedules do not go according to plan. We have solved some of our resource and prioritization issues, but in the process have created a web of interdependencies that only serve to decrease our ability to effectively deal with change. In some ways, our project schedules become even more brittle than they were before. 1/8/2008
  • Iterative and incremental development is not supposed to be a series of overlapping waterfalls. The purpose of iterations is to have all skillsets on deck working toward a common iteration objective. Each iteration has a goal and a set of functionality that it is supposed to deliver. By having everyone focused on the same set of deliverables, we are able to deal with changes within the iteration itself... no one has moved onto other work... no one has to backtrack. Dependencies are contained and cascading impacts can be kept to a minimum. The iterative timeboxes are fixed and do not overlap. The team develops the set of functionality planned for that iteration and reviews the outcome of the iteration as a team. There is opportunity to learn from our progress and take any corrective actions before the next iteration begins. If change is introduced into the project, it gets planned for in the next iteration, and the impact of that change cascades down the project. Most teams that are adopting agile find themselves at this level of project maturity. They have introduced iterative and incremental development but have not embraced some of the other organizational changes that are necessary to make it work. At this point, we still have not solved the problem of people being pulled away from our projects. We are at risk of being impacted by competing priorities... we are not able to function as a cohesive team. Also... there is nothing particularly agile about this approach. We might still be doing a big up front design, traditional change management, and predictive project control. We can acknowledge it is a step in the right direction, but it is not agile. 1/8/2008
  • Moving from iterative and incremental, to something that begins to look agile, you need to shorten even further your delivery cycles and create cross functional teams that are allocated to your projects 100%. By shortening delivery cycles, the project manager can focus less on how product gets delivered and more on what is getting delivered and how fast. The team becomes accountable for meeting delivery objectives, and has more ability to decide what gets done and when. The team can make decision on how to best use their time to meet the goals of the iteration. The project manager gets real empirical data about how the project is progressing in the form of working software. By keeping people 100% allocated to our projects, project managers need to focus less on activity sequencing, this can be delegated to the team. Giving this responsibility to the team allows them to be more creative solving problems. They stop being accountable for doing tasks, they become accountable for delivering value and meeting objectives. Project managers become more focused on tracking the flow of value, removing obstacles that could get in the way, and communicating and collaborating with the rest of the organization. At this level of maturity, project managers are often still thinking with a predictive mindset. They are still trying to predict the flow of value and schedule all the iterations in advance, but have moved to a value focused planning model rather than an activity based planning model. 1/8/2008
  • The agile project schedule is really just the sequence of project releases and iterations. It is the basic cadence of delivery the team has decided to organize around to deliver product. Features are kept in a sequenced backlog and scheduled iteration by iteration based on what we have learned about the evolving product. Project managers measure the flow of feature delivery, iteration by iteration, to communicate to the organization how the team is making progress. If a change needs to be introduced to the project, it can be added to the backlog just like any other feature. The team collaborates with the business to frequently reprioritize. Because we focus on delivering working software on incredibly short cycles, the business gets to decide exactly when it wants to take product to market. 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • Minimize dependencies so sequencing is not as much of an issue Prioritization rules Resource estimating using more abstract techniques like story points Activity duration estimating. All features are less than two weeks Schedule based on time to market, not task duration Schedule control through fixed timeboxes with clearly defined deliverables. 1/8/2008
  • Cost is generally fixed, based on the size of the team. If you have hard costs, fixed capital budgets, that is fine. No constraint from Agile. Costs are inherently controlled through fixed team size and timeboxing 1/8/2008
  • Time and Cost are fixed. Scope is going to vary. Get’s negotiated every sprint. Need to commit to release objectives at a higher level. ROI with less than 100% is necessary Give the team room to negotiate within the defined boundaries. Commit at the right level of Abstraction. DSDM and MoSCoW 80%, 20%, 20% Contract Implications, pull Cockburn’s work 1/8/2008
  • Risk management is inherent in the process Make reference to test first, continuous integration, and automation Show risk curves in Waterfall vs. Agile Deliver highest risk and highest value first. Discuss traditional risk lists. Deal with real risks on the project. 1/8/2008
  • Quality gets built in by the nature of the process Backlog items are 100% complete and tested at the end of the sprint Approved by the customer Test first and automated testing necessary Continuous builds Definition of done sufficient to ensure quality 1/8/2008
  • Keep it light Let the tools automatically generate the data, naturally out of the processes of managing the work Information radiators, PM knows what’s going on all the time Status reports, sure. Better… the team room, stuff on the walls Focus less on managing stakeholders through static communication, build relationships, get people what they need. Light touch. 1/8/2008
  • No conflict with Charter, Scope Statement, Project Management Plan, and Closing the Project Replace Direct and Manage Project Execution with facilitate and guide, measure, hold people accountable Replace Monitor and Control with Monitor and Adapt as necessary Replace Integrated Change control with collaboration If you are changing things not related to software development, integrated change management might be appropriate. Things that come to mind are capital expenditures, consulting dollars, etc. Feel free to have a process in place based on the requirements of your organization and your initial project approvals. Agile is going to call for little to no change management, up to the product owner. 1/8/2008
  • Not generally addressed by agile. Problems arise when having to buy hardware. Lead time etc. Agile assumes software architecture and physical architecture On real projects this is not always the case Encourage tighter collaboration with infrastructure guys Part of the team, building out the physical, prototyping, load testing Build scalable infrastructures. Low initial investment. Proof of concept on lab equipment, loaner boxes. If all else fails, design up front but you are accepting risk. 1/8/2008
  • Efficiency of Agile, light documentation, fast delivery cycles hinges on the quality of the team. Yes, the individuals, but the team too, Quality individuals are an integral part of an agile team Pay attention to team selection ID project roles: self organizing generalists Responsibilites: more fluid Reporting relationships: Scrums, scrum of scrums, self-organizing Staffing management plan: sure, why not. Focused on procedures for taking people on or off the team Retrospectives as a way to enhance team member interactions Less focus on tracking individual performance, more on overall team performance 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • 1/8/2008
  • The agile pmp teaching an old dog new tricks

    1. 1. The Agile PMP Teaching an Old Dog New Tricks
    2. 2. Introductions <ul><li>Product consultant and agile evangelist for VersionOne </li></ul><ul><li>Previously a Senior Project Manager for CheckFree and John Harland Company </li></ul><ul><li>PMP, CSM, DSDM Agile Project Leader </li></ul><ul><li>Board member of APLN and the current Treasurer. Founder APLN Atlanta </li></ul>
    3. 3. Why are we here today ?
    4. 4. What is Agile? <ul><li>Umbrella term to describe a family of methodologies </li></ul><ul><li>Engineering best practices </li></ul><ul><li>Leadership philosophy </li></ul><ul><li>Project management methodology </li></ul>
    5. 5. What is Project Management? <ul><li>When will the project be done? </li></ul><ul><li>How much will it cost? </li></ul><ul><li>Do we all agree on what done looks like? </li></ul><ul><li>What are the risks to delivering time and on schedule? </li></ul><ul><li>How will we mitigate these risks so we can get done </li></ul>
    6. 6. Let’s take a look at Traditional Project Management
    7. 7. Balancing the Triple Constraints <ul><li>There is a dynamic relationship between time, cost, and scope </li></ul><ul><li>When one of the three variables change, there is necessarily a change in one or more of the other two </li></ul><ul><li>Understanding and managing the relationship between these variables the primary job of the Project Manager </li></ul>
    8. 8. Managing Project Scope <ul><li>Project scope is the set of deliverable the project is approved to build </li></ul><ul><li>Defined at a high level in the business case or project charter </li></ul><ul><li>Defined in greater detail in a product requirements document or a work break down structure </li></ul>
    9. 9. Managing Project Costs <ul><li>Project cost is the sum of all capital expenditures, contractor expenses, and internal cost of labor </li></ul><ul><li>Project managers track project expenses in relationship to the budget </li></ul><ul><li>Responsible for making sure the project is spending money at the right rate and time </li></ul>
    10. 10. Managing the Schedule <ul><li>The project schedule defines when all the deliverables should be completed and who is going to do them </li></ul><ul><li>The project schedule also defines the order of the deliverables and is used to track physical percent complete. </li></ul>
    11. 11. Building the Project Schedule <ul><li>Scope for the project is defined and the size of the deliverables are estimated </li></ul><ul><li>Deliverables are sequenced and resource needs are calculated </li></ul><ul><li>Based on the size, available budget, dependencies, and constraints; the project timeline can be calculated </li></ul>
    12. 12. Traditional Waterfall Scheduling
    13. 13. What always happens when we approach the business with our project schedule ?
    14. 14. Add more resources (crashing)
    15. 15. De-scope or phase the project
    16. 16. Overlapping Phases (fast tracking)
    17. 17. Project Baseline and Critical Path <ul><li>Once the project sponsors agree to the schedule, the schedule is locked and becomes the baseline </li></ul><ul><li>Once the project has a baseline, the project manager will calculate the critical path and begin tracking earned value </li></ul><ul><li>Earned value measures how much the project is spending relative to time and deliverables </li></ul>
    18. 18. What about uncertainty ?
    19. 19. Project Risk Assessment <ul><li>What are the factors that could impact our ability to meet our project objectives </li></ul><ul><li>Risk can be categorized by likelihood of occurrence, impact severity, and ability to detect </li></ul><ul><li>The project managers prioritizes risk and create mitigation strategies </li></ul>
    20. 20. Primary Traditional Project Constraints <ul><li>Scope is typically the primary driver… time and cost are calculated based on the size of the project </li></ul><ul><li>Assumes an ability to accurately predict scope, cost, and schedule </li></ul>
    21. 21. So… what’s new about Agile Project Management?
    22. 22. Primary Agile Project Constraints <ul><li>Time and cost are the real drivers… scope has to be able to vary </li></ul><ul><li>Agile is a framework, a new way of looking at product development, that gives the project team the ability to inspect outcomes and adapt accordingly </li></ul>Scope Time Cost Scope
    23. 23. A Fundamental Paradigm Shift <ul><li>Not all projects are predictable </li></ul><ul><li>Market uncertainty drives change </li></ul><ul><li>The less certain we are about our requirements, the more we need to plan to adapt </li></ul>
    24. 24. Agile embraces uncertainty !
    25. 25. Agile is a risk mitigation technique when our assumptions about predictability do not hold
    26. 26. The Cost of Change <ul><li>Cost of traditional change management is too high in many project contexts </li></ul><ul><li>Change control is bureaucratic and slow </li></ul><ul><li>We become resistant to change when we should embrace change </li></ul>
    27. 27. How often to we really take process cost into consideration when planning our projects ?
    28. 28. Still answering the five questions… <ul><li>When will the project be done? </li></ul><ul><li>How much will it cost? </li></ul><ul><li>Do we all agree on what done looks like? </li></ul><ul><li>What are the risks to getting done on time and on schedule? </li></ul><ul><li>How will we mitigate these risks so we can get done </li></ul>
    29. 29. … but taking a difference approach <ul><li>Deliver working product in short cycles </li></ul><ul><li>Keep the evolving product highly visible </li></ul><ul><li>Inspect outcomes frequently </li></ul><ul><li>Change our product or processes as we learn more to ensure acceptable outcomes </li></ul><ul><li>Do less work that will change </li></ul>
    30. 30. … and a shift in focus <ul><li>Focus less on predictive up front planning </li></ul><ul><li>Focus more on delivering value </li></ul><ul><li>Focus more on collaboration with the business </li></ul><ul><li>Focus more on engaging the team </li></ul>
    31. 31. Moving away from activity based Project Management toward value based Project Management …
    32. 32. Not all value based project management is agile …
    33. 33. Proto-Iteration Planning
    34. 34. Iterative Planning
    35. 35. Predictive Feature Based
    36. 36. Agile Project Management
    37. 37. Agile and the PMBOK
    38. 38. Agile and the PMI process groups Initiation Planning Execute Monitor Control Closing
    39. 40. The Importance of Language <ul><li>Companies don’t change over night </li></ul><ul><li>People need to bridge the old language to the new </li></ul><ul><li>Help teams understand new concepts within the old model </li></ul>
    40. 41. Understanding Agile in the context of the PMI knowledge areas…
    41. 42. Project Time <ul><li>Define deliverables not activities </li></ul><ul><li>Strive to reduce dependencies between deliverables </li></ul><ul><li>Prioritize don’t sequence. Work from the top of the list. </li></ul><ul><li>Estimate based on relative size </li></ul><ul><li>Releases and iterations always end on time. </li></ul>Time Management Activity definition Activity sequencing Activity resource estimating Activity duration estimating Schedule development Schedule control
    42. 43. Project Cost <ul><li>Cost is defined by your willingness to invest </li></ul><ul><li>Cost estimates are the product of the team size and project duration </li></ul>Cost Management Cost estimating Cost budgeting Cost control
    43. 44. Project Scope <ul><li>Scope is defined at progressive levels of detail. </li></ul><ul><li>Plan scope, deal with project realities, and make tradeoffs. </li></ul><ul><li>Allow room for scope negotiation when planning project scope </li></ul><ul><li>Collaboration and frequent interaction </li></ul>Scope Management Scope Planning Scope Definition Create WBS Scope Verification Scope Control
    44. 45. Project Risk <ul><li>Business Risk, Technical Risk, and Logistical Risk </li></ul><ul><li>Risk management is built into the structure of the project </li></ul><ul><li>Risks are constantly visible and managed through iterations </li></ul><ul><li>Risk lists, response planning, and mitigation strategies </li></ul>Risk Management Risk management planning Risk identification Qualitative risk analysis Quantitative risk analysis Risk response planning Risk monitoring and control
    45. 46. Project Quality <ul><li>Quality is not an afterthought </li></ul><ul><li>Test first design </li></ul><ul><li>Test driven development </li></ul><ul><li>Continuous integration </li></ul><ul><li>Continuous testing </li></ul>Quality Management Quality planning Perform quality assurance Quality control
    46. 47. Project Communication <ul><li>Communication planning can be thought of in the traditional sense when looking outside the project team </li></ul><ul><li>Collocation </li></ul><ul><li>Information radiators </li></ul><ul><li>Osmotic communication </li></ul>Communication Management Communications planning Information distribution Performance reporting Manage stakeholders
    47. 48. Project Integration <ul><li>Agile has room for a Charter or a Vision statement </li></ul><ul><li>Project management plans and approach statements </li></ul><ul><li>More empowering style of management based on individual accountability </li></ul><ul><li>Change control is built into the process. Tradeoffs managed in real time. </li></ul>Integration Management Charter Scope statement Project Management Plan Direct and Manage Project Execution Monitor and Control Project work Integrated change control Close project
    48. 49. Project Procurement <ul><li>Agile does not deal much with procurement </li></ul><ul><li>Approach contracts with adaptability in mind </li></ul><ul><li>Build relationships based on trust </li></ul><ul><li>Create win-win agreements </li></ul>Time Management Plan purchases and acquisitions Plan contracting Request seller responses Select sellers Contract administration Contract closure
    49. 50. Project Human Resources <ul><li>Staffing based on available people and willingness to invest </li></ul><ul><li>Build your team around motivated people </li></ul><ul><li>Give them what they need to be successful and remove impediments </li></ul><ul><li>Allow teams to self-organize </li></ul>Human Resource Management Human resource planning Acquire project team Develop project team Manage project team
    50. 51. What Can I Do Today ?
    51. 52. Agile Project Management Plans <ul><li>Explain agile processes in the context of an agile project management plan </li></ul><ul><li>Build agile principles into the project charter or project definition document </li></ul>
    52. 53. Feature Based Deliverables <ul><li>Stop putting activities in your project plan </li></ul><ul><li>Focus on outcomes… what are we going to build? </li></ul><ul><li>What capabilities need to be in the system by when? </li></ul><ul><li>Let’s start actually Earning Value </li></ul>
    53. 54. Iterative Planning <ul><li>Do detailed planning on iterative cycles </li></ul><ul><li>Use the data gathered in the planning to do a reality check on your schedule </li></ul><ul><li>Keep a higher level plan, maybe a milestone plan in a traditional PM tool </li></ul>
    54. 55. Daily Stand-up Meetings <ul><li>Increase visibility </li></ul><ul><li>Establish a sense of team work and collaboration </li></ul><ul><li>Shared accountability </li></ul>
    55. 56. Agile PM Model <ul><li>Project Manager as the center of the project </li></ul><ul><li>Project manager as an enabler </li></ul>PM Team Team Team Team Team Team Team Team PM
    56. 57. Incorporate agile values and principles
    57. 58. Empowerment <ul><li>Create the context </li></ul><ul><li>Manage the process not the people </li></ul>
    58. 59. Self-Organization &quot; Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” Dee Hock, Founder and Former CEO of Visa International
    59. 60. Trust <ul><li>Expect the best out of people </li></ul><ul><li>Elevate the individual, give them respect </li></ul><ul><li>Value people and encourage relationships </li></ul>
    60. 61. Accountability <ul><li>Measure results, not processes or steps </li></ul><ul><li>Focus on value </li></ul><ul><li>Inspect the process </li></ul><ul><li>Create a culture of accountability </li></ul>
    61. 62. True Agile Project Planning
    62. 63. Know where you are … Know where you are going … Know what else you need to do to get there…
    63. 64. Great Project Managers take input from reality and deal with it
    64. 65. Resources <ul><li>Traditional Project Management </li></ul><ul><ul><li>http://www.pmi.org </li></ul></ul><ul><li>Agile Project Management and Leadership </li></ul><ul><ul><li>http://www.versionone.com </li></ul></ul><ul><ul><li>http://www.apln.org </li></ul></ul><ul><ul><li>http://www.agilealliance.org </li></ul></ul><ul><ul><li>http://www.scrumalliance.org </li></ul></ul><ul><ul><li>http://www.dsdm.org </li></ul></ul><ul><ul><li>http://www.agilemanifesto.org </li></ul></ul><ul><li>How to contact me </li></ul><ul><ul><li>email: [email_address] </li></ul></ul><ul><ul><li>Blog: http://blog.versionone.com </li></ul></ul><ul><ul><li>Blog: http://www.leadingagile.com </li></ul></ul><ul><ul><li>Presentation: http://www.linkedin.com/in/cottmeyer </li></ul></ul>
    65. 66. Simplifying Software Delivery

    ×