Fixed Price with Agile & Continuous Delivery - #londoncd September 2015
•Download as PPTX, PDF•
2 likes•711 views
Fixed Price with Agile & CD (or how I learned to stop worrying and love budgetary constraints) Fixed price (or fixed budget) projects can be the antithesis of Agile principles, and can make Continuous Delivery a battle, but they are a staple of many organisations and are often the only way to get a project signed off. We’ll look at some common antipatterns and a few workarounds to make Agile and CD work with Fixed Price projects, making use of the strengths of CD, not just shoehorning it in.
Recommended
More Related Content
Viewers also liked
Viewers also liked (10)
Recently uploaded
Recently uploaded (20)
Fixed Price with Agile & Continuous Delivery - #londoncd September 2015
- 1. Fixed Price with Agile & CD (or how I learned to stop worrying and love budgetary constraints)
- 16.
- 24. Fixed Price, Fixed Resource + Continuous Delivery
- 28. 1. Fixed Price, Fixed Points 2. Fixed Price, Fixed Resource 3. Fixed Price, Minimum Deliverable (set menu) (bar tab) (hybrid)
Editor's Notes
- Been a PM for nearly 10 years Been at softwire for a year and a half At softwire we tailor our projects to suit our client’s needs, so we work with a range of methodologies and commercial models
- At meetups like these, someone always puts up their hand and says, that’s all well and good but You don’t know what it’s like in my organisation You don’t know what my clients are like They have this really strict procurement process No way a project is ever getting signed off without certain conditions
- Fixed Price, Fixed Scope You pay a specific amount, you get a specific thing
- Project is bigger (or more complex) than expected
- Multiple interpretations of requirements
- Over-resourcing to meet a tight deadline (Subject to diminishing returns – man-months are mythical, after all)
- Payment schedule can get out of sync with release schedule (and thus, the delivery of actual value)
- Difficult to adapt when things go wrong, or simply change
- So you’ve got a big, pre-defined scope that has to fit into a fixed budget, probably with a fixed timeline as well There’s nothing stopping you from chopping it up into bite-sized pieces Arranging those pieces into sprints Holding a daily standup meeting and declaring, WE ARE DOING AGILE But if you take a waterfall project and all you do is break it into smaller pieces, you don’t automatically get an Agile project
- All you get is lots of little waterfalls
- So, how can we really do Agile on a fixed price project? How do we take advantage of the benefits of Agile within the constraints of a fixed price project? It so happens…
- A colleague at Softwire is working on a whitepaper weighing up value and certainty in various commercial models (Work in Progress) He’s suggested 3 variations on the fixed price model All 3 of them present an opportunity to incorporate Agile in a way that improves on fixed price, fixed scope
- Just like a set menu, where you can choose one starter, one main and one dessert If I want the panna cotta instead of the apple crumble, the price doesn’t change The backlog is like a menu: you can choose which stories get included as long as it adds up to the number of points agreed at the start of the project If I want to swap one 5 point story for another, the price of the project doesn’t change Swaps can happen at any point in the project, can be built into sprint planning Makes the project adaptable to change
- Assumption: Swapping stories of equivalent effort / value (you’re not swapping a filet for a salad) Value of a point fixed over the duration of the project? Are all 5-pointers created equal?
- Project: Update bespoke CMS to accommodate a new class of content for a different area of the organisation New content had a much more complex structure CR: Better navigation, including breadcrumbs Estimated the changes Identified lower-priority stories in the backlog not yet started Collaborative discussion to determine what could be swapped to make room for the changes Similar points, similar risk Able to adapt the project scope to incorporate new ideas
- Like hiring a mixologist for the evening with a fixed tab This guy will mix anything you want, no menu required
- But when the tab runs out, the party’s over Essentially a T&M project with a fixed budget
- What is every organisation’s worst nightmare when they have a fixed budget but haven’t fixed the scope up front?
- The unfinished project! The money runs out, work has been done, but we haven’t built anything useful This eventuality is scary enough to drive many organisations to fixed price, fixed scope despite all the downsides
- This is where CD can shine If all check-ins are potentially releaseable, then at any given point, the product is useable. We can stop the project at any time – even before the budget runs out, and we will still have something useful
- Project: Organisation wants to replace horrendous macro-filled excel spreadsheet with a webapp Strictly limited budget Small, fixed project team XP with Continuous Deployment Week by week decided what to build next, close client collaboration Client got exactly what they wanted for their budget Able to follow the principles of XP, even with a fixed budget
- Worth reiterating
- A hybrid
- Fixed scope of must-have functionality, remaining budget used for enhancements
- Project: A new native mobile app that looks great Minimum deliverable: The basic functionality of the app, it loads the content, it renders it correctly, it’s navigable Extras: “UI sugar” Design team came up with a bunch of ideas which were estimated and prioritised – a backlog Dev team stepped through the list, working side by side with the designers to get them right, regularly checking in with the client on which design ideas to work on next Client was very pleased with the results and how the “UI sugar” budget was put to use This approach eliminated the risk of getting bogged down with “gold plating” at the expense of essential functionality