agile pricing models (webinar by luxoft agile practice)
Post on 14-Apr-2017
Embed Size (px)
LUXOFT AGILE PRACTICE
Agile Pricing Models
Luxoft Agile Practice webinarby Sergey Prokhorenko
17 Aug 2016
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.1
Sergey ProkhorenkoAgile coach, head of Luxoft Agile Practice
My name is Sergey Prokhorenko, Im 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).2
Difference between 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
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.3
Top 4 Client ProblemsSource: The CHAOS Manifesto, The Standish Group, 20111. PAYING FOR THE WRONG THINGS50% of money are spent on features which are never or rarely used by real users
2. ALWAYS LATE WITH THE THINGS WE REALLY NEEDEngineers tend to reinventing the wheel and focusing on interesting engineering stuff instead of business priorities
3. TOO EXPENSIVE TO MAKE EVEN LITTLE CHANGESLong change cycles due to complicated change management procedures which consumes time and money
4. DIFFICULT TO UNDERSTAND WHERE WE ARE RIGHT NOWClient is overburden with different reports but have no clue of real progress in terms of working features
Despite leading Agile Practice CoE, I never push our clients for Agile unless theyre 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:4
Perception of Agile as a Silver Bullet
Source: Developing Modern Applications With Agile Outsourcing, Forrester Research, 2014Addressing Agile AD&M challengesDoing right things for businessChange for freeClear progressCross-functional teamswhile following non-Agile SVM restrictions*Greater vendor accountabilityFixed scopeRing-fenced changeShared resource models
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 thats 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 dont end up with fixed scope-schedule-budget engagement, effectively killing most of the value of Agile development methods.
Ill 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 theres many-to-many relationship and I will talk about choosing proper pricing model for specific engagement phase.5
Common Engagement ModelsOutstaffing (Cost+)BOT (Build-Operate-Transfer)Team ExtensionManaged Delivery
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 theres no applications delivery component included into contract, this model isnt interesting from Agile pricing perspective, as process is organized purely by the client management team.
Build-operate-transfer (BOT)is acontractual 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.6
Top Agile Contracting Frameworks @ LuxoftT&MPlain vanilla T&MT&M NTE (not-to-exceed)Good for initial stages (build trust)Measurement unit: man-dayFixed Capacity (Agile Pod)T&M-like pricing, but packaged for a teamVendor responsibility for strong team buildingGood for long-term projects with sustainable requirements flowMeasurement unit: team-sprint (for fully functional team)FP per Work UnitOutput-based pricingVendor margin is based on performanceBest risk management approach for clientMeasurement unit: story point (aligned with pre-agreed Definition of Done)
T&M and T&M NTE
Fixed Capacity (Agile Pods)Fixed price per teamMinimum 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 SoWDefinition 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 sprintsIf team becomes dysfunctional due to attrition (falls under minimal target velocity), vendor is responsible for hiring and training new people, otherwise team isnt billedNot fully managed delivery, as delivery risks stay on the client side
Fixed Price per Work Unit (Story Point)Definition of done and acceptance scenarios agreed before developmentFeatures are demonstrated to customer only if 100% done and meet acceptance criteriaIndicative sizes of user stories (in Story Points) are included into SoWFeatures are billed after UAT closedMonthly payments based on estimates of features accepted within previous billing periodClient is responsible for providing backlog according to Definition of ReadyFeature A Feature B Feature C
Feature ZSprint planning
Feature A (100% done)Prioritized backlogFixed 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 AFeature BIssues and change requests are added to product backlogDoRDoD
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.10
Forming Initial Backlog Product Discovery WorkshopIdentification of key user rolesStory mapping and identification of key functional scenariosForming of product backlog based on user story mapsRelative