Downloaded 51 times
Uploaded bySergey Prokhorenko
Agile Pricing Models (webinar by Luxoft Agile Practice)
The document presents a webinar on agile pricing models by Sergey Prokhorenko from Luxoft, discussing differences between delivery models and pricing approaches, along with common pricing models for agile projects. It highlights several client challenges with current practices, including issues with feature usage and change management, as well as outlines various contracting frameworks and engagement models for agile projects. The content emphasizes the importance of aligning pricing models with business needs and enhancing vendor accountability throughout the agile development process.
More Related Content
Similar to Agile Pricing Models (webinar by Luxoft Agile Practice)
![谷歌留痕技术教程[ 𝙩𝙤𝙥 𝟮𝟯𝟯. 𝙘 𝙤𝙢 ]](https://cdn.slidesharecdn.com/ss_thumbnails/top233-260130173900-2eb784f9-thumbnail.jpg?width=640&height=640&fit=bounds)
Agile Pricing Models (webinar by Luxoft Agile Practice)
- 1. www.luxoft.com Agile Pricing Models LuxoftAgile Practice webinar by Sergey Prokhorenko 17 Aug 2016
- 2. www.luxoft.com Sergey Prokhorenko Agile coach,head of Luxoft Agile Practice sprokhorenko@luxoft.com sergeyprokhorenko
- 3. www.luxoft.com Session Plan Differencebetween a delivery model and a pricing approach Common pricing models for Agile projects Delivery and billing approach for Agile fixed price Choosing specific model for the particular engagement phase Q&A
- 4. www.luxoft.com Top 4 ClientProblems Never 45% Rarely 19% Sometimes 16% Often 13% Always 7% Actual use of requested features Source: The CHAOS Manifesto, The Standish Group, 2011 1. PAYING FOR THE WRONG THINGS 50% of money are spent on features which are never or rarely used by real users 2. ALWAYS LATE WITH THE THINGS WE REALLY NEED Engineers tend to reinventing the wheel and focusing on interesting engineering stuff instead of business priorities 3. TOO EXPENSIVE TO MAKE EVEN LITTLE CHANGES Long change cycles due to complicated change management procedures which consumes time and money 4. DIFFICULT TO UNDERSTAND WHERE WE ARE RIGHT NOW Client is overburden with different reports but have no clue of real progress in terms of working features
- 5. www.luxoft.com Perception of Agileas a Silver Bullet Source: Developing Modern Applications With Agile Outsourcing, Forrester Research, 2014 Addressing Agile AD&M challenges… Doing right things for business Change for free Clear progress Cross-functional teams …while following non-Agile SVM restrictions* Greater vendor accountability Fixed scope Ring-fenced change Shared resource models
- 6. www.luxoft.com Common Engagement Models Outstaffing(“Cost+”) BOT (Build-Operate-Transfer) Team Extension Managed Delivery
- 7. www.luxoft.com Top Agile ContractingFrameworks @ Luxoft T&M - “Plain vanilla” T&M - T&M NTE (not-to-exceed) - Good for initial stages (build trust) - Measurement unit: man- day Fixed Capacity (Agile Pod) - T&M-like pricing, but packaged for a team - Vendor responsibility for strong team building - Good for long-term projects with sustainable requirements flow - Measurement unit: team- sprint (for fully functional team) FP per Work Unit - Output-based pricing - Vendor margin is based on performance - Best risk management approach for client - Measurement unit: story point (aligned with pre- agreed Definition of Done)
- 8. www.luxoft.com T&M and T&MNTE Pros • Least formal contracting framework • Easy scaling • Good for team extension model Cons • Vendor is not accountable for result • Uncontrollable spending (for standard T&M) • Low-level engagement with lower margin
- 9. www.luxoft.com Fixed Capacity (AgilePods) Fixed price per team - Minimum team setup is defined upfront (e.g. 3x senior Java developers, 1x QA/BA, 1x BA/QA – one of them plays Scrum Master role) - Team minimal target velocity is agreed in SoW - Definition of Ready and Definition of Done is contracted (if needed) Billing for every complete cross-functional team (T&M rates + extra margin to cover team forming stage and attrition risks) per sprint or several sprints If team becomes dysfunctional due to attrition (falls under minimal target velocity), vendor is responsible for hiring and training new people, otherwise team isn’t billed Not fully managed delivery, as delivery risks stay on the client side
- 10. www.luxoft.com Fixed Price perWork Unit (Story Point) Definition of “done” and acceptance scenarios agreed before development Features are demonstrated to customer only if 100% done and meet acceptance criteria Indicative sizes of user stories (in Story Points) are included into SoW Features are billed after UAT closed Monthly payments based on estimates of features accepted within previous billing period Client is responsible for providing backlog according to Definition of Ready Feature A Feature B Feature C … Feature Z Sprint planning Feature A (100% done) Prioritized backlog Fixed sprint duration (2 weeks) Demo (100% done features only) Feature A Feature B (100% done) Feature C (85% done) Feature B UAT (1-2 weeks) Feature A Feature B Issues and change requests are added to product backlog DoR DoD
- 11. www.luxoft.com Forming Initial Backlog– Product Discovery Workshop Identification of key user roles Story mapping and identification of key functional scenarios Forming of product backlog based on user story maps Relative sizing of user stories in a backlog Identification of acceptance criteria for top priority stories Predicting team velocity and planning of first development sprint Release roadmap
- 12. www.luxoft.com 36% OF FEATURESARE REALLY USED BY BUSINESS CUSTOMERS AGILE (BUSINESS VALUE-ORIENTED) Feature A Feature B Feature C … Feature Z “Big Bang” acceptance Never 45% Rarely 19% Sometimes 16% Often 13% Always 7% WATERFALL (PLAN-ORIENTED) Source: The CHAOS Manifesto, The Standish Group, 2011 Never 10% Rarely 10% Sometimes 27% Often 24% Always 29% Feature A Feature B Feature C … Feature Z Small batch Small batch Small batch Small batch Small batch 80% OF FEATURES ARE USED BY BUSINESS CUSTOMERS Based on Luxoft experience Agile Fixed Price (per Story Point) Savings
- 13. www.luxoft.com Engagement Transformation Grow andScaleBuild Trust Hiring Environment and Infrastructure setup Business Domain Induction trainings Engage Duration and Contract Team Structure Cross-functional, cross- component feature team Local PO proxy Hiring Fostering Advanced Domain and Product Expertise Building Hyper productive teams Introduction Build-in Quality Luxoft DC Activities and Results Core team of 5-7 team members Luxoft Agile COE Support Engagement assessment Core Team Interviews Strategy development Agile 101 & Sprint 0 Workshops and Trainings Ongoing Team Coaching Foster Relationships with Client Setup/Engage Local Community of Practice Team Mentorship Grow/Scaling Workshops Build-in Quality Workshops Performance and Quality Boosts Coaching Staffing completed Strong domain & engineering expertise Stable Velocity On-site Coordinator Pool of Feature teams Scrum of Scrums Business Requirement Streams 3-6 months T&M Fixed Price per Capacity N/A Fixed Price per Capacity Fixed Price per Work Unit 1-3 months T&M
- 14. www.luxoft.com Engagement and PricingModels Compatibility Fixed Price per Work Unit Fixed CapacityT&M (T&M NTE) Team Extension Managed Delivery + + + + - +/-
- 15.
- 16. www.luxoft.com Luxoft Agile PracticeTrainings ICAgile Certified Professional - Agile Fundamentals https://icagile.com/icagile-certified-professional ICAgile Certified Professional - Business Value Analysis https://icagile.com/icp-business-value- analysis ICAgile Certified Professional - Agile Team Facilitation https://icagile.com/icp-agile-team-facilitation Professional Scrum Master https://www.scrum.org/Courses/Professional-Scrum-Master Management 3.0 https://management30.com/events/two-day-course/ Custom Workshops Registration and more info at agile@luxoft.com www.luxoft.com/agile
- 17.
Editor's Notes
- #2 Hello, we will start our webinar in a couple of minutes, please standby for a while. If you hear me and see the slide deck, please let me know by using chat panel in your Go2Webinar client. You can also use it for asking questions during my talk, I will address most of them during dedicated Q&A slot in the end of the webinar.
- #3 My name is Sergey Prokhorenko, I’m head of Agile Practice Center of Expertise at Luxoft, leading provider of high-end software development services. Our team of coaches and trainers helps delivery teams at Luxoft and our client companies become more effective and increase business agility by frequent delivery of valuable software. I have 15 years of experience in IT, and more than 6 years in Agile projects (as a proxy Product Owner, Scrum Master, Agile coach), during which I trained and coaches many Agile teams delivering products in industries ranging from travel and aviation or mobile startups to investment banking, most of them featuring large scale geographically distributed Agile delivery in a complex engagements with multiple outsourcing vendors. I also speak at conferences, mostly Agile-oriented, including Agile Alliance, Agile Eastern Europe, Agile Days and Lean Kanban Russia. I'm a member of ScrumAlliance and Agile Alliance, Certified ICAgile Professional at International Consortium for Agile (ICAgile) and a Certified Scrum Master (CSM).
- #4 As a head of Agile Practice at Luxoft, I'm often being asked by industry analysts, investor advisors and clients about our Agile framework for distributed delivery. This is a tricky topic for many IT outsourcing vendors, as original implementations of Agile process frameworks (such as Scrum or XP) implied (or even explicitly demanded) that the whole delivery team is colocated with the customer and benefits from good old face-to-face communication. Many companies still try to build their Agile delivery without paying attention to the fact that enterprise-scale geographically distributed client/(multi-)vendor teams require special tools and practices to be effective.
- #5 Despite leading Agile Practice CoE, I never push our clients for Agile unless they’re ready for it. Change of process and corporate culture always comes at a cost and there should be very clear business value to start such changes. Most of our clients operate in a challenging, fast-paced business environment and traditional plan-oriented frameworks generate traditional problems, among which the most frequent are:
- #6 However, in a large enterprise environment, application development & maintenance, engaging outsourcing vendors to improve their delivery capabilities, faces pretty rigid restrictions set up by sourcing vendor management. Most of them have perfect reasoning, but that’s another story, so we as a provider of customer software development services, must bring our expertise in tuning contracts for Agile delivery, so that we don’t end up with fixed scope-schedule-budget engagement, effectively killing most of the value of Agile development methods. I’ll differentiate between engagement governance model and pricing model in this webinar, the first is mostly the matter of sourcing vendor expertise and trust between vendor and the client. Pricing model, to some extent, depends on the engagement model but there’s many-to-many relationship and I will talk about choosing proper pricing model for specific engagement phase.
- #7 Standard outstaffing is normally pure T&M working on a margin between internal and external rate. Cost+ is a form of engagement where client agrees with your provider on a fixed management cost per employee and negotiates salary directly with each employee. You negotiate it with an employee like you would if you were hiring someone locally, so actually outstaffing vendor is responsible for recruitment and operations, but not for IT services delivery. Since there’s no applications delivery component included into contract, this model isn’t interesting from Agile pricing perspective, as process is organized purely by the client management team. Build-operate-transfer (BOT) is a contractual relationship in which an organization hires a service provider to set up, optimize and run an IT or business process service delivery operation with the contractually stipulated intent of transferring the operation to the organization as a captive center. BOT, as a hybrid model, combines elements of the “build” option (that is, “insourcing” or captive center) and the “buy” option (that is, outsourcing; see also “captive centers”). The ultimate objective is to build a captive center with sustainable operations and delivery model, so the core of the services is also non-IT. Two other models are delivery-oriented with the main difference that in Team Extension model client drives product discovery and delivery processes and vendor staff augments existing onsite delivery teams, while in Managed Delivery vendor is responsible for meeting cost/schedule/scope restrictions and takes accountability for building sustainable delivery.
- #11 Features are estimated by development team and estimates are agreed with business product owner. Development cycle runs goes through two-week iterations and demo is arranged for the client by the end of iteration, which is followed by two-week UAT period (which goes in parallel with new development cycle). Only features which are 100% complete, meet agreed Definition of Done and acceptance criteria, are subject to demonstration and UAT. According to the contract, monthly invoice include payment only for features accepted by business users during UAT phase.
- #13 Due to fast feedback loops and constant refinement of a product backlog, Agile Fixed Price per Story Point model leads to significantly higher value being delivered for the same price. Also, client can choose to end project earlier due to budget constraints or any other external factors, and still have valuable product serving the most important needs of business users.
- #14 Luxoft has significant experience in transition of projects from the T&M model to Fixed Capacity or Fixed Price per Work Unit Agile model. Slide shows high level description of transition model and prerequisites for the transition: First 3-6 months after start of the engagement we use T&M model to get team acquainted with business domain, achieve stable performance and elaborate shared agreement on Work Unit size. Once these preconditions are met, contract could be switched to Fixed Price per Work Unit.