Distributed Agile Workshop @ Agile India - Dipesh Pala

@DipeshPala@DipeshPala

Unleashing the full potential of your Distributed Agile Teams

Dipesh PalaAgile Capability Leader - Asia Pacific

Agile India 2016

A workshop for those working in complex environments

@DipeshPala

PART ONE ��Background and Introductions

@DipeshPala


Our Expectations

What do we want to get out of this workshop?


Why would an organization consider to do Distributed Agile?

E X E R C I S E


Why Distributed Agile?

•  Reduced Costs •  Expanding for Innovation and Thought Leadership •  Access to Talent •  Access to New Markets


6

6

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

8. Working software is the primary measure of progress.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Do the Agile Principles align to Distributed Agile?


Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Agile Manifesto Values

Satisfy the Customer Our highest priority is to satisfy the

customer through early and continuous delivery

of valuable software.

Welcome Change Welcome changing requirements, even late in development. Agile processes harness

change for the customer's competitive advantage.

Deliver Frequently Deliver working software frequently,

from a couple of weeks to a couple of months, with a preference to the

shorter timescale.

Business + Development Business people and developers must

work together daily throughout the project.

Trust the Team Build projects around motivated

individuals. Give them the environment and

support they need, and trust them to get the job done.

F2F Communication The most efficient and effective method

of conveying information to and within a

development team is face-to-face conversation.

Working Software Working software is the primary

measure of progress.

Sustainable Pace Agile processes promote sustainable

development. The sponsors, developers, and users

should be able to maintain a constant pace indefinitely.

Technical Excellence Continuous attention to technical

excellence and good design enhances agility.

Simplicity Simplicity--the art of maximizing the

amount of work not done--is essential.

Self Organizing The best architectures, requirements,

and designs emerge from self-organizing teams.

Reflections At regular intervals, the team reflects on

how to become more effective, then tunes and adjusts its behavior accordingly.

Do the Agile Principles align to Distributed Agile…

@DipeshPala

PART TWO ��Common reasons for Distributed Teams

@DipeshPala


Which is better? Going Agile first than Distributed

or Distributed first than Agile?

G RO U P D I S C U S S I O N


Benefits of doing Distributed Agile


What is the greatest challenge that your Distributed teams (might) face?

E X E R C I S E

@DipeshPala@DipeshPala 12

Considerations for Distributed Agile

!


Considerations for Distributed Agile


!  One team culture !  Two-way flow !  Minimise hands-off !  End-to-end and capability within each location

!  Innovation !  Share and learn !  Continuous knowledge transfer

!  Empowered !  Willing to do everything !  T-shaped skills !  Courage to challenge, and be challenged

!  Being able to start/stop work at low cost !  Move from Push-to-Pull culture of Self-Service !  Deliver Business Value rather than Projects

!  Funding of work is conductive to the Agile ways of working

!  Agile Demand Management !  Single consistent way of working across all

locations

Guiding Principles for Distributed

Agile

!  End-to-end capability within teams !  Long lived teams !  “you build it, you maintain it” !  Capacity and Dependency

Management

PASSIONATE PEOPLE

CONTINUOUS IMPROVEMENT

DISTRUBUTED DELIVERY

CUSTOMER VALUE

SCALING TEAMS

AGILE GOVERNANCE


TEAM 2

Core team members

Non-Core team members

Core team members

Non-Core team members

TEAM 1

Rotation type 1 non-core team member rotation

Frequency: 3 months Percentage: Max 30%

of the team

Accelerating velocity and minimising the impacts of peaks and troughs

Rotation Model

Rotation type 2 core team member rotation

Frequency: 6 months Percentage: Max 10%

of the team

Capability that has both depth and breadth across the domain providing greater scalability and flexibility


AS IS



IDEAL

More Accountability

Less Coordination

More Transparency

Reduced Cycle Time



How do we set up Distributed Agile Teams?

!

Sydney Melbourne Pune

!

Sydney Melbourne Pune


!

Getting Started with Distributed Agile

@DipeshPala

PART THREE ��Distributed Agile Exercise

@DipeshPala


Timings

Event Duration

Release Planning 15 mins

Sprint (including Sprint Planning) 5 mins

Sprint Review 3 mins

Sprint Retrospective 3 mins

Final Production Release (Demo) 5 mins

Game: Miniature Farm

The aim is to create a miniature farm with using the Distributed Agile methods.


Inputs •  Product Backlog •  Product Vision •  Team Capacity •  Risks, Issues, Dependencies

Agenda •  Product Owner presents the product vision and goals •  Product Owner reviews key milestones and dates •  Product Owner presents the first cut of the

Product Backlog •  Team asks questions to understand the stories •  Team estimates the stories at a high level •  Team estimates initial capacity/velocity per sprint •  Team produces a Release Plan •  Key Risks, Assumptions, Risks and Dependencies are

recorded

Miniature Farm – Release Planning (15 mins)


Miniature Farm – Product Backlog Item # Descrip7on Business Value

1 Farmer and his wife 1000 2 Sheepdog 50 3 Scarecrow 100 4 Barn to store hay/grains 300 5 Farm House for Farmer's family 800

6 Veggie patch for the Farmer's family (including spring onion, cabbage, carrots) 200

7 Tractor for hauling (2 front wheels smaller than the 2 rear wheels) 700

8 Windmill for milling grain (with 3 sails) 600 9 Square Hay Bales (x5) 50 10 Hay Barrack with roof moving up & down as the hay level changes 500 11 Fence to protect the livestock 300 12 Duck pond (with 2 ducks) 400 13 Farm pick-‐up truck 200 14 Large trees (x2) to provide shade 100 15 Stool -‐ to sit on while milking 400 16 Pail -‐ to put milk in while milking (x2) 500


Miniature Farm

Hig

hly

Flex

ible

Not

so

Flex

ible


Miniature Farm – Risk Register


Miniature Farm – Sprit Planning

Inputs

•  Product Backlog •  Prior velocity •  Team capacity •  Risks, Issues, Dependencies

Agenda •  Product Owner proposes the Product Backlog for review •  Product Owner and Team review and clarify each item •  Larger Stories are broken down if necessary •  Team and Product Owner clearly define the Acceptance

Criteria for every story •  Team estimates all resultant stories •  Team selects the stories they can complete within this sprint •  Team identifies the Sprint Goal or Theme •  Product Owner agrees with the order in which work will be

completed








Miniature Farm – Sprit Review

Product Demo


Miniature Farm – Sprit Retro

How can we get better?







* 17 * Farm House to have an opening door and 2 opening windows 500 * 18 * Farmer's wife has just had twins -‐ 2 baby boys! 1000


Miniature Farm – Sprit Review

It’s Showtime!


Miniature Farm – Sprit Retro

How can we get better?

@DipeshPala

PART THREE ��Types of Distribution

@DipeshPala


!  Team is aware of how their work addresses the needs of end users.

!  Dependencies are reduced. !  Handoffs are reduced. !  Planning is easier. !  Design issues are found and

corrected earlier.

Administer user accounts

Administer Web server accounts

Bill for services

Administer email accounts

Feature teams work on customer-centric capabilities delivered as features in the final product.

Feature Teams


Where teams are focused primarily on “layers” or components rather than features: •  Limited understanding of problem •  Increased dependencies •  Delays for feature teams •  Bottleneck for feature teams that use the

components •  Slower to detect and correct design flaws •  Creates risk

Feature: Administer

user accounts

Component Team: Database Team

Component Team: Web Services Team

Component Team: Billing System Team

Feature: Administer Billing

details

Component Teams

Component Teams

@DipeshPala

PART FOUR ��Choosing Your Method for

Communicating and Collaborating

@DipeshPala


Strive for the Richest Communication Channel Possible


Edward T. Hall (1959), a renowned social anthropologist, argued that in a normal conversation: “More than 65 percent of social meaning occurs through the nonverbal channel.”

Nonverbal Communication

@DipeshPala

PART F IVE ��Dealing with Time Zone Issues

@DipeshPala


Use a Liaison

Whole team Consistent Date/time

Whole team Alternating

Meeting Times

Documentation (and chat)

Approaches to Time Zone Issues


•  Anyone who cannot attend documents their answers in an e-mail or wiki

•  The Scrum Master reads their answers in the meeting BUT… •  Lack of opportunity for Q&A •  Less rich communication vehicle •  People don’t always read about what team mates are doing •  Reduces the whole team experience •  Reduces peer pressure

Using Documentation


•  Transcript of session produce notes for the meeting •  Makes the meeting easier for non-native speakers

BUT… •  Complete loss of non-verbal communication •  Difficult to gauge if everyone is paying attention •  Depends on the Scrum Master to start on time •  Hard to follow if the meeting is not structured

Instant Messaging

Meeting via instant messaging (form of documentation)


•  Team schedules the meeting at two different times

•  Team members attend at the meeting time most convenient to them

•  One team member serves as a liaison and attends both meetings

•  Liaison communicates information from the other meeting

Taking a Liaison Approach


Pros •  Better for sustainable pace

•  Allows for a degree of visibility on everyone’s work

•  Can be better than docs because people can ask questions.

•  Richer communication medium.

Cons •  The liaison is basically “playing telephone”

•  The liaison may not present all the details

•  Risk of fracturing of the team

•  Negative impact on “whole team” view

•  Negative affect on the work-life balance of the liaison

Taking a Liaison Approach


1

3 Important Questions

What days/times work best for you (including hours outside of normal hours)?

2 Which days/times are okay?

3 Which days/times are off limits?


•  Team identifies two different times for the meeting

•  Team alternates the time used for the daily scrum at a set frequency (every day, every week)

•  Everyone is encouraged to attend •  Anyone who cannot attend

documents their answers in an e-mail or wiki

•  The Scrum Master reads their answers in the meeting

Or, you can alternate meeting times for whole team


Pros

•  Everyone shares equally in the compromise

•  Aligns best with interactive spirit of Scrum and Agile

•  Verbal communication

•  Opportunity for Q&A

•  Greater pressure to deliver on commitments

Cons

•  Challenging for sustainable pace

•  Some may not be willing to share the pain

•  Loss of information from members if team members don’t show up during the hours that are bad for them

Alternating Meeting Times


Don’t expect offshore development to be cheap: - Overall costs could be lower than if you hired an equivalent number of staff on site,

but don’t expect it to be a cheap option. - Need to budget for travel, communications and potential training.

The Agile Manifesto: The values and principles of the manifesto remain foundational to Distributed Agile. And while “the most

efficient and effective method of conveying information to and within a development team is face-to-face conversation” is one of the primary principles, there are new ways of working and communicating that reduce the impact where this is not possible.

Consistency all around:

A single, consistent, and Agile way of working across all locations will increase the effectiveness across the project teams.

1

Key Takeaways

1

2

3


End-to-end delivery capability by team by location: Teams should be loosely coupled with highly integrated, end-to-end, capabilities in each team/

location to reduce hand-offs and dependencies between teams.

Invest in people, tools and technology: Tools are critical, but they are not the only answer. It is necessary to have good processes in place, and for team members to meet in person as frequently as possible. Technology will help bridge most obstacles; so code review, wikis, discussion forums, bug tracking, requirement tracking, Continuous Integration tools are very important.

Everyone on a single platform:

Having one integrated collaboration platform helps align the team and improve transparency, productivity, efficiency and trust across projects and organizations.

49

Key Takeaways

4

5

6


Related Books

@DipeshPala

Dipesh PalaAgile Capability LeadIBM GBS Asia Pacific

[email protected]

@DipeshPala

slideshare.net/DipeshPala

au.linkedin.com.com/in/dipeshpala

Distributed Agile Workshop @ Agile India - Dipesh Pala

Leadership & Management