Proposal for Customer

- Vinay Aggarwal

Agenda• Business Drivers• Development Constraints• Challenges• Solution and Approach• Enabling Customer• Delivery Plan• Staffing Plan• Release Timelines• Measuring Health Check• Risks• Assumptions

• Dependencies• Communication Plan• Golden Rules of Development• Cost

Customer’s Business DriversBusiness Need

New settlement product to be developed

Request from Customer Augment capacity from off-shore

Development Constraints• Scope not known at this stage • Forward looking technology – yet to be identified• End users spread across Europe and Australia• Increased complexity - Integration with existing products• Existing products have very limited test automation (code coverage 20%)• Engineering practices not automated (e.g. build, test automation)• No prior experience of customer in modern development methodologies• Limited Subject Matter Expertise

Challenges• Existing Development Constraints• Additional challenges : Offshore

– Geography– Time zones– Culture– Different standards– Shared ownership?– Knowledge gap (technology and business)

How do we bridge the gap?

=

Can one strategy solve all challenges?

Yes

Offshore IT engineers : knowledge workers• This means they are motivated by:

• Responsibility• Involvement in decision making• Problem solving• Technical excellence• Delivering quality• Influencing your own environment• Personal development• ….

• Just like UK employees! It is these factors that we can connect on, despite known challenges and any other differences.

Mixing both worlds: killer combinationAgile hyperproductivity and quality combined with offshoring benefits:

• Focus on Business Value only• Close collaboration of Technology and Business• Availability of talent• Scaling up/down with knowledge retention• Software excellence, Build Quality In• Teams - Equal partner in success• Faster to market, cutting the waste• Business sustainability• Cost reduction

Solution: Fully Distributed Agile

Distributed Development: OneTeam

Enabling Customer : Coaching• 2 Days of Agile training/workshop in London for customer’s key

stakeholders including members from development team• Focus on :

– Benefits How Distributed Scrum solves current business problems How it cuts waste, builds in quality, delivers business value How it gives long terms sustainable business, champions software excellence

– How it works and what it takes to work– Responsibility and obligations : both sides

Delivery Plan : Project Phases

Phase 4 - Business as

Usual : Maintenance

Phase 3 - Roll out

Phase 2 - Roller

Coaster Development

Phase 1 - Proof of Concept

(PoC)

3 Sprints - 6 Weeks

6 Sprints - 12 Weeks

2 Sprints - 4 Weeks

N Sprints – N Weeks

* Number of Sprints are indicative; actual to be determined once prioritized backlog is ready

2 weeks

Prioritized Product Backlog

Sprints BacklogScoped-in User Stories

Daily Collaboration

Working Software

- Close communication- Focus on quality- Focus on added business functionality- Motivated people

Agile means:- Multidisciplinary teams (5-6 members)

- Business sets priorities- Working in small increments- Very high transparency

Delivery : Every 2 WeeksShippableRunning Tested

Features

Agile: Open Kitchen

Phase 1 : POC

UK Team1 Product Owner (PO) + 1 Developer

2 Developers + 1 Tester+ 0.5 Manager

India Team

Co-location

* 0.5 is average for Manager

Phase 1 : PoC

Goals

Success Criteria

• Build One Team : Shared product vision, roadmap and responsibility• Technology, Architecture : Brainstorm, identify, start building• Features: Validate technology, deliver 3 priority features• Set up Common Development Environment and scrum tooling

Proposed Technology working well, Architecture base-lined 2 Features delivered and proves technology working well Product Roadmap, defined and well understood Team dynamics, One team feeling, Intense Collaboration Shared responsibility and collective ownership, team’s are confident Development environment: Set up; Best Engineering practices: In Place

Roadmap of PoC Phase• Handshake, Ice-breaking, Know stakeholders• Explain Product Vision and Roadmap• Start knowing business domain• Understand existing Technologies• Understand products to be integrated• Evaluate Technology, Architecture• Establish definition of done • Setup technical environment, tooling,

engineering practices (TDD, CI, shared code repository, build automation, Sonar)

• Set up Common Wiki, Common electronic Scrum tool such as Mingle or Jira with GreenHopper

• Identify 2 small features, start working on them• Read product documents• Start building product backlog, break down

requirements into Epics/ User stories by PO• Trust building, Relationship building• Informal meetings (e.g. Lunch Together)

Sprint 1• Start developing person repo• Have shared Product Vision and Roadmap• Continue to learn domain• Full understanding of existing Technology• Have fairly good understanding of products

to be integrated• Start building chosen Architecture • Start using common practices, Refine• Refine technical environment and tooling• Start using Common Wiki, e-Scrum tool• Product Backlog ready for next 2 sprints at

least, well understood• Demonstrate 2 small features end to end• Identify 1 major feature, start developing it• Informal meetings (e.g. Dinner Together)

• Prioritized Product backlog ready• Continue to learn domain on the job• User stories related to product integration

available and understood• Evolve Architecture and freeze• Definition of done working well• Technical env. and tooling working well• Common Wiki, Common e-Scrum tool

delivering value• Demonstrate 1 major feature end to end• Validate distributed setup from India;

engage 4th developer who is joining team from 4th sprint

• Celebrate success of PoC

Sprint 2 Sprint 3

Phase 2 : Roller Coaster Development• India team starts working from off-shore - Fully Distributed Scrum • Scale India team up with 1 Developer

• Distributed Stand-up, Planning, Retro• Close collaboration with London team using digital tools and

electronic media• Skype, Video conference, Online Meetings, Desktop sharing,

Telephone, email, FTP• Bridging distance

• Additional Scrum Practices:• Local stand up, Pre-planning, Local Retro (all time boxed)

Sprint 4 Sprint 5

• Taking maturity of distributed scrum to next level• London team to co-locate with India team• Refine distributed scrum practices, Iron out gaps (if any)• Opportunity for London team and new India team member to

work closely, know each other, build relations, develop repo

Fast Paced full fledged development

Participation of SME, End Users in Demos

TIME LINE

TIME LINE

A Day in Distributed Product Development

8:00 12:00 13:00 14:00 15:00 16:00 17:00 17:0010:00 11:00

9:00 12:30 13:00 14:00 15:00 16:00 17:00 18:0010:00 11:00

Stand up

Stand up

Update Scrum board

Local standup India

London, UKUpdate Scrum board

Typical Sprint

• Team continues to work in distributed mode, delivering value every sprint• Running Tested Features getting ready as per business priority• End of 6th Sprint: Team invites SMEs to demonstrates knowledge of

domain and product; helps refine product, further develops shared vision• End of 7th Sprint, check feasibility of:

– alpha release where end users from Europe, Australia start using the product; give feedback– travel needs (may be 1 week travel of SM or PM) if it helps

• Constant co-location required to ensure team bonding and collaboration remains at highest level

• End of Sprint 9: Beta release – all SMEs and End Users to start using software

Phase 2 : Roller Coaster DevelopmentSprint 9Sprint 6

• Co-locate 1 India team member (Senior) at London• PO to be well prepared and 100% dedicated during• All SMEs and End Users in Europe, Australia to start using the product actively, close collaboration with

PO • Strongly recommend daily meeting among PO, SMEs and End Users• PO to analyse feedback, add to backlog, prioritize based on business value• Team to fix and fine tune product as early as they receive feedback from PO• Advantage: Time difference between India and UK• Ensure full availability of entire team• Suggestions, enhancements to be parked for Phase 4 (BAU)• Check feasibility of:

– Sprint 10/ 11 : Mini internal sprints of 1 week each 10.1, 10.2, 11.1, 11.2– Kanban – When to Push code to Beta Staging: every week, twice a week– Scale down of India team by 1 member: really needed?

Phase 3 : Roll Out Sprint 11Sprint 1010.1 10.2 11.1 11.2

• Talent Spread Over 11 Sprints

Staffing Plan

Roll Out

PoC Phase

Sprint India Team Members

Customer Developer

Customer Product Owner

Project Manager

Total FTE Sprint Wise

No. of Days in Sprint

Man days Sprint Wise

1 3 1 0.75 1 5.75 10 57.52 3 1 0.5 1 5.5 10 553 3 1 0.5 0.5 5 10 504 4 1 0.25 0.25 5.5 10 555 4 1 0.5 0.25 5.75 10 57.56 4 1 0.25 0.25 5.5 10 557 4 1 0.25 0.25 5.5 10 558 4 1 0.25 0.25 5.5 10 559 4 1 0.5 0.25 5.75 10 57.5

10 3 1 1 1 6 10 6011 3 1 1 1 6 10 60

Total Effort in Man Days 617.5

Location Wise Staffing Plan

Sprint 1, 2, 3

Sprint 4

Sprint 5

Sprint 6, 7

Sprint 8, 9

Sprint 10, 11

London India

India Team Member

Customer Developer

Customer PO

RoleScrum Master (also Sr.

Developer)

Developer

Tester

# Developer* Project Manager

Developer

* Product Owner

* These Roles are not full time, involvement varies from phase to phase# To start from 4th Sprint

Release Timelines

Beta Release

Production Release

18 Weeks 4 Weeks

Incremental Release to Staging

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11

Success• PM to define success criteria together with customer at the beginning• Success Criteria to be as objective as possible; measured regularly and

shared with stakeholders transparently• Factors impacting success:

Shared and accessible environment for all development work Initial colocation and regular travel afterwards for short period across locations Accessible Product Owner or his proxy during the sprint Regular communication; setup to enable team members communicate across locations

in easy manner on a regular basis

Measuring Health CheckSr. No.

Measurable Expectation

Bad Good Excellent Remarks

1 Productivity Slow progress, current rate is too slow to achieve market commitments

Stable, sometimes increases, can release product with all major features implemented in-time

Reached maturity, confident to achieve market commitments

Measure VelocityAfter PoC phase, Assign numeric value (e.g. Good: 15-20, Excellent > 20, Bad < 15)

2 No. of Open Defects

Too many open defects Few open defects with no major impact, within acceptable range

No major open defect, very few minor defects

Refer open defects in backlog & their priorityAfter PoC phase, Assign numeric value (e.g. Good: 5-8, Excellent < 5, Bad > 8 )

3 Sprint Goal Achieved

Sprint goal consistently missed

Sprint goal mostly achieved with occasional miss

Sprint goal always achieved with occasional exceeding goals

Boolean valueMeasure result of each sprint, analyze in retrospectives and also in management meetings; take corrective action as appropriate

4 Code Quality Bad code, Poor design, standards,Tight feature coupling

Simple design+ code standards followed+ reduced feature coupling

+ smart solutions+ easy removal of incomplete features

For team to measure internally and publish using tools like Sonar: test coverage, code complexity, dead code, time taken per build, no. of failed builds , state of automation

(also a measure of engineering practices)

5 Impediment Backlog

Takes more than 2 sprints to fix

Impediments removed within same sprint

Impediments removed within same 1 week or work around provided

Quality and Processes

Measuring Health CheckSr. No.

Measurable Expectation

Bad Good Excellent Remarks

1 Customer Confidence

Poor confidence, risk to market commitments

Fairly confident to achieve market commitments, do not see major risks, happy with progress and quality

Very confident to achieve market commitments; excited to see progress and quality

Generic customer feedback including that of PO captured during management meetings and need basis; this is purely customer’s perspective based on current state of affairs

2 Running Tested Features (RTF)

Slow progress, very less RTF

Good no. of RTF available

Confident to achieve all minimum marketable Priority features in backlog within release timelines

High no. of RTF available

Confident to achieve all Priority features within release timelines

Analyze backlog, see release burn down It’s subjective ; depends upon completeness & maturity of backlog After PoC phase, start assign numeric value for RTF to made available at every sprint(e.g. Good: 3-5, Excellent > 5, Bad < 3)

3 Closure of open risks and issues (action points)

Too many risks openOpen AP impacting business

All open risks have well thought mitigation planAP getting closed in time without impacting business much

Able to translate some risks into opportunityNo open issues, issues are captured well at risk level

Maintain Risks Backlog; have mitigation planRefer list of open APs

It’s leading indicator of manager’s proactive-ness and efficiency

• Team Related General Team dynamics Clear understanding of Business goals of the user stories by the team members Independent Capability of feature development by India team

Customer and Business

Team Related

RisksRisk MitigationCustomer: No agile experience • Agile coaching for key customer stakeholders before starting the engagement

• Once engagement starts, India team to collaborate with customer on the job; helping them

Customer: No prior experience in distributed development

• Initial Agile coaching for key customer stakeholders to cover this aspect • India Team to share its experience with counterparts, make them comfortable• Shared development environment, common engineering practices at both locations

Lack of Market representation (Europe, Australia) for the development team, Late involvement of end user

• Insist and encourage involvement of end users in sprints demo as much as possible• PO to collaborate comprehensively with end users to ensure their perspective is built-in in the

backlog• Beta release 4 weeks prior to market release to ensure systems gets sufficient eyes before go live

Customer: little experience in building product from scratch

• Customer to benefit hugely from our rich experience • Agile is a superb way to aid software product development end to end

Integration with market adapters – knowledge, coordination

• Assign one point of contact (must be influential) for us to help coordinate with stakeholders of these market adapters• Engage them right from beginning; ensure they resolve dependencies in time (SLA?)• Access to product documentation, test environment and test data• Establish proper communication channels, regular meetings, publish escalation matrix• Invite them to participate in demo on need basis

Continuous Availability of Subject Matter Expert as PO

• One SME to perform the role of Product Owner (PO)• PO to be dedicated certain amount of his time for this project, sometimes even full time• PO’s top priority must be this project, he must be made equal party in success

RisksRisk MitigationNon-functional requirements (e.g. Performance, GUI)

• PO to ensure these are included in backlog and assigned due priority well in time• Team to help check on this proactively, share experience with PO

Beta Release: Availability of all SMEs, all end users

• Regular participation in demos of these stakeholders will reduce high dependency in beta phase• Co-locate end users from Australia in London before 1st week of beta release• Customer to anyway ensure availability of SMEs and end users during beta release, no exceptions

No auto test suite of existing market adapters

Low test coverage

• In PoC phase, whole team to undergo Training on market adapters: Covering test framework, testing tools and other aspects of testing• Reserve dedicated test capacity of these market adapters on need basis and especially in beta phase• Insist tester from these market adapters to work with team (on need basis) particularly when India

team is co-located in London (build relation , get to know market adapter)• Develop those pieces of code/functionality early that require interfacing with these market

adapters; allow surprises to spring early• Get contact details of their SMEs, test specialists and other needed key points of contact belonging

to these market adapters, get added to their e-mail distribution list• Team to be proactive and aggressive to resolve dependencies ; know their escalation matrix• Opportunity: Recommend to do a pilot project to enhance test coverage and automation of market

adapters either now or after production release or may be as a part of phase 4

Scope Not Known Number of sprints mentioned in delivery plan are just indicative; scope boundaries are not known at this stage neither draft backlog is available; once prioritized backlog gets ready during PoC phase, actual number of sprints to be determined at that time

Assumptions• After Agile Coaching, Customer understands Scrum reasonably well and also

committed to fulfil his obligations• One Subject Matter Expert to be dedicated for development team as per

expectations of Agile PO role• Key assumptions from PO :

– Liaison with other SMEs and end users; know their perspective well– Ensure entire Product backlog is ready before end of PoC phase– Ensure only Prioritized requirements are scoped-in in sprints– Formally accept the Epics/Stories once demonstrated as per his satisfaction– Regular participation in the Scrum practices including planning and demo is must– Provide direct and upfront feedback in timely manner

• Beta Release: Customer to free up SMEs and End Users in Europe, Australia during beta release; ensure they participate on priority and are dedicated (almost!)

Continued…

Assumptions• Hosting and deployment needs are not covered in this proposal; we will share our

experience and give recommendations; procurement of any 3rd party software or environment (e.g. cloud) is responsibility of customer

• Dependencies on market adapters to be resolved quickly, on priority• Customer to provide:

Graphic design material as needed Production test data Access to Integrated test environment, Staging environment, Production env (before roll out phase) Access to test environment of other products to be integrated (market adapters) Financial customers usually have very secure development environment; assumed access to all

necessary environment and platforms will be provided

• Customer to enter into relationship of open communication; treat India team equally to your own staff; participate in demos as much as possible

Dependencies• Subject matter experts• End users• Market adapters

Communication PlanWhat Who Frequency AgendaDaily Stand Up Dev Teams along with PO

(Local and Distributed)Daily • What I did yesterday, Plan for today

• Impediments

Planning Meeting Bi-weekly along with PO Bi-weekly(beginning of sprint)

• Goal of sprint• Queries, Estimation, Def. of done

Demo Entire Team + SME + End User + Other Stakeholders

Bi-weekly(end of sprint)

• Demo working software • Capture feedback

Retrospectives Bi-weekly along with PO(PM optional or need basis)

Bi-weekly(end of sprint)

• What went well and wrong• Improvements, actions

Management Meeting

Project Manager, Key stakeholders from customer’s side

Bi-weekly • Progress, status on key indicators, feedback, impediments/risks, budget, escalations, status on previous APs, AoB

Team Sync Project Manager, Scrum Master, PO Bi-weekly • Project manager to sync with team for bi-directional feedback, Risks, Improvements

Executive Meeting Customer’s executive team + TW senior management (PM optional)

Fortnightly + need basisWeekly in Beta release

• How engagement is going?• Feedback, Status, Risks, Escalations, Budget, AoB

Collaborate with market adapters

Project manager + Representatives of market adapters

Initially weekly, later on fortnightly + need basis

• Resolve queries and dependencies on market adapters quickly and efficiently, escalate

Golden rules of development• Allow easy removal or disabling of incomplete features• Reduced Feature Coupling• Never Gold Plate – develop user story just enough to meet the business

goal• Good number of information radiators like burn down chart, digital scrum-

board etc. so that everyone is aware of sprint progress• Ensure changes, feedback gets added to product backlog and prioritized• Celebrate small success and celebrate together

Cost• Approx. cost of development: < $ xyz>

• Offshore Blended Rate: < $ 20-28/hour>

• Onsite Blended Rate: <$ 60-70/hour>

• Exclusions: – Cost of customer agile coaching– Travel cost (airfare + accommodation) on actuals

* Refer appendix for details on cost calculations

Let’s Deliver…

Thank You!

*Relationships are precious*

Appendix : Justifying cost of project manager

Conversation partner at overall engagement level Process owner: Make sure Agile works and delivers value for all parties Meta Scrum Master – resolve impediments beyond scrum master’s control May act as Agile coach as and when required Facilitate cultural assimilation Take feedback every sprint and sync with stakeholders, team Status report on business metrics (health check indicators) Facilitate discussion between team, customer stakeholders, market adapters, as appropriate Direct feedback to the customer First point of escalation Administrative Responsibilities: Contract Management, Resourcing, Invoicing, Forecasting,

plan for knowledge build up and knowledge retention