EV Agile Mashup Measures Progress
•Als PPTX, PDF herunterladen•
0 gefällt mir•75 views
This document discusses connecting Earned Value Management principles with Agile development methods. It outlines how 11 criteria from Earned Value Management have direct connections to 12 principles of Agile. Specifically, it maps things like work breakdown structure, schedule, budget, and variance measurement between the two frameworks. The document advocates that regardless of development method used, measuring physical progress against plan is critical for project success.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (18)
Ähnlich wie EV Agile Mashup Measures Progress
Ähnlich wie EV Agile Mashup Measures Progress (20)
Mehr von Glen Alleman
Mehr von Glen Alleman (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
EV Agile Mashup Measures Progress
- 1. A Mashup for Two Emerging Ideas Earned Value Management meets Agile Development Starting with Earned Value, the principles of Agile have a one-for-one connection between 11 EV criteria and 12 principles of Agile
- 2. A Face With A Name 2
- 3. Our approach for tonight 3 Earned Value Management is a tool for measuring physical progress The “value” of Earned Value is not business value. It is “dollars” compared to the Planned Value – the budget for the planned work. The 5 Immutable principles include measures of progress to plan. No matter the development “method” these principles must be in place for success. This is especially true for Agile methods in the
- 4. First some breaking news 4 Early and continual involvement of the user; Multiple, rapidly executed increments or releases of capability; Successive prototyping to support an evolutionary approach; and Modular, open-
- 5. What does this mean? 5 Government (DoD) procurement of IT systems will always be based on Earned Value Management for programs > $20M. DoD has embarked on an effort to incorporate “agile” principles in the acquisition process. You’re engaged in a Master’s Program, where there is a sea change in how mission critical software is developed.
- 6. 1. Where Are We Going? 2. How Do We Get There? 3. Do We Have Enough Time, Resources, And Money To Get There? 4. What Impediments Will We Encounter Along The Way? 5. How Do We Know We Are Making Progress? IRREDUCIBLE Of Project Management Project Success 6/17
- 7. Can we tell where we are going? Do we have a path to get to done? Do we have everything we need to get to done? What’s going to stop us from getting done? How do we know we’re making progress toward done? So What Does All This Have To Do With Software Development Methods? When we look at any software development method – no matter the method – can we answer these questions with any level of confidence? If we can’t say this with confidence, then how can we convince those funding our efforts to be happy with us spending their money? 7/17
- 8. 1. Where Are We Going? Eliciting Requirements Is Domain Dependent “Design and integrate 18 major weapon systems and platforms simultaneously within strict size and weight limitations, while synchronizing the development, demonstration, and production of as many as 157 complementary systems with the Future Combat System content and schedule.” (This is an actual requirement) Implement the 8 stories for our new warehouse inventory package tracking system using the existing web site platform as a starting point. 8/17
- 9. 2. How Do We Get There? Some problems respond to lightweight approaches, like Scrum, DSDM, Crystal, and XP as product development methods. Others require more complex approaches, like a System of Systems (SoS) spiral development processes. In all cases a disciplined approach increases the probability of success – no matter the complexity of the problem or the solution This approach works well when we don’t know what “done” looks like with enough clarity So Does This! 9/17
- 10. 3. Do We Have Enough Time, Money, And Resources To Get There? A Common Problem A Simple Solution We have undue optimism Use documented procedures – no matter the method – for estimating and planning using historical data. We attempt to avoid risk and uncertainty Understand and prioritize risks for each critical component empowers management and staff. Use this knowledge to control your optimism. We rely too much on intuitive judgment Simple statistical models are more often correct than the human judgment. Have the number to back up your intuition. The Rational Planning of (Software) Projects, Mark C. Paulk, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213–3890 10/17
- 11. Risk Management Is How Adults Manage Projects ‒ Tim Lister 4. What Impediments Will We Encounter Along The Way? 11/17
- 12. 5. How Do We Know If We Are Making Progress As Planned? The only measure of progress is the Physical Percent Complete for the planned deliverables A Physical Percent Complete means tangible evidence of the outcomes that were planned – measured at the time they were planned to be delivered. B This is the basis for full Earned Value Management with physical percent complete. This is also a natural a fit with the agile approaches to software development. C All successful methods measure the evidentiary outcomes in units meaningful to the stakeholders. These units are usually “money” and “time.” D 12/17
- 13. An Opening Thought† 13 † Integrating Risk Management with Earned Value Management, NDIA, http://www.ndia.org/Divisions/Divisions/Procurement/Documents/PMSCommittee/Com mitteeDocuments/WhitePapers/Integrating_RM_with_EVM.pdf
- 14. Core Principles for Connecting the Dots14 Earned Value Management Agile+ Measures of progress in units of “physical percent complete.” Each iteration produces 100% working products. Forecast of future performance provided by past performance. Measure of performance in units of product produced. A systems approach to the development of products and connecting cost, schedule, and technical performance. Increasing fidelity of product and problem understanding takes place after each iteration and release.
- 15. We’ve All Seen This Before On Our Programs That Follow Strict EVMS† 15 † John Rusk’s www.agilewiki.com
- 16. 12 Agile Manifesto Principles 16
- 17. Our Path Starts With The 32 Criteria Of ANSI / EIA–748–B17 The 32 EVM Criteria are all designed to deliver value. These 11 are the basis of “connecting the dots.”
- 18. Here’s A Quick Look at the Connections 18 # EVM Criteria Agile Approach 1 Define WBS Features and Stories define tasks 2 Identify Organization Self organizing teams 5 Integrate WBS and OBS Self organized teams with a customer 6 Schedule Work Iterations and Releases 7 Identify Products & Milestones Working software at the end of iterations 8 Set time phased budget Fixed length iterations and releases 16 Record direct costs Fixed staff = Level of Effort 23 Determine variances Velocity measures missed features 25 Sum data and variance Missed features moved to next iteration 26 Manage action plans Replan missed features, adjust
Hinweis der Redaktion
- The five irreducible principles of project management are: Know where you are going by defining “done” at some point inf the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.
- When we speak about project management in the context of product development or service providing, we apply these 5 questions to the “project” as a whole. Ignoring for a minute the development method used to actually produce the product or the service. If we start with the method, then we will miss the critical success factors for the project and focus on the means rather than the end.
- The key here is that requirements tell us something about where we are going. But requirements come in all shapes and sizes. Here’s a sample of two extremes. A small project and a not-small project. The small project is straight forward in terms of requirements. There is a list of them on the flip chart. They are likely well understood. They probably can be estimated in terms to cost an schedule. And most importantly the interactions between the requirements can be intuited with a little effort. The project on the right is a different class of effort. This is the top level component (if you can call them that) arrange of the Future Combat System. It’s a $35B, that’s billion with a B program to restructure the entire US Army Battle Space Management processes. I help one of the teams – the Class I team – build their Performance Measurement Baseline and get that information into a cost and schedule management system, so they can use Earned Value Management to “manage” their program. FCS is a software intensive system, where software is in everything from small hand held devices to major buildings housing the “battle space management command.” Software doesn’t work, the FCS doesn’t work. Soldiers can’t do their job. Soldiers can’t o their job – BIG PROBLEM.
- Now that we know where we want to go, the next question is how to get there. How do we build the products or provide the services needed to reach the end of our project. There are numerous choices, depending on the domain and the context of the project in that domain. For the software domain there are many context’s. Using the example on the previous page, let’s look at two methods. These are the extreme ends of the spectrum of contexts and methods. They can serve to focus the discussion on project management rather than product development methods, by hopefully disconnecting project management from product development so we can look at them separately. In the first software development context – a list of features, SCRUM is a popular approach. But there are many more software based project, possibly more complex than the example from the previous page to the “wickedly” complex program also shown on the previous page. The SCRUM method is shown in its common diagram. But below it is the method used for product development in the US Department of Defense – DoD 5000.02. The products are not actually developed by the DoD (except in rare cases). But are instead, procured. So acquisition management is guided by this process. While few here – I’ll assume work in the DoD 5000.02 context, there are direct connections between SCRUM and this approach. Both are iterative, both are incremental, both can deal with emerging requirements, both make use of “test driven planning,” and both have clear and concise measures of physical percent complete.
- No that we know where we’re going and how to get there – do we have all we need to reach the end? Staff, time, money, the necessary skill and experience and the proper management support. These are all obvious on any project – at least any well managed project. But there are always underlying issues with answering these questions. The first is that management as well as the development organization are always optimistic about the outcome. This is the very nature of project management. Why be pessimistic? Well maybe not pessimistic, but how about realistic? What do we mean when we say realistic? One good word is credible. Credible could be optimistically credible or pessimistically credible. But either way we have a credible understanding of what it takes to reach the end. One part of credible is knowing what the risks and uncertainties are and how we are going to dealing with them. Managing in the Presence of these uncertainties is critical to reaching our goal. Risk and uncertainty never go away. They are always there. They are unavoidable.
- There are many phrases about managing in the presence of risk. Tim Lister’s is a good one. Another is Kent Beck’s Optimism is the disease of software development, feedback is the cure. Getting feedback is built into Scrum. It is also built into DoD 5000.02. The two opposite ends of the development method spectrum – both share the same core values.
- With the information from the previous 4 irreducible principles, we now need to confirm we are making progress. The key principle here is “planned progress.” We must pre-define what progress we must make at any specific point in the project, otherwise all we can determine is the passage of time and the consumption of money. Preplanning the progress is the basis of “performance based” measurement for both project processes and technical products. Like Kent Beck’s advice we need feedback on our progress. There is only one kind of feedback for projects – measures of physical percent complete. No soft touchy feely measures of progress. No hand waving measures. Physical, tangible evidence of progress. Something that can be physically shown to the customer. Something that is compliant with the planned technical outcomes at this point in the plan. Scrum does this by predefining the outcomes of the iteration. DoD 5000.02 does this as well with the Integrated Master Plan and Integrated Master Schedule. So looking two extremes of the spectrum – one a software development method and the other a mega-program procurement method. Both share the same principles and outcomes. Something that is tangible and measurable at incremental steps along the way to “done.”