Succeeding With Globally Distributed Agile
•
0 j'aime•804 vues
Why use Agile methods ? Why go globally distributed ? Challenges and how do you address them
![Succeeding with Globally Distributed Agile Sameer Deans Delivery Manager, ThoughtWorks - Bangalore ,[object Object],© ThoughtWorks 2010](https://image.slidesharecdn.com/succeedingwithgloballydistributedagile-100128004537-phpapp02/85/succeeding-with-globally-distributed-agile-1-320.jpg)
![Agenda © ThoughtWorks 2010 ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (7)
En vedette
Similaire à Succeeding With Globally Distributed Agile
Similaire à Succeeding With Globally Distributed Agile (20)
Plus de ThoughtWorks Studios
Plus de ThoughtWorks Studios (20)
Dernier
Dernier (20)
Succeeding With Globally Distributed Agile
- 3. Why use Agile methods ? © ThoughtWorks 2010
- 4. © ThoughtWorks 2010 Collaboration
- 5. © ThoughtWorks 2010 Feedback
- 6. © ThoughtWorks 2010 Time to market
- 7. Why go globally distributed ? © ThoughtWorks 2010
- 8. © ThoughtWorks 2010 Talent pool
- 9. © ThoughtWorks 2010 Quicker turnaround
- 10. © ThoughtWorks 2010 Economic benefits
- 11. Challenges © ThoughtWorks 2010
- 12. © ThoughtWorks 2010 People
- 13. © ThoughtWorks 2010 values & attitudes > challenges > people
- 14. © ThoughtWorks 2010 team structures & roles > challenges > people
- 15. © ThoughtWorks 2010 cross-pollination > challenges > people
- 16. © ThoughtWorks 2010 Process
- 17. © ThoughtWorks 2010 inception workshops > challenges > process
- 18. © ThoughtWorks 2010 collaboration among roles > challenges > process
- 19. © ThoughtWorks 2010 engineering practices > challenges > process
- 20. © ThoughtWorks 2010 involving testers > challenges > process
- 21. © ThoughtWorks 2010 ensuring work-life balance > challenges > process
- 22. © ThoughtWorks 2010 Visibility
- 23. © ThoughtWorks 2010 use of collaboration tools > challenges > visibility
- 24. © ThoughtWorks 2010 showcases & retrospectives > challenges > visibility
- 25. Critical factors © ThoughtWorks 2010
- 26. © ThoughtWorks 2010 a gradual move offshore > critical factors
- 27. © ThoughtWorks 2010 invest in critical team roles > critical factors
- 28. Questions ? © ThoughtWorks 2010
- 29. Thank you ! © ThoughtWorks 2010
Notes de l'éditeur
- We’re talking application development here, though many of the challenges and solutions are applicable across solution domains I’m assuming that you have an understanding of agile practices and how a typical project might use them
- Its not about throwing requirements over the wall Involvement of the business in the delivery process, defining requirements, being in constant touch with what the delivery team is doing Moving forward as one team
- Constant feedback – both from business and from the delivery team How does this feedback happen ? A more formal route is via application Showcases and team retrospectives Informally, by reviewing mockups, test plans
- Earlier testing, reducing cost of change Easier to prioritize requirements From business idea to deployable application is a smaller cycle than using other methods
- A Distributed model means you have delivery teams in multiple locations, its not just offshore
- Access to a global pool of talent
- With teams in different time zones across the world, the IT needs of businesses can be addressed almost 24x7
- And finally, a favourable economic impact contributes to the decision to go distributed
- Lets look at the various challenges associated with operating globally distributed following Agile methods
- How do we build up a common understanding of project goals, business needs, functional requirements People are at the center of all Agile practices –
- Its important that the people on your teams have the right values and attitudes Multi-cultural experience – those who have lived abroad or have experience in other cultural settings Ability to travel Build relationships
- Role of a proxy customer collocated with an offshore team is critical for faster feedback cycles on business priorities and requirements Role of onsite coordinator – business, other teams Sometimes critical to have a technical role on site who communicates to the offshore team at all levels Role of iteration manager Full complement of roles in each location – for example, don’t expect all the testing to be done in the offshore location, this will increase your feedback cycle
- Encourage and plan for rotations between locations – builds respect and trust Experiencing the benefits or pain of working in a particular location
- From project planning to requirements analysis, testing
- Agile projects are kicked off with collaborative and iterative workshops to get the big picture Perform the inception in the offshore location During the inception, get the team from the offshore location to present their understanding back to the rest of the group team that attended the inception gained a good understanding of the business goals and domain. This knowledge was passed on to the rest of the team through domain and technical sessions - visible process maps
- How does collaboration happen among different roles work especially when some may be in different locations ? Example of a requirement flowing from the business to development and testing Story kickoff with the developers and QA who signed up for the story where the business context, scope and acceptance criteria of the story were explained BAs test the application on developer’ machines to give quick feedback – saves the SME’s time
- such as test-driven development (TDD) and continuous integration (CI) play an important role in feedback cycles for development teams. Tests, for example, are an effective way of communicating design intent and requirements to distributed team members. More social-engineering practice "Collective Code Ownership" is also critical to distributed agile teams. Encourages trust to work off same codebase – pre-requisite are high levels of unit testing and CI Build pipeline with staged builds so that you get feedback on your code immediately You don’t want the entire team waiting on your broken build – which reminds of the social discipline of not leaving a broken build for the other team to fix
- Agile practices involve a lot of testing and testing early Also a large focus on automating tests so that the team becomes more efficient Testers create test scenarios QAs created test scenarios for the stories and got them validated by the BA or SME Creating of functional and performance testing environments offshore to ensure the feedback loop is closed
- High levels of communication are required for distributed teams and this means that you should not lose sight of the work-life balance After all, we want the teams to run at a sustainable pace Other practices like cross-pollination help in surfacing these issues and making others in the team sensitive to them The major pain area being common meetings which needs to be scheduled keeping the other time zones in mind – share the pain - Representatives dialling in Mindful of weekends, local holidays and festivals Example : You may not want to schedule Friday morning team meetings in a western timezone when you have an offshore team since it often means they will have to stay late on a Friday evening
- Knowing where the team stands is important – more so when you have teams split across locations
- Source control repositories allow teams to work off same codebase – but you need a test and CI setup in place to allow people to work without the fear of disrupting the rest of the team’s work Phones, Instant Messenger, VC all enable teams to stay connected and keep the information flowing Keeping physical card walls synchronized across multiple locations is a painful activity - Tools like Mingle from ThoughtWorks have taken real world agile metaphors such as the card wall and digitized it Email - daily status update mails were sent by the offshore IM and by the onsite coordinator to keep the team informed of story, defect and release status. Iteration Notes on a daily basis in the project wiki Team leave plans were shared in the project wiki Information radiators – example : we setup one which was a stuffed toy that would clap in the customer’s office every time a story was signed off
- Regular showcases & retrospectives provide visibility across locations Larger formal retrospectives are very tough to do distributed – end of iteration feeling the team’s pulse can be done Give bad news early as possible – we can try and fix things only when we know about it
- Especially in greenfield app dev with high customer touch, stabilize the team and then move offshore So what I mean is – try and get to a point where the velocity or throughput per iteration is predictable The team that you put in place to reach this point of stability needs to include a good mix of folks from all locations This means a higher cost, but the long term benefits of a team that can more easily hit their stride are worth it
- Identify the roles that are going to be critical for your project – BA, Iteration Manager, Lead Tester etc Right choice of the people Invest in rotations to build trust