Making Distributed Agile Work

Making Distributed Agile Work
Mike Schimmel ALM Solution Architect Microsoft Date: October 20th, 2008
Agenda
Introduction
Presenter Goals of Workshop
Background
Characteristics of Distributed Development Problems identified in distributed development projects Problems identified in transition from Legacy Waterfall to Agile/Iterative Characteristics of well running agile teams Characteristics of not-so-well running agile teams Solutions To Distributed Agility Problems Summary
Agenda
Introduction
Background
Introduction
Mike Schimmel
ALM Solution Architect Microsoft Corportation 20+ Years Software Development / Management Special Interests
Workshop Goals
Identify Possible Solutions to Distributed Agility Problems
Your Goals
Agenda
Introduction Presenter Goals of Workshop
Background
Background
In the beginning
Single developers worked on dumb terminals with a large central processor
Project data was central Workers were co-located Communication was easy
Background
Distributed Within an Office
Single developers worked on their own work stations
Benefits: More Autonomous More Individual Productivity Problems with data coordination solved by: Version Control Increased Communication Careful Merge Management Centralized Data
What is Happening?
Companies Want to Go Agile
CIOs have heard great things Want / Need to Deliver Faster with Higher Quality
Companies Want to Go Global

CIOs have heard great things Want / Need to Lower Costs of IT or App. Dev.
Background
Distributed Globally
Developers all over the world to save money due to low billing rates
Global Distribution Characteristics

Global Distribution
Benefits:
Save Costs Continuous Work (24 Hours)
Problems:
Communication Language Requirements Silos Poor Hand-Offs Culture Project Data Synchronization Poor Application Quality
Challenges Going from Waterfall to Agile

Challenge
Old Dog, New Tricks Long time developers dont like change PMP / Executive Need for Milestone How do we start? Dont just try agile, but try distribution at same time
What Happens?
Find one flaw, give up. Sponsorship at risk. Misinterpret Methods Mass, Globally Distributed Confusion
Results:
Lots of money lost, large decrease in productivity, lowered morale, and exodus from company
Agenda
Introduction
Background
So, we use Agile Methods Scrum

Rapidly Gaining Acceptance Very productive Minimizes Unnecessary Work Focus on the source of value those DOING the work Why Scrum? Provides Good Governance, Controls, and Organization for Mitigating Risk Well-Documented, Popular, and Simple Industry Guidance All Over the Place Simple Easy to Learn
Characteristics of a Well Running Team

Outstanding Developers Cross Functional Rock Stars! Solid Architect Strong Personalities Overcome Customer Customer is part of team Test Driven Development A Religion Automated Build Mgt., Release Mgt., and Testing Paired Programming Informal Code Review
Characteristics of a Well Running Team

Focus on Evolving Small, Manageable Stories; Not Complex Use Cases Didnt Kill the Tracker Automated the Task Cards Guerilla Testing
Co-Located Team!
Agenda
Introduction
Background
A NOT So Well Running Team

Not Co-Located Distributed across the globe Developers are NOT Rock Stars!
One Trick Ponys Low Skill and Desire (i.e. Wont do TDD)
Project Functions are NOT Co-Located

Developers in one location, testers another, business stakeholders yet another
Dependencies on other projects that do not practice the same methods Part Time Commitment from Critical Resources (i.e. Architect) Lack of test and build automation
So, Whats the Reality

Teams dont know how to start Distribution is going to happen Not all team members can be Rock Stars Some customers are not 100% Available Functions will be isolated Dependencies on other projects will exist
Agenda
Introduction
Background
Solutions: Starting to Go Agile

Start with 30-Day Scrum Scrum Start with 30-Day Get Good Agile Experience GetHire a Scrum Master / Agile Good Agile Experience Is this you? Coach a Scrum Master / Agile Coach Hire 50% Team Should Have Agile Experience Good 50% Team Should Have Agile Experience Good Master/Journey Relationship Master/Journey Relationship Incrementally Adopt the Practice small team first, followed by Practice small team first, Incrementally Adopt the more and more more and more followed by Automation Build Mgt., Release Mgt., Unit Testing, Build ReleaseOr this? Unit Testing, Automation Build Mgt., Mgt., Build Verification Testing Verification Testing Use Work Flow and Work Item Use Work Flow and Work Item automation for Story automation for Story Cards and Cards Tasks and Tasks
Starting to Go Agile: Brainstorm

Audience Participation
Solutions: Distribution
Complete functional team isolated by application domain
Scrum Master Team Member Skills: Business Domain SME, Developer, Test Manager/Engineer, DBA, Network Specialty, Application Architecture, Etc.
Strictly Enforced Daily Stand-up More Documentation

(yea, I know, but graphics improve language barriers) Models of Scenarios / Component Interactions Enterprise Architecture Common Repository (WIKI) Source Code Management with robust branching, merging, and workspace isolation Work Flow / Work Items Management
Communications and Technology

Phone access to each site E-Mail Instant Messaging Video Conferencing
Automation
Rotate Resources
Distribution: Brainstorm
Solutions: Were Not Rock Stars

Hire Experience to the Team Pair Programming Approach to All Tasks Scrum Coach Application Architect Analysis Test Automation Lead Functional / System Test Automated Work Flow and Everything is Shared Work Items Informal Training Sessions Enforce Accountability Brown Bag Seminars Small Expectations After Hours Workshops Commit to small amounts of work Make Process Guidance Start with low compexities Available Show Early Success WIKI Start In Single Location, then Project Portal Expand Globally
At Best, Were Aging Rock Stars
Not Rock Stars: Brainstorm

Solutions: Customer Accessibility

Frequent, I Mean FREQUENT Communication
Daily planned conference calls Unplanned access They NEED to answer the phone
Meet me half way

Go to them Get them to come to you once in a while
Get Creative (see picture)
Customer Accessibility: Brainstorm

Solutions: Dependencies on Projects

Concede Some Deliverables due to waterfall dependencies Align with releases Align with interim milestones
Project Dependencies: Brainstorm

Agenda
Introduction
Background
Summary
Distributed Agile Can Work Requirements: Willing to Learn Willing to be Creative Automation Tests, Builds, Releases Automation Work Flow, Work Items Frequent, Open, Communication Supported by Technology Experience and Coaching
Thank You!
Distributed Agile:
Make it Real Mike Schimmel
mikeschi@microsoft.com

Making Distributed Agile Work

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Making Distributed Agile Work

Hochgeladen von

Copyright:

Verfügbare Formate

Making Distributed Agile Work

Companies Want to Go Global

Global Distribution Characteristics

Challenges Going from Waterfall to Agile

So, we use Agile Methods Scrum

Characteristics of a Well Running Team

Characteristics of a Well Running Team

A NOT So Well Running Team

Project Functions are NOT Co-Located

So, Whats the Reality

Solutions: Starting to Go Agile

Starting to Go Agile: Brainstorm

Strictly Enforced Daily Stand-up More Documentation

Communications and Technology

Solutions: Were Not Rock Stars

Not Rock Stars: Brainstorm

Solutions: Customer Accessibility

Meet me half way

Get Creative (see picture)

Customer Accessibility: Brainstorm

Solutions: Dependencies on Projects

Project Dependencies: Brainstorm

Das könnte Ihnen auch gefallen