Agility and off-shoring

1. Agility and off-shoring Bob Hughes Using Scrum on a dispersed project

2. Motivation: methodologies • As teacher (and writer) concerned about project management standards and practices • Interested in the difference between the core standard (e.g. PRINCE 2) and how it is used in practice (‘PINO’) • Agile approaches seen as a way of addressing the risks of inflexibility inherent in structured methods

4. Motivation: dealing with globalisation Off-shoring: generally driven by desire to exploit lower cost staff abroad however problems include: • Lack of personal communication • Time zone differences etc., etc Tendency to use more traditional, structured, Waterfall approaches – assumption that Agility needs team members to be located close to one another ?? Is Agile incompatible with off-shoring ?? ?? Can UK compete with off-shored developers ?? We are going to look at this in relation to Scrum

5. Scrum • A metaphor based on rugby scrums – team joining together in one effort • Not an acronym – so not ‘SCRUM’! • Scrum was originally a product design approach – not specific to software development • Developed originally by Ken Schwaber and Jeff Sutherland • Identifies three key roles: • Product owner • Scrum master • Development team

6. Scrum roles Product owner Owns the requirements Approves products Scrum master Guides the process May chair key meetings A different role to being a project manager Development team Seen as largely self-managing

7. Scrum workflows • Scrum planning meeting • Group meeting to identify requirements - recorded in a product backlog • Also identifies tasks needed to implement product backlog in a sprint backlog • Identifies tasks/products for first sprint, i.e. Increment • Estimates effort for each task and allocates tasks to developers

8. Sprint execution • Sprint meetings – daily 15 minute ‘stand-up’ meeting of the development team • Each developer reports: • Progress since last meeting • Planned activities for next meeting • Any inhibitions of further progress • Sprint terminates with a sprint review meeting – presentation of products to product owner • Followed by planning meeting for the next sprint

9. Case study: Seagull software • Based in a south coast town in the UK • Provides a service to travel businesses generating standard email shots to their customers e.g. E-tickets • Uses data extracted from the standard PNR (passenger record) created by systems such as Amadeus or Sabre • So, • Seagull had international clientele • Competitive because of existing software/IT assets and expertise • Seagull espoused the use of Scrum

10. The client: Koala Travel • A travel related business based in eastern Australia • Objectives of project • To use statutory email confirmation of an online transaction as an opportunity for cross-selling new or enhanced services • To ensure that the email (which would appear to customer as coming directly from Koala) had the correct corporate image/style • Koala had never used Scrum before

11. Koala versus Seagull time

12. Research method ‘Observation’ - Listening into telephone conferences between Seagull and Koala Advantages of approach. • Direct insight into how things really work • Richness of data • Little/no extra effort from participants Drawbacks • ‘Deaf’ and ‘blind’ spots • Lack of participant explanation/justification – observer may draw wrong conclusions • Observation may distort behaviour

13. The actual process: Pre-Scrum • Not observed • Selection of Seagull as a supplier by Koala rather than in-house or off-shoring to a low cost development country • Exploration of business requirements by Koala and Seagull • Face-to-face meetings • Seagull presentation on the Scrum approach • Contract – the need for a contractual relationship governs initial processes which tend to be rather conventional?

14. Planning meeting • Two hour telephone meeting starting at 7.30 UK time • Base product backlog originated by Seagull business analyst • Amended and approved by Koala business lead who acted as Product owner • Koala representatives included business, technical and QA people • Started with introductions, overview of Scrum ground rules (Scrum Master), business objectives (Product Owner)

15. Planning meeting continued – product backlog • Prioriitising requirements on the Product Log ‘..not that we won’t do the lowest priority items’ Certain patterns: • Some requirements are subsets of others e.g. distinguishing domestic/overseas flights and identifying countries in which airports are located • Requirements relating to same function merged • Split uncertain requirement into that which is clear cut and can be started and uncertain bit that needs clarification

16. Planning meeting: Sprint backlog • Two passes • Identification of tasks needed • Estimation of effort and allocation of developers • Seagull developers came to the fore here • Discussion tended to be technical but Scrum Master stressed importance of Koala understanding how estimates were arrived at • At end Scrum Master promised to distribute updated Product and Sprint Backlogs • Product Owner ‘don’t give me a Gantt chart’!

17. Pause for observer comment • Gantt charts key product of the conventional planning process telling you who is going to do what and when. • IHMO, Gantt charts produced by tools such as MS Project tend to be really annoying. • Where communications are non –visual, lists and spreadsheets clearly have advantages • Question of task dependencies – not clear how these were resolved • Resolved by developers before the meeting? Example of an observational blind spot!

18. Sprint execution • ‘Norm’ seems to be for daily scrum meetings at which Scrum Master and developers ( not Product Owner) meet for 15 minutes • With this project, two meetings a week (Tuesday and Thursday) which had same attendees as planning meeting • Developers reported on work completed, work to be done for next meeting, and obstacles to progress • Obstacles included: information and resources (e.g. data, graphics, requirement clarification) need from Koala

19. hurdles to progress • Technical/ architectural constraints e.g. Main source of data the common standardised PNR which might or might not have details needed • Details needed from person outside the Scrum group e.g. Koala marketing • Organizational conflicts, e.g. • Differences over naming standards for files • Koala quality and risk management standards – acceptance testing outside sprint activities

20. Some concluding comments • Distributed Scrum can work • Telephone conferences easy to set up – participants can be located anywhere with a phone • Discussions were clear – sometimes you could hear real seagulls in the background. Seemed part of the brand! • Identification of speakers may be a problem sometimes – but easy to identify Seagulls versus Koala (English/Irish versus Australian accents) • A showcase for Seagull – showed they were on the ball and on the case!

21. Relationship to off-shoring • Most detailed experience reports of distributed Scrum tend to be US based • US Scrum developers supplementing their staff by developers in India, say • Motivated by possibility of cost reduction • Emphasis on ‘educating’ off-shore developers in the ways of Scrum/XP etc • ‘On-shore’ versus ‘off-shore’ implies ‘on-shore’ is more powerful • ‘On-shore’ developers may control access to client

22. Scrum as a client management approach • Scrum seems to have been in part a way of managing the client • Key that generated emails have Koala corporate image – need for close co-operation on this • Would Scrum work as well for more ‘architectural’ development e.g. Completely new applications? • Would Scrum work for larger multi-team projects? (An approach with a Scrum of Scrums has been proposed, but how would this work in practice?) • The answer is to find people who have successfully modified Scrum to solve these problems!

23. Some useful sources – Scrum basics Linda Rising and Norman S Janoff (2000) ‘The Scrum Software Development Process for Small Team’ IEEE Software July/August 2000 pp 26-32 Softhouse ‘Scrum in five minutes’ http://www.softhouse.se/download Ken Schwaber ‘Scrum Guide’ http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf

24. Some useful sources – distributed Scrum A. Filev (2006) ‘Adopting and benefiting agile processes in offshore development’ Microsoft Architect Journal http://msdn.microsoft.com/en-us/library/bb245671.aspx Jeff Sutherland, Anton Victorov, Jack Blount, Nikilai Puntikov (2007) ‘Distributed Scrum: Agile Project Management with Outsourced development teams’ Proceedings 40th Hawaii International Conference on System Sciences J.Sutherland, G.Schoonheim, M.Rijk ‘Fully distributed Scrum: Replicating local productivity and quality with offshore streams’ Proceedings 42nd Hawaii International Conference on System Sciences Martin Fowler ‘Using an agile software process with offshore development’ http://www.martinfowler.com/articles/agileOffshore.html

25. An ‘academic’ view Sarker and Sarker (2009) ‘Exploring agility in distributed information systems development teams: and interpretive study in an offshoring context’. Information Systems Research 20(3) pp 440-461 Part of a special issue on academic research into agile methods