Transcript Slide 1
Agility and off-shoring Using Scrum on a dispersed project Bob Hughes 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 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 Scrum • A metaphor based on rugby scrums – team joining together in one effort • • Not an acronym – so not ‘SCRUM’! • Developed originally by Ken Schwaber and Jeff Sutherland • Identifies three key roles: Scrum was originally a product design approach – not specific to software development • Product owner • Scrum master • Development team 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 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 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 Case study: Seagull software • • Based in a south coast town in the UK • Uses data extracted from the standard PNR (passenger record) created by systems such as Amadeus or Sabre • So, • Provides a service to travel businesses generating standard email shots to their customers e.g. E-tickets • Seagull had international clientele • Competitive because of existing software/IT assets and expertise Seagull espoused the use of Scrum 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 Koala versus Seagull time UK time 0 (hours) E. Australian 8 time UK core hours 1 2 3 4 9 10 11 12 E.Australian core hours UK time 12 13 14 15 16 (hours) E. Australian 20 21 22 23 0 time UK core hours E. Australian core hours 5 6 7 8 9 10 11 13 14 15 16 17 18 19 17 18 19 20 21 22 23 1 2 3 4 5 6 7 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 • Observation may distort behaviour Lack of participant explanation/justification – observer may draw wrong conclusions The actual process: Pre-Scrum • • Not observed • Exploration of business requirements by Koala and Seagull • • • Face-to-face meetings Selection of Seagull as a supplier by Koala rather than in-house or off-shoring to a low cost development country Seagull presentation on the Scrum approach Contract – the need for a contractual relationship governs initial processes which tend to be rather conventional? Planning meeting • • Two hour telephone meeting starting at 7.30 UK time • 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) Base product backlog originated by Seagull business analyst 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 Planning meeting: Sprint backlog • Two passes • • Identification of tasks needed Estimation of effort and allocation of developers • • Seagull developers came to the fore here • At end Scrum Master promised to distribute updated Product and Sprint Backlogs • Product Owner ‘don’t give me a Gantt chart’! Discussion tended to be technical but Scrum Master stressed importance of Koala understanding how estimates were arrived at 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! 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 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 Some concluding comments • • Distributed Scrum can work • 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! Telephone conferences easy to set up – participants can be located anywhere with a phone 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 • ‘On-shore’ versus ‘off-shore’ implies ‘on-shore’ is more powerful • ‘On-shore’ developers may control access to client Emphasis on ‘educating’ off-shore developers in the ways of Scrum/XP etc 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! 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%20 Guide.pdf Some useful sources – distributed Scrum A. Filev (2006) ‘Adopting and benefiting agile processes in offshore development’ Microsoft Architect Journal http://msdn.microsoft.com/enus/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 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