Agile schedule vs. scope workflow
•Télécharger en tant que PPTX, PDF•
0 j'aime•873 vues
A short look at how Scope vs. Schedule works in Agile development with a focus on moving from Estimates equally commitments to Estimates equally "educated guesses".
Recommandé
Recommandé
Contenu connexe
Similaire à Agile schedule vs. scope workflow
Similaire à Agile schedule vs. scope workflow (20)
Dernier
Dernier (20)
Agile schedule vs. scope workflow
- 1. Scope vs. Schedule in Agile A Gorilla Coach Guide
- 2. Joel Bancroft-Connors – Enterprise Agile Coach Hogarth is the Gorilla in the room. The elephant in the room is an obvious truth that is being ignored. The 800 pound gorilla is something that can act the way it wants without regard for others. The Gorilla in the Room is that looming problem that has the power to crush your project into dust and leave you wondering what was the license plate of the bus you were just tossed under. Hogarth © J Bancroft-Connors 2@JBC_GC I believe in a Better World By helping individuals to be better, The team is made better Better teams lead to better projects Better projects lead to better products Better products lead to a better company Better companies can and will make a better world
- 3. • To get the comments section, with full text, download the PPT presentation here: • https://www.dropbox.com/s/hiauhykmulag5d k/Gorilla%20Agile%20Schedule%20vs%20Scop e%20Workflow%20.pptx?dl=0
- 4. Not Flexible Low Flexibility High Flexibility Most Flexible Quality Scope Schedule Resources © J Bancroft-Connors @JBC_GC
- 5. Not Flexible Low Flexibility High Flexibility Most Flexible Quality X Scope Schedule Resources © J Bancroft-Connors @JBC_GC
- 6. Not Flexible Low Flexibility High Flexibility Most Flexible Quality X Scope Schedule Resources X* © J Bancroft-Connors @JBC_GC
- 7. SCOPE DRIVEN
- 8. Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Scope Driven 1st Estimate ~50% accurate Schedule Release
- 9. Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Scope Driven 1st Velocity Report ~70% accurate Schedule Release
- 10. Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Scope Driven 2nd Velocity Report ~80% accurate Schedule Release
- 11. Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Scope Driven 3rd Velocity Report ~90%+ accurate Schedule Release
- 12. Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Scope Driven 3rd Velocity Report ~90%+ accurate Schedule Release Deliverable Deliverable Deliverable New feature since planningDeliverable Release Date
- 13. Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Deliverable Scope to Schedule Driven 3rd Velocity Report ~90%+ accurate Schedule Release Deliverable Deliverable Deliverable Removed from Release Deliverable Deliverable Deliverable
- 14. SCHEDULE DRIVEN
- 16. Del Del Del Del Del Del Del Del Del Del Del Deli Schedule Driven MS 1 MS 2 MS 3 MS 4 MS 5 MS 6 Release MVP Line - The “No point in releasing” cut-off
- 17. Del Del Del Del Del Schedule Driven MS 1 MS 2 MS 3 MS 4 MS 5 MS 6 Release Estimate ~50% Accurate Release Line: How Much Work Do We Think We Can Do MVP Line Del Del
- 18. Del Del Del Del Del Schedule Driven MS 1 MS 2 MS 3 MS 4 MS 5 MS 6 Release Estimate Del Del Del Velocity Trend ~60% Actual Work Complete
- 19. Del Del Del Del Del Schedule Driven MS 1 MS 2 MS 3 MS 4 MS 5 MS 6 Release Estimate Del Del Del Velocity Trend Del Del Del Del Del Velocity Trend ~70 Actual Work Complete
- 20. Del Del Del Del Del Schedule Driven MS 1 MS 2 MS 3 MS 4 MS 5 MS 6 Release Estimate Del Del Del Velocity Trend Del Del Del Del Del Velocity Trend Del Del Del Del Del Velocity Trend ~80% Del Del Del New feature since planning Actual Work Complete
- 21. Del Del Del Del Del Schedule Driven MS 1 MS 2 MS 3 MS 4 MS 5 MS 6 Release Estimate Del Del Del Velocity Trend Del Del Del Del Del Velocity Trend Del Del Del Del Del Velocity Trend Del Del Del Del Del Del Del Velocity Trend ~90% Del Del Del New feature since planning Actual Work Complete
- 22. Del Del Del Del Del Schedule Driven MS 1 MS 2 MS 3 MS 4 MS 5 MS 6 Release Estimate Del Del Del Velocity Trend Del Del Del Del Del Velocity Trend Del Del Del Del Del Velocity Trend Del Del Del Del Del Del Del Velocity Trend Del Del Del Del Del Del Del Final Release Del Del Del New feature since planning
- 24. Del Del Del Del Del Schedule Driven The Other Reality MS 1 MS 2 MS 3 MS 4 MS 5 MS 6 Release Estimate Del Del Del Velocity Trend Del Del Del Del Velocity Trend Del Del Del Del Velocity Trend Del Del Del Del Velocity Trend Del Del Del Del Velocity Trend Hofstadter's Law in action
Notes de l'éditeur
- A project normally has four levers that it can adjust to impact what and when it is delivered. These are Quality, Scope, Schedule and Resources. Taking a prioritized backlog approach, none can be equal in priority. One is always more or less flexible than another. Using this chart each column can only have a singe X.
- Quality is non-negotiable. It gets the Not Flexible column. Our service and our customers does not have a tolerance for quality related issues. If we were a freeware app on the iPhone, it might be different.
- Next it is pretty much a given that resources are your most flexible lever. Whether it is hardware or head count, this is almost always the most flexible lever we have to work with. That said, we do have to keep in mind the laws of diminishing returns and the mythical man month. When you are 90 percent of the way into the project, you can’t double your headcount and expect it to magically fix all your schedule issues. So this leaves us with just Scope and Schedule as the levers we look at.
- If we decide on a scope driven release, then this is the way it will work.
- If we decide on a scope driven release, then this is the way it will work. We start with the complete list of desired features, we’ll use Eagle Deliverables for this example. Engineering reviews the total scope and does an estimate on the work to be done. This initial estimate is likely no more than 50% accurate. If it’s something you’ve done a dozen times before this may be higher and on greenfield projects almost never will you get higher than 50% accuracy. It is also important to note that the margin of error will never go in favor of early. The 50% accuracy is you’ll ship by a given date and not that it will ship later.
- It is only once work has been started that you will start to get any higher accuracy. It will take two to four sprints to get a reasonable velocity trend going (depending on the overall length of the project). This first velocity report will give a brand new date estimate. It could have no bearing on the original estimate as engineering is now doing work and has a better idea of what is going on. The new date estimate though is going to be more accurate than the original estimate, because it is using real trend data.
- Roughly halfway through the estimated project, you’re velocity trending report will improve in accuracy even more. This is about the time you can start to plan your release as the margin of error will probably have dropped into a few week range.
- And three quarters of the way through the project is when you get to a point you can start looking at a specific release date, or in agile terms, a specific iteration you’ll be done by. It should be noted you’ll almost never get more than 95% accuracy. There is always something that can go wrong. Now if the backlog is well prioritized, and the teams work to that, it means you might be able to ship with a smaller scope sooner than the estimates. When the true MVP is complete, you can release and the dev team can either keep building or stop and start something new.
- Of course, when was the last time a product’s features didn’t change during development? With a Scope driven release two things can happen. In this example, the new work is added to development and the release date is pushed out. These features need to be there and so does everything else already in the plan.
- So what will nearly always happen, is that your Scope driven release becomes a Schedule driven release. Once the business has even an estimated schedule, it becomes the working plan. So when new features come up, existing features are removed from the release so that the current schedule estimate is not changed. What this means is that the closer you get to the release, the less flexibility you have to change the release. And it means that the reality is that Scope driven is release a myth and all projects are Schedule driven.
- If we decide on a schedule driven release, it works the reverse. This can be hard for people to wrap their heads around as then uncertainty can seem higher. It requires more discipline to manage this.
- You start with the same prioritized backlog as with a scope driven release.
- The business then decides what date they want to be released by. They should also provide a “true” MVP. That which marks where the business would not even consider shipping. On the iPhone this was probably “can work as a standard cell phone, do email and have a mobile browser”. Remember that when the iPhone first shipped, Apps were more an idea than a reality. This is when engineering gets to work.
- They start again with an estimate. Now though, instead of how many iterations it will take, it is what features can be ready by the release. As with Scope driven, this initial estimate is not going to be accurate. For a repeat program you could get up to 80%. For greenfield projects, 50% is the best you can hope for. If the engineering estimate does not cover the MVP, this is when you go back to the drawing boards. You don’t start a project, with a fixed date, if you don’t have confidence you can get that must ship set of features. This may mean you redefine must ship, it may mean you scrap the project. Maybe some company decided to try and compete with the first iPhone. Only after looking at their MVP and a must ship date of 10 months after the iPhone shipped, they found out they couldn’t do it. So they scrapped the project because they knew Apple would come out with another phone in a year and they couldn’t even compete with the first phone. This does underline that your backlog must be well prioritized. You can’t have 10 P0s features when engineering thinks they can only ship seven features. If engineering gets to decide which of the 10 P0s they will ship, it will likely be the seven easiest, not the seven most valuable. So if the MVP is in the initial engineering estimate, then the development begins.
- The first velocity trend report, two to four iterations in, will give you the first reality check on what will be ready by the release date. And it’s also often going to be the first panic moment. On new projects, you’re initial velocity will almost always be lower than expected at first. This is normal and most teams will recover from the initial bumps and mis-starts to improve.
- By the second velocity check, you’ll have a much better idea of what will be done by the release date.
- Teams that hit high productivity (Norming or Performing on the Tuckman scale) may well exceed their initial estimates. This can also be done through strong enforcement of small work items. The shorter your cycle times, the more work you can complete. New features in schedule driven releases are handled very simply. If you add a new feature, you must remove an equally sized feature. The product is date driven and you have working velocity trends. The only way to add more scope, without removing scope is to reduce quality. Organizations will often try and get around this with the age old “we’ll just work more hours”. Science has shown us that this is not only not sustainable (leading to burn out and turn over of staff after release) it has also shown us that this “weekend” work introduces an outsized number of defects. So the “we’ll just work harder” only leads to a reduction in quality.
- As we get close to the release date, we finally get a firm handle on what will be in the release. In this example, the MVP is complete and so is one new feature added after development started.
- And we come to final release date. We get the MVP plus two features added during development.
- That’s best case though. Hofstadter is a cognitive scientist who first came up with this law to explain why computers were still unable to beat human chess masters. His law is a basis of the Mythical Man Month and essentially tells us that until we’re actually doing work, we won’t be able to have an idea when we’ll be done. And even then we may have things that come up to interfere. So when planning, never take your best case plan and put money on it.
- Here is an example of Hofstadter’s Law in action. This serves as a good reminder that we should never fully load development with MVP as you may not even get the initial estimate so make sure development has buffer to deal with the unforeseen.