Nearshore Best Practices Workshop

  • 1,073 views
Uploaded on

This workshop is part of our kickoff process for new projects. …

This workshop is part of our kickoff process for new projects.
It's a space to discuss about how we and our clients understand agile methodologies their implementation.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,073
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes
  • Notes

Transcript

  • 1. Nearshore Agile Development Best Practices Workshop 2
  • 2. Workshop Objectives Align with our clients on agile practices. Set reasonable expectations Mitigate difficulties of Distributed Agile Software development Agree on tools to be used, meetings to be held, agile ceremonies to be practiced, etc. Recommend Solutions based on our experience Listen to the client’s concerns regarding agile and come up with possible solutions. 3
  • 3. Workshop Agenda Distributed Meeting Management Roles Agile Process Alignment o Scrum / Kanban o Tracking o Artifacts o Quality, Velocity, and Definition of Done Risks and their Management 4
  • 4. Meetings As agile practitioners, we put individuals and interactions over processes and tools. The use of video when communicating improves the quality of interactions, facilitates feedback and is the warmest kind of communication we can have being distributed. o Some tips to keep in mind: make sure lighting is adequate; orient people to face the camera; individual cameras (versus room cameras) are preferred. 5 Video Usage Tools we propose: GoToMeeting (recommended) Skype Google+ Screen sharing only: Join.me
  • 5. Roles & Responsibilities 6 It’s important to clearly define roles and responsibilities when starting any kind of project. When being distributed, even more! Take the time to establish team and cross team roles and how interactions are expected to happen. Focus on have clear understanding of the following roles (at least): o Product Owner o ScrumMaster o VP Team Lead o Solutions Manager o Client Stakeholders: who and what responsibilities? o Other Roles: QA lead, build management, others?
  • 6. Agile Process Alignment Take time to discuss the following items in order to be aligned How agile is the group of people that the VP team will be interacting with? How agile do we want to be ? Scrum Process and Meetings o Sprint cadence: ? weeks o Required meetings, timing, agenda, prep, and attendees. 7
  • 7. Agile Process Alignment Choose appropriate tools to support agile practices in a distributed model. o E.g. TFS, JIRA, Rally, VersionOne, Assembla, TargetProcess, etc. o Document repository? (e.g. wiki, Google Drive, Confluence, etc.) Go through the following discussions: o Tracking Methods o Deliverables and Artifacts o Quality Practices o Expected Velocity o Definition of Done 8 Tools
  • 8. Scrum or Kanban? 9
  • 9. Scrum Process 10
  • 10. Scrum Meetings Scrum proposes the following ceremonies 1. Product Planning 2. Release Planning 3. Sprint Pre-Planning (“grooming”) 4. Sprint Planning 5. Stand-up 6. Sprint Demonstration 7. Sprint Retrospective 11 This doesn’t mean that they all will be useful in our specific project.
  • 11. Scrum Meetings The key is choose the ones that we consider will add value to our processes. Inspect and adapt: remove unnecessary meetings and add as necessary. 12
  • 12. Kanban Process Overview of Process Work States. Define them and make sure everyone has a deep understanding of them. Establish adequate WIP Limits. Card Ownership. 13
  • 13. Tracking Methods / Development Artifacts Take time to sync up about the expected tracking methods Also sync up on understanding and importance of concepts like velocity, story points, etc. We find the following charts quite useful to document the selected tracking methods. 14
  • 14. Tracking Methods 15 Stories / PBIs Tasks How is work estimated? How is progress measured? How is velocity measured? (not applicable) What are the statuses? Working at task level? Are bugs/defects treated differently than a story / task?
  • 15. Development Artifacts 16 Content and Format Who Does? Tracking Board User Story / PBI Specification (see next slide for example) UI Design Task / Card Test Case Ticket (for bug or issue) Documentation (classic)
  • 16. Software Quality Assurance Development Process Improvement – KPIs, e.g.: o Velocity o Estimation accuracy o Code quality o Functional quality o Others? Quality Planning o Role, if any, of stories and tasks in testing Quality Practices o Internal code quality o Testing roles and practices o Approaches and environments 17
  • 17. Testing 18 Responsible Party Practices and Tools Unit Functional System Integration Regression Performance Acceptance Role of TDD / BDD Environments to be used (dev, QA, staging, etc.) Automation?
  • 18. Expected Velocity Establish velocity expectations from both sides. The Velocity of the team will depend on a number of variables, as the ones on the next slide. Make sure both parties are aligned on the understanding and importance of those variables. 19
  • 19. Expected Velocity Ramp-up expectation (three iterations?) Use of spikes in stories ? Goal of first iterations: learning, delivery? Approach to technical debt Approach to changes during sprint o Re-cap: changes in requirements o Re-cap: changes in estimates and commitment Absence planning (holidays and vacations) 20
  • 20. Definition of Done This is an area of truly focus on when working on distributed teams. Make sure we are aligned on the Definition of done criteria on the Task, Story, Sprint and Release level. 21
  • 21. Definition of Done examples 22 Task: •Implemented •Unit Tested •Code commented •In source trunk •In CI build •Coverage •Standards met •Tracked •Other metrics? Story: •AC met •All agreed tasks done •Functionally tested •All known bugs fixed •Documented for user view •Story test updated •Integration tested •Installation works •Smoke-tested Sprint: •Sprint end date reached •Completed stories demo’d •Retrospective held and documented •Product backlog updated •Performance tested •Regression suite updated •All bugs closed or postponed •Documented for tech. view Release: •All agreed sprints done •Integration tested / hardened •Documentation “tested” •Install packages complete •Release notes •Marketing collateral •Regression test complete •External testing •PO sign-off
  • 22. Risk Management 23 Be aware of risks involved in agile development, and take into account that being distributed sometimes add more risks. This is our introduction to Risk Management in 2 steps. o 1 Awareness of possible risks. o 2 Assessment and mitigation plan.
  • 23. Possible Risks 24 Needs •Product Owner participation and clarity / distance from business customer •Incomplete acceptance criteria •Developers unclear / unquestioning during story elucidation Plan •Expectations for ramp-up •Unrealistic, business-driven deadlines •Planning at too high a level / inaccurate estimations Commit- ment •Commitments when there should not be commitments •No measures of productivity Delivery •Velocity / blockers early warnings and visibility •Not enough time / attention to functional testing •Poor definition of / adherence to agile processes, e.g. mid-sprint changes
  • 24. Risk Assessment 25 Risk Area Specific Risk Priority (H/M/L) Mitigation Strategy Communication (access, infrastructure, response, 3rd parties, etc.) Requirements (client or team participation, too many layers, incomplete acceptance criteria) Planning (ramp-up / deadline expectations, planning too high, poor estimating) Commitment (team being “sure”, lack of metrics) Delivery (attention to blockers, lack of QA, adherence to agile processes) Personnel (roles, skills, motivation, conflict) Other
  • 25. Workshop Action Plan Specific Action Items o Action Item #1: (establish ad hoc meetings for example) Future Use of Workshop Output o Use #1: 26 Workshop Retrospective What went well? What didn’t go well? How can we improve the workshop for the next time?
  • 26. Thank you !! For further information contact us: www.velocitypartners.net info@velocitypartners.net 27