distributed agile workshop @ agile india - dipesh pala
Post on 11-Apr-2017
349 Views
Preview:
TRANSCRIPT
@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@DipeshPala
Why Distributed Agile?
• Reduced Costs • Expanding for Innovation and Thought Leadership • Access to Talent • Access to New Markets
@DipeshPala@DipeshPala
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?
@DipeshPala@DipeshPala
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@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
@DipeshPala@DipeshPala
What is the greatest challenge that your Distributed teams (might) face?
E X E R C I S E
@DipeshPala@DipeshPala 14
! 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
@DipeshPala@DipeshPala 15
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
@DipeshPala@DipeshPala
AS IS
Capability that has both depth and breadth across the domain providing greater scalability and flexibility
@DipeshPala@DipeshPala
IDEAL
More Accountability
Less Coordination
More Transparency
Reduced Cycle Time
Capability that has both depth and breadth across the domain providing greater scalability and flexibility
@DipeshPala@DipeshPala
How do we set up Distributed Agile Teams?
!
Sydney Melbourne Pune
!
Sydney Melbourne Pune
@DipeshPala@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.
@DipeshPala@DipeshPala
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)
@DipeshPala@DipeshPala
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
@DipeshPala@DipeshPala
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
@DipeshPala@DipeshPala
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
@DipeshPala@DipeshPala
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
* 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
@DipeshPala@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
@DipeshPala@DipeshPala
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@DipeshPala
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@DipeshPala
Use a Liaison
Whole team Consistent Date/time
Whole team Alternating
Meeting Times
Documentation (and chat)
Approaches to Time Zone Issues
@DipeshPala@DipeshPala
• 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
@DipeshPala@DipeshPala
• 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)
@DipeshPala@DipeshPala
• 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
@DipeshPala@DipeshPala
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
@DipeshPala@DipeshPala
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?
@DipeshPala@DipeshPala
• 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
@DipeshPala@DipeshPala
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
@DipeshPala@DipeshPala
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
@DipeshPala@DipeshPala
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
top related