Meeting the challenges of agile principles: An offshore Scrum Master perspective
The 12 agile principles lay the foundation for a successful agile team and deliver a product that meets customer satisfaction. Every principle is an absolute necessity to build great software and great teams. While these principles have stood the testimony of time over a decade now, much has changed the way we build and deliver software, especially from an offshore perspective. Adoption of agile methods does not simply imply a framework or a process implementation, but it goes beyond that.
In this talk, I share the experience of a Scrum Master, who in hindsight, look at the challenges such as lack of trust, micro management, lack of technical excellence, managing stakeholder’s expectations etc. and the impact on team’s performance. This is the result of ignoring agile values and principles which could have been avoided. Lastly, we look at the actions taken by the team and Scrum Master to turn on the challenges into a win-win situation for both onshore and offshore teams and become one of the successful agile teams.
Outline/structure of the Session
In this interactive session, I walk you through the challenges of being in the hot seat of a Scrum Master at offshore, what are the dos and dont’s , what actions you take when you realize that on ground your project is everything but “Agile”
Part 1: Challenges of a Scrum Master at offshore
Part 2: Challenges and influence on agile principles
Part 3: Remedial actions, ways to make the agile principles work to your advantage
From this session, you will learn:
- The practices at planning and tracking level to build teams around agile values and principles.
- The Offshore scrum master challenges and actions to be taken
- Team's self assessment for continous improvement
Scrum Masters, Scrum Teams, Managers, Customers/Product Owners
schedule Submitted 3 years ago
People who liked this proposal, also liked:
A Practical Guide to Setting up Distributed Agile Projects
A practical guide to setting up a new agile project team. Based on years of agile delivery and coaching experience for projects in a number of distributed and offshore models, for teams sized from 10 to 200 people, and spread across 4 continents, and 8+ locations. Some areas that will be touched on:
- People - how to organize distributed teams, cultural factors to consider, ways to build trust, and how to avoid timezone burnout.
- Process - how to communicate effectively, plan collaboratively, setup distributed practices (standups, retros, pairing, etc), effectively divide work on a common codebase, maintain visibility, and track progress.
- Tools - (tips provided as a handout) which hardware and software tools should you absolutely invest in to help overcome communication, visibility and collaboration challenges
A Principle-Centered Approach to Distributed Agile (OR) Distributed Agile: Ten Guiding PrinciplesRaja Bavani
schedule 3 years agoSold Out!
The challenges in distributed agile can be seen under three broad categories viz., a) Communication and Coordination, b) Time Zone Differences and c) Issues related to People, Culture and Leadership Style. Successful teams consciously adhere to certain principles and it is their principle-centered approach that helps them face such challenges and deliver the best.
Steven Covey wrote: "Principles always have natural consequences attached to them. There are positive consequences when we live in harmony with the principles. There are negative consequences when we ignore them. But because these principles apply to everyone, whether or not they are aware, this limitation is universal. And the more we know of correct principles, the greater is our personal freedom to act wisely." This is true in all situations of life and it includes application of agile methods in geographically distributed teams too.
This session is to present the ten principles and elaborate 3-4 principles learned through experience in working with project teams and interactions with industry experts, and applied for more than a decade. These ten principles are above and beyond agile manifesto and agile principles. These are related to areas such as context-specific methodology, tools for productivity improvement, infrastructure for communication and coordination, knowledge management, focus on quality, inclusion, collaborative governance, automation, technical debt management, iteration progression and ensuring early success.
Distributed Product Owner Team for an Agile Medical DevelopmentAndrea Heck
schedule 3 years agoSold Out!
We are developing medical imaging and workflow software in an agile way with development teams distributed to several countries. One of the major challenges is how to set up and communicate within the Product Owner team. There we have to deal with the distribution, e.g., have the Product Owner either onsite with her peers or with her Scrum team, travelling, or with proxy. We need people who are good in two different fields of knowledge: medical and software development. As a third issues, the environment of the customers may be different in different countries.
We have ramped up local Product Owners in different countries, have found local collaboration customers, and have developed a set of communication channels and workshops how to synchronize Product Owners in the team, share a common vision and backlog with their Scrum teams, and collaborate with customers locally and globally.
The different engagement models, processes, challenges and solutions for a distributed Scrum Team in an outsourced product development (OPD)Pooja Wandile
schedule 3 years agoSold Out!
A distributed Scrum team is a necessity than a choice in many cases. Often customers and their suppliers struggle to put up a team model that will work effectively and provide maximum value. The customer wants to be absolutely sure how the entire engagement will be executed so that there are no surprises later.
So, what are the different ways of forming teams in a distributed environment, what is the impact on the execution, how do you execute different engagement models, what challenges do you see and so on? These are the questions the customers are interested in.
This talk will focus on answering the above questions. We have defined 3 types of distributed team models and implemented in few of the projects in an onshore-offshore scenario. We have also tailored scrum meetings like planning, DSM, etc. so that these meetings are more effective in distributed model. While some of the changes have worked, some still needs to be enhanced further.
Can India be truly Agile?Joe Zachariah
schedule 3 years agoSold Out!
It's Indian Independence day today as I work on this proposal. As I read newspapers today, I understand the importance of the IT and ITES Offshore business, which has almost single handedly provided employment to millions of technically suave and English speaking folks. One question that repeatedly comes to surface is whether the Indian IT industry will be able to up its game from the servicing mentality which started the boom of IT in India. As Agile and Scrum began to become the flavour of the worldwide IT industry, many firms in India also went out on the Agile path, many of them out of pressure from their Western clients. Some of them were successful, but there are also numerous examples of failures of the Agile model and also half hearted adoptions, which have led Western businesses to believe that maybe India is not adept enough to take its game to the next level where teams can follow the Agile framework.
My talk would be driven by my experiences of following Agile in different ways in my different teams over the last 6-7 years. My forays into the Agile ways of software delivery in India have been largely successful and I cannot see a reason why Agile will not work in India.
In my talk, I would focus on the reasons on why Agile would work in India. Right from the way we approach diversity and inclusivity, to the way we approach our post election coalition party governance model, the Indian way of living is rife with finding innovative ways to quickly adapt to change, which essentially is the Agile mantra.
I plan to start with a simple example. Of the Western way of cooking & dining as compared to the Indian way of cooking & dining. A traditional Indian kitchen is a sacred space. It is decorated with auspicious signs. Sometimes, it doubles up as a puja room. In many households, you are not allowed to enter the kitchen with footwear, you are expected to bathe before lighting the kitchen fire, you are not allowed to eat unless you have taken a bath - these can be metaphorically compared with the Ceremonies that an Agile team practising Scrum follows - the daily standups, sprint planning and reviews, etc. However the core delivery is the food. And no matter what ceremonies you follow and what your menu for the day is, the food comes out daily at the same time and is served everyday with the same set of stakeholders. There aren't as many tools and supporting equipment that you might see as in a Western kitchen, but at the end of the day the practices followed in a typical Indian kitchen are very Agile at heart.
There are many other examples from Indian culture and mythology that one can refer to understand that Indians are essentially Agile at heart. Open source product groups, many of which are largely Agile, can also find a reference point in Indian culture and mythology. That which is timeless is referred to in the Indian context as Sanatan. It refers to wisdom that has no founder and is best described as collaborative and open source freeware. Every idea is accepted but only that which survives the test of time, space and situation eventually matters.
There are many myths circulating in the IT industry that Agile cannot survive in India, since Indians cannot be trusted to be self governed and always require direction. Also Indians don't know how to have fun at work. Through my presentation I seek to dispel those myths drawing from Indian mythology and culture and essentially try to make folks understand that reasons for Agile not working in India is the same as Agile not working elsewhere. What you need to make Agile work at the end of the day, is just the belief that it will work.