AT12 Session 6/6/2013 3:45 PM 

       

"Using Scrum for Global Scale Development"

   

Presented by:

James Lynn SUTO Consulting

        

Brought to you by:  

  

340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

James Lynn SUTO Consulting

A partner with SUTO Consulting (sutoconsulting.com), James Lynn is passionate about delivering value to his clients by improving software development productivity and quality through enhancements to organization, process, and metrics; by transitioning work off-shore or reallocating work on-shore; and by developing business intelligence and metrics in his organization’s SaaS products to increase effectiveness for the end-user, resulting in higher customer satisfaction and improved renewal rates. For the past ten years, Jim has been an agent of change for several organizations in transition from waterfall to agile in the quest to improve performance and as the foundation to migrate heterogeneous applications to a single enterprise architecture. Reach Jim at jim@sutoconsulting.com.

 

1

Using Scrum for Global Scale Development

Jim Lynn

SUTO Consulting

Presentation Progress

7 3 2 1 5 4 6

2

The Disclaimer

• The specific issues have been generalized

• The specific solutions have been rationalized

• What we are going to talk about is the intersection of these experiences

No Individual Company Solution or Results - Contained in the Presentation

Company A

Company C

Company B

Background

• Based on several companies

– Shared common theme of goals and issues

–Had a large number of applications

• Different technologies, languages, security

• Developed in different geographic areas of the company

• Documentation was limited, SDLC was tribal and inconsistent within the company , quality hero based

A Composite Project is Illustrated in This Presentation

7

3

Migrating - Standard Architecture

• 6 applications needing a refresh

– Each developed by a different center

– Each different technology and some obsolete

– Each center in a different geographical location

• Migrate applications to enterprise architecture

Large Application

• Project estimated at 20,000 function points

• Over 110 developer person years effort

• Selected a Service-oriented Architecture (SOA)

• Investors need a 24 month implementation

• Nearly all employees will stay on deployed solutions

– Only 10% of staff will move to the migration

6

4

• Create foundation for next 10 years

– Refreshed technology

– Standards for security, communications, technology

– Add mobile delivery

– Adequate documentation to support

• Improve the product quality

• Reduce the cost for maintenance

• Reduce the redundancy of services

Application Goals

Project Objectives

• Unify the geographic development centers

– SDLC, documentation, communication

• Introduce agile development

• Introduce UML for documentation

• Common tools, documentation, architecture

• Introduce Metrics for management and communication

• Transform the organization while supporting current clients and employees

5

Issues to Consider

• Attrition rates in India could exceed 30%

• Little documentation on existing applications

• Engage contractors for most of implementation

– They would have no background in applications

– Needed a short process to get them productive

– As the application evolves transition to employees

• Communication with over 100 people

• 20,000 FP large risk of project failure

– Needed to demonstrate the migration

– Investors and clients

Architecture

• Selected Service-oriented Architecture (SOA)

– Atomic stand-alone , loosely coupled

– No calls between services

– Services and objects are orchestrated

• Standardize on Unified Modeling Language (UML)

– Visual models of object oriented systems

– Pictures are better than words for communicating

• Standardize service communication using Extensible Markup Language (XML)

6

11

Scrum of Scrums

A Common Agile Approach for Large Teams

Agile and Global Issues

• Most large developments are NOT co-located

• Time zones, communication

• Customer interaction

• Testing and defect resolution

• Multiple teams on a single Build lines

• High attrition issues and keeping teams coherent

• Transition the work from contractors to employees

Only 20 Employees Would be Available at the Start

7

13

3 Dimensions to the Team

Project Organization

• Implementation Teams (121 people) – Limited application exposure – Contractors – 15 – 8 person teams – 1 manager – All offshore 3 different locations

• Architecture Team (50 people) – Provides all technical leadership – Customer for the implementation teams – Mostly onshore (40/10)

• Project Management Office (PMO) (4 people)

Employees Were all in Architecture Team

8

Implementation Teams

• Contractors – no product experience – Need to transition to employees

• Focused on producing high quality code – Using Style Guides, Testing Standards – Work assignment/coordination from Architecture Team – Based on work packages

• Product owner for each team comes from Architecture team – multiple teams

• Performance and quality held to common standards

Also known as The Factory

5

Implementation Teams

• Highly skilled developers • Develop Services

– UML Documents – Using Reference

implementations

• Support specific Architecture teams

• Architecture team responsible for accepting output of Factory

9

Factory Sprint Team

• 8 members per team • 15 factory teams established • 1 team was an integration/test

team only • Teams in 2 Cities in India &

Philippines • New employees joined the

factory • Growth to architecture teams • Factory metrics and

management by a Factory Manager

Factory Sprint Team

Scrum Master

5 Developers

2 Test Engineers

Onboarding – A Factory Team

18

Process Tools &

Technology

Hands on

(Mock Sprint)

Training Evaluation

Factory 2 Weeks onboarding process

10

Team Bilbo Onboarding

• 1 defect 600loc

• Goal was 1/Kloc

• Moving to 1/10Kloc

• Standard ~ 10.24 hours/fp

• Based on 15fp/dev-mo

• Goals always improved

19

17.3

11.63 9.77

0

5

10

15

20

History POC Manage scale & grades

Demo Sprint Sprint -xxx Sprint – yyy

Effort (Hrs.)/FP

0.16

0.1

0.09

0

0.05

0.1

0.15

0.2

History POC Manage scale & grades

Demo Sprint Sprint -xxx Sprint – yyy

Defects /FP Mock sprint

evaluation Production sprint evaluation

Mock sprint

evaluation Production sprint evaluation

Goal 10.24

Goal .054

20

Factory Manager PMO QMO

Architects & BAs

Factory – Supported by Specialist

City 1 – Star Wars Characters City 2 – Lord of Rings

Team Darth Team Dengar Team Jarael

Team Skywalker Team Paploo Team Orrin

Team Nimrodel Team Legolas Team Eowyn

Team Gimli Team Tango Team Bilbo

Code Quality

Evangelist

11

Factory Metrics

• Evaluated teams like “machines” against standards and control limits

• Presented by Factory Manager

• Focusing on productivity and quality

• Teams not compared to each other

• Leveraged the best for the rest

• Weekly metric

• Monthly metrics

• Goals always improve

Factory Support

• The Factory is a structure that specializes

– Producing production deployable software

– According to user requirements

– Through an assembly process

• Supported by the Specialist in the Architecture Teams and the PMO

12

Architecture Team

• Employees/Contractors

• Specialist – Code Quality Evangelist

– Test Architects

– Business Analysis

– Technical Architects & DBAs • BAs and Architects formed Sprint Teams

• Sequenced work packages

• Provided direction to the Factory

• Accepted the results of sprints

• Central control of the Intellectual Property

4

Code Quality Evangelist

• Dedicated Team within the Architecture Group – All off-shore to be closer to the Factory

• Highly skilled in the language and environment

• Established coding style guides

• Developed reference implementations – Classes, services, UX and design patterns

• Develop training materials for factory

• Review the code and provide direction and mentoring to implementation teams. They trawl through the code

• Responsible for the factory teams to produce high quality consistent code -mentors

Trawling became Troll and thus the Code Troll

13

Code Trolls

• We needed our 100+ developers to produce – Code that meet the standards – Could be maintained and appeared as if only one person

wrote the code

• More money in maintenance than development • Worked w/Architects to insure we could build • Set the standards and review exceptions

– i.e. Cyclomatic Complexity – maintenance indicator

• Tasked to develop a tool to review all code – Created a tool called – Sledge Hammer

• Identify Factory staff that could be Code Trolls

SLEDGE Hammer

• NCover & NDepend used to find potential trouble in the code base and reported to the Code Trolls via import into the Sledge Hammer tool

• Trolls review source code and make recommendations to sprint teams – work with each team

• Second set of eyes reviews the code during sprints

• Recommendations get added to the product backlog

• Trolls coordinate with the Technical Architects on recommendations to ensure they are sensible

• Recommendations are tracked and managed through the Sledge Hammer tool.

14

Code Troll Role in Factory

• Fixes/refactors by the sprint team MUST be reviewed by a Code Troll and be VERIFIED before it is accepted.

• New Code/Changed code gets reviewed after sprint is delivered.

Code

Review

Code Quality Metrics

Generated on Day 7 &

Day 10

Code Quality Data Moved to

Code Quality Improvement

Management System

Recommendations

Sledge

Hammer Tool

Code Quality

Review Sprint Teams

Code Troll Tasks & Activities During a Development Sprint Cycle

Development Sprint Cycle

Test Architects

• Create sprint test guidance

• Own the test architecture

• Review test cases

• Insure all the sprint test cases support goals

• Manage the Integration sprint team

• Automated testing

• Enter defects in the backlog for architect scheduling

• Review and verify requirements delivered

• Coordinate Build lines with architects

15

Technical Architects/DBAs & BAs

Product

Backlog

Design Work

Packages

Sprint

Teams

Factory

Production

Shippable

Incremental

Build

• Includes UX/UI team

• Document Requirements

• Design work packages

• Ensure sprint teams deliver desired requirements

• Architecture communication

Architects & BAs

Verify

Implementation

Architecture

Communication

Requirements &

Design Verification

Work Package

• UML package – Reusable code identified – Reference implementations are included – Common solutions

• Video of the UX/UI elements – UX/UI Style Guide

• Contains all of the requirements • Sized and sequenced for sprint implementation • BA and Architect support the WP during the sprint • BA and Architect are customers for sprint

acceptance

16

31

• Senior BA – Provides a scope definition of each package

• Lead Solutions Architect - Reviews/Approves the scope definition of each package

Scope Definition

• Senior BA – Validate that the requirement and use case for each package is correct and meets our define standards

• UI Lead – Validate that the mock UI for each package follows defined standards

• Architect – Validate requirements and use cases are clear and follows defined standards

Package Reviews

• Lead Solutions Architect –Perform final approval on requirements, use cases and UI for each package

Package Approvals

• BA – Handoff requirements and use cases for each package

• Architect – Handoff design artifacts for each package

• Scrum Master – Accepts approved package for development

Package Handoff

• BA – Verify that all requirements are meet prior to sprint demo. Review the test case coverage for each package.

• Architect – Verify that the design of each package is correct.

Sprint Reviews

BA & Architects w/WP

32

Architecture Sprint - Process Flow

Package Acceptance

Joint Application

Design (JAD)

JAD Backlog

Scope Sequence , UI/UX movies,

Review/Approval by Leads

Approval Lead Solution Architect

Architecture Teams

Factory Backlog

Package Analysis (Day 1-2)

Development (Day 3- 11)

Reviews (Day 11 -14)

Approval (Day 15)

17

Project Management

• Project scheduling and tracking – Planning was done on a 90 day rolling wave

• 1 planner dedicated to the factory and metrics

• Scope watchdog – highlighted scope creep

• Coordinated communication – Conducted audits for documents and results

– Acted as the honest brokers

– Management communication

– Customer communication

• Risks and Action Register

3

The PMO

• Managed the connections to organizations outside of development

– Transformation of processes to include UML/XML

– Training for other organizations

• Owner of the build lines and release schedule

– Periodic releases for clients and internal stakeholders

– Manages the Change Control Board

18

35

Factory Sprint - Process Flow

Sprint Acceptance

Work Package Handoff

Estimate Scope & Seek

Approval

Approve Sprint Scope

Work Package Analysis

Post Questions on design &

requirements

Development, Code Review &

Test Case Creation

Code Walk-through

Log Change Request

Scope affected

Provide Clarification

Yes

CCB Review

Test Case Execution and Bug Fixes

Demo

No

BA/,

Architect

Sprint Teams

Retrospective

Requirement Analysis (Day 1-2)

Development (Day 3- 11)

Testing (Day 11 -14)

Demo (Day 15)

2

Take Away

• Architects wanted to write code • Code Trolls were very effective • The Factory

– High degree of employee satisfaction • Liked the routine of the sprints • Liked that software developers were the clients

– Needed firm plans for transition of employees – Needed to add training for “what” we were building

• Maintained library of reusable code and reference implementations – Needed standards and tools for easy reuse – CMS to manage content

1

19

Learning

• Managing the build lines was a full time job – Multi Factory building on a line

– 1 Final Integration line

• Clients struggled with build lines that had partial functions – so many things going on

• Communication always needed to be monitored – Establish overlap hours for meetings

• Difficult for companies to adapt agile without a plan and executive buy in and commitment

• Selecting the right contractors to help train staff was key

Questions

20

Jim Lynn jim@sutoconsulting.com

40

• Certain images and/or photos in this presentation are the copyrighted property of 123RF Limited, their Contributors or Licensed Partners

and are being used with permission under license. These images and/or photos may not be copied or downloaded without permission

from 123RF Limited.

Notes