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.  

 

 
8 favorite thumb_down thumb_up 15 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

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

Learning Outcome

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

Target Audience

Scrum Masters, Scrum Teams, Managers, Customers/Product Owners

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Ravi Kumar
    By Ravi Kumar  ~  3 years ago
    reply Reply

    Hi Pooja,

    Many of the conference attendees are requesting presentation slides. We find that your proposal on http://confengine.com/ is not updated with your session slides. Request you to kindly update the same.

     

    Thanks and regards,

     

     

    Ravi

  • Pramod Sadalage
    By Pramod Sadalage  ~  3 years ago
    reply Reply

    Pooja,

    Would you be able to convert this to a 20 min experince report? Which will allow you to distill your thoughts and also provide a concrete list of learnings.

    Thanks

    • Pooja Wandile
      By Pooja Wandile  ~  3 years ago
      reply Reply

      Well, I can try, may be I will have to trim down some of the points.

       

      Regards,

      Pooja

      • Naresh Jain
        By Naresh Jain  ~  3 years ago
        reply Reply

        Request you to please update your proposal to reflect the same.

        • Pooja Wandile
          By Pooja Wandile  ~  3 years ago
          reply Reply

          Done. Changed it to 20 mins experience report.

          Do you have any specific format for the experience report or I am free to choose my own format?

           

          • Naresh Jain
            By Naresh Jain  ~  3 years ago
            reply Reply

            Choose your own format. We care about the content, not the format/template :)

  • Ravi Kumar
    By Ravi Kumar  ~  3 years ago
    reply Reply

    Hi Pooja,

    Thanks for the submission.

    The topic synopsis and learning outcomes suggest that the target audience for this presentation are new comers into agile. There might be very few people who would be interested in attending 45 min Agile 101 session. My suggestion is pick one of two practices and showcase how effectively you have implemented that others could learn/take away from your session.

    Thanks,

    Ravi

    • Pooja Wandile
      By Pooja Wandile  ~  3 years ago
      reply Reply

      HI Ravi,
      Thanks for your review comments.
      As for the target audience, I believe it should be of interest not only to agile newbies but also to those who have been through its rigour. This talk is inspired from a failed project where agile principles were ignored. I plan to cover the challenges that were faced and what solutions could have been implemented though the team could never do so but these are learnings for the new project. The team did fail fast.
      I am sorry but can you please elaborate more on your suggestion to pick one or two practices? I am unable to understand  what you are trying to suggest. 

      Thanks,
      Pooja

      • Ravi Kumar
        By Ravi Kumar  ~  3 years ago
        reply Reply

        Hi Pooja,

        While the talk is about a failed project I am not sure if the audience will be interested to hear only about the failure. You have said that the team failed fast; what happened post that. Was there anything the team did to improve and better the practices? If there are one or two practice improvements then as a audience I might be motivated to hear about them.

        Hope this should give you an idea to tweak/update your proposal.

         

        Thanks,

        Ravi

         

    • bruno orsier
      By bruno orsier  ~  3 years ago
      reply Reply

      Pooja, I like your proposed topic very much; indeed it addresses the common criticism that only successful agile projects are presented/discussed. The failed projects are much more interesting as a learning opportunity. And it is very important to learn through failure, at individual level, team level  but also company level. Thus I think your presentation should try to cover these different levels.

      Best regards

      Bruno

      • Pooja Wandile
        By Pooja Wandile  ~  3 years ago
        reply Reply

        Thanks Bruno for your encouraging words. I also strongly believe that there is much more to learn from failed projects also. At least, failed projects tell us what should definitely not be done.

    • Kwong Hon
      By Kwong Hon  ~  3 years ago
      reply Reply

      Hi Pooja,

      Perhaps a deck or chart to show comparision of a successful vs failed Agile project. Highlight key characteristics of both. What should have been done better. Also, if possible root cause of missing the "Agile" points in the failed project.

      Also, another deck / chart of an actual project is everything but "Agile". Highlight what's missing. And what it should be, if it is to be "Agile.

       

      Thanks,

      Kwong Hon

    • Sudipta Lahiri
      By Sudipta Lahiri  ~  3 years ago
      reply Reply

      Hi Pooja,

      Can you pls give some insight into the "certain things do not work when teams drift away from the core agile principles"... nothing detailed but at least 2-3 lines so that we understand what you going to talk about.

      Also, where is this experience based on? You have referred to a case study... can you give an idea of the project/environment on which the case study is based on? Have you presented this in any other conference/gathering before?

      Regards
      Sudipta.

      • Pooja Wandile
        By Pooja Wandile  ~  3 years ago
        reply Reply

        HI Sudipta,

        Thanks for your review comments. Here are the details that I plan to cover:

        This talk is inspired from one of the recent failed projects, a typical onshore-offshore model. After doing post mortem, it was found that the customer never followed agile in spirit but only on paper or to his convinience/advantage. Almost 9 out of 12 principles were never put in practise, ofcourse I don't plan to cover all the 9 principles but the important 3-4 principles that I believe if could have been taken care of , the project may not have failed. For e.g. Team will never be motivated if customer does not show faith in their abilities and does micro management on a day to day basis, clearly a failure of one of the agile principles. Similarly, how the quality will suffer if team is not given room for technical skills enhancement especially while working on new technologies and resulting burnout of the team leading to more frustration, and likewise. I do plan to cover what solutions can be implemented to avoid recurrence of such problems.

        I have not shared this before but planning to publish a paper soon.

        Hope this helps,

        Thanks,

        Pooja

         

    • Naresh Jain
      By Naresh Jain  ~  3 years ago
      reply Reply

      Pooja, request you to please respond to the comments below.


    • Liked Tarang Baxi
      keyboard_arrow_down

      Tarang Baxi - A Practical Guide to Setting up Distributed Agile Projects

      45 mins
      Talk
      Beginner

      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
    • Liked Raja Bavani
      keyboard_arrow_down

      Raja Bavani - A Principle-Centered Approach to Distributed Agile (OR) Distributed Agile: Ten Guiding Principles

      Raja Bavani
      Raja Bavani
      Chief Architect
      Mindtree
      schedule 3 years ago
      Sold Out!
      20 mins
      Experience Report
      Beginner

      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.

    • Liked Andrea Heck
      keyboard_arrow_down

      Andrea Heck - Distributed Product Owner Team for an Agile Medical Development

      Andrea Heck
      Andrea Heck
      Agile Coach
      Siemens AG Healthcare
      schedule 3 years ago
      Sold Out!
      45 mins
      Case Study
      Advanced

      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.

    • Liked Pooja Wandile
      keyboard_arrow_down

      Pooja Wandile - The different engagement models, processes, challenges and solutions for a distributed Scrum Team in an outsourced product development (OPD)

      45 mins
      Talk
      Beginner

      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.

       

    • Liked Joe Zachariah
      keyboard_arrow_down

      Joe Zachariah - Can India be truly Agile?

      45 mins
      Talk
      Beginner

      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.