Effective "Code-branching" strategies are still one of the most ignored in Agile development world. In this talk, using case-studies, I would like to present what is wrong with traditional strategies, how it hinders teams to deliver continuously and why Trunk Based Development (TBD) is a durable solution. Furthermore, the talk aims to explore various strategies (code/dev and ops) that enable teams to attain TBD. Finally, the talk ends with successful TBD case-studies.

 
2 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

1. Start with case studies of "smelly" commonly used branching patterns [10 mins]
2. What is Trunk Based Development (TBD) and its importance in CD [5 mins]
3. TBD strategy - Feature Toggle [5 mins]
4. TBD strategy - Branch by Abstraction [10 mins]
5. FaceBook case study [5 mins]
6. Google Case study [5 mins]
7. Wrap-up and Q&A [5 mins]

Learning Outcome

1. What is Trunk Based Development (TBD)
2. finding motivation to favour TBD, if you want to deliver continuously.
3. Various strategies to support TBD - feature toggles and branch by abstraction
4. Learning from case-studies of branching strategies in Facebook and Google
5. Scaled Trunk Based Development

 

https://solutionsiq.app.box.com/s/ody694q7yxeq8ea8h7i2vcad7lticsz3

Target Audience

Coaches, Developers, Architects, Techno-functional Managers

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Naresh Jain
    By Naresh Jain  ~  2 years ago
    reply Reply

    Hi Devesh,

    Branching is an important topic, however very contextual. Also it can vary quite a bit depending on your choice of workflow. IMHO participants would get the most, if you can take a specific project, you worked on and tailor this proposal to an experience report or case study, where you present:

    1. context of your project
    2. challenges faced without TBD
    3. how you went about introducing TBD
    4. challenges faced while introducing TBD
    5. how you resolved those challenges
    6. benefits your team is getting after moving to TBD
    7. some limitations or drawbacks of TBD
    8. next steps from TBD

    If this makes sense, please update your proposal accordingly. Also as Joel pointed out, please share a video from your past presentation so we can see your on stage presence.

    • Devesh Chanchlani
      By Devesh Chanchlani  ~  2 years ago
      reply Reply

      Apologies for the delayed response given extended festivities of Diwali.

      Thanks Joel & Naresh for your valuable inputs. I will revamp my presentation as per your inputs and should be able to upload the updated presentation soon.
      Also, unfortunately, I do not have a video to share as there was no video recording in the last 2 conferences I spoke at. However, I have few snaps which you can have a look at. https://app.box.com/s/xqrtcatbqlghi122eonv9fqizs0a9nu0

      • Naresh Jain
        By Naresh Jain  ~  2 years ago
        reply Reply
        Thanks Devesh. Can you please create a 2 mins video (trailer) of your talk and update the proposal with a link to the same? We don't need a high quality video, it can be taken from your phone or you could use Google Hangout Live to record it.
  • Joel Tosi
    By Joel Tosi  ~  2 years ago
    reply Reply

    Hi Devesh,

        Thanks much for this submission, it strikes a real note with me as I see tons of groups embracing the newest repos (i.e. git) but not even thinking about branching strategies.  I look at gitk with them , and it is a mess.

    I like the flow of the session and the examples.  The only question I have is when you have delivered this session before, what have attendees taken away and been able to 'do' afterwards?  You make a great case for TBD, is there a connect to help them get there you make in the presentation?

    Best,

    Joel

    • Devesh Chanchlani
      By Devesh Chanchlani  ~  2 years ago
      reply Reply

      Hi Joel,

      Thanks for your interest. I delivered this session in XP-Conference, Bangalore (Aug 2015).

      I could notice attendees quickly resonating with the pain and challenge involved with traditional and most-widely used branching strategies. Also attendees acknowledged the fact that not merging, but the real pain was not being able to deliver/deploy continuously with such branching strategies. I think the mindset to 'question yourself twice every time you want to branch', was the key take away for the attendees.

      I am not sure what they were able to do afterwards, but post the session, I was part of a lot of interesting conversations where folks were introspecting keenly on their branching strategies. However, being a coach, I have helped many teams appreciate and adapt TBD.

      Let me know if I was able to answer your queries appropriately.

      Thanks,
      Devesh.

      • Joel Tosi
        By Joel Tosi  ~  2 years ago
        reply Reply

        Hi Devesh,

           Thanks for the response. Do you have a video you could share?

         

        Best,

        Joel


  • Liked Jayaprakash Puttaswamy
    keyboard_arrow_down

    Jayaprakash Puttaswamy - Transformation - The Devil is in the Execution

    45 Mins
    Talk
    Advanced

    This talk is an experience sharing session about what it takes to realize business benefits in a large-scale (beyond 100 people) agile transformation. Having driven more than 4 large-scale transformation initiatives (of scales 160 to 700 people) over last 5 years, I would be sharing a couple of case-studies where I worked recently and I would discuss various challenges of implementing large-scale transformation and possible approaches to handle them. Participants would be engaged through interactive discussions on mutual experience sharing with a focus on key dimensions of agile execution.

    As the title reveals, the talk would focus more on execution challenges and approaches to handle them at all levels of stakeholders involved in a transformation. Levels include developers, architects, managers (project/engineering), senior management (delivery/program management, directors) and CXO's. More details in Outline section. 

    The key dimensions to be covered include

    1. Building and sustaining learning culture (approaches include Community of Practice, Guilds and Joint Workshops)
    2. Causing the mindset shift in engineers (different approaches for developers, architects and engineering managers)
    3. Enabling managers to create and nurture agile engineering culture (approaches include effective metrics about quality of code, tests, application and build)
    4. Inverting the Test Pyramid (approaches include test automation strategies, BDD, dealing with Legacy using Strangler pattern, Component Guardian pattern)
    5. Leadership Agility (approaches include catalyst style of leadership, risk driven decision making, leading the change)

     

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    Madhavi Ledalla / Devesh Chanchlani - Autonomy in Teams - Why & How !

    90 Mins
    Workshop
    Intermediate

    This is a fast paced workshop of 90 minutes, split across 3 progressive parts/activities. The intent of the workshop is to bring out the challenges that organizations face due to their traditional structure, during their Agile adoption journey. In the workshop, we emulate such an environment and try to have a first-hand experience of the difficulties faced both at the team and managerial levels (Part A). Subsequently, we let people form their own teams which are "Autonomous". (Part B). Now, we deliver as newly formed teams. (Part C).

    The final debrief revolves around importance of "Autonomous teams" in terms of quality and individual motivation.

  • Liked Raji Bhamidipati
    keyboard_arrow_down

    Raji Bhamidipati - Remote working in an agile world

    45 Mins
    Talk
    Intermediate

    Remote working in an Agile world

     

    My experience of being a remote tester in an agile team

     

    Main statement:

    What does it mean to you/your colleagues/your company if you are a remote worker? How is it different to being an ‘office worker’? Let’s find out!

    Abstract

    Picture this!  – I landed a job with a company and team that I had wanted for a long time. Everything was going to plan until after about a year when I faced relocating to a far off land due to personal reasons. Imagine having to give up a job that you love and believe is going to be good for your career progression. Imagine working for a company that’s so awesome that, when I told them I had to move, they offered me the chance to become a full time remote worker!

    This was about 6 months ago and I have been a full time remote tester since then. I have learnt a lot during this time and want to share my experiences with you.

    Geographical limitations no longer stop people from working on awesome teams, or stop companies recruiting the right testers for the job. There are huge benefits for the remote worker and the company alike.  However, there are also drawbacks on both sides and remote working is not something to take lightly.

    At NewVoiceMedia we run a ‘Remote Working Community of Interest’ where we tackle some of the difficulties faced by remote workers as well as enjoy the benefits. To make remote working work there have to be changes made by the remote worker, the company and the colleagues who work in the office.  I want to present what these changes could be and could potentially mean to you, and your team.

     

     

     

     

  • Liked ShriKant Vashishtha
    keyboard_arrow_down

    ShriKant Vashishtha - Completely Distributed Agile - A Case Study

    ShriKant Vashishtha
    ShriKant Vashishtha
    Agile Coach
    Malonus
    schedule 2 years ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    What about a case where the whole team is completely distributed, i.e. every team member works from home, possibly from a different country or from a different time-zones. What about the challenges faced by a team where team-members are distributed with 7-8 time-zones.

     

    In the new era of Lean Startup, some startups are working and developing software in this fashion. This session is a case-study of one such startup which is completely distributed. How they are working, are they using Agile or have evolved some new practices which work for them. What kind of different challenges these teams face on regular basis and how do they solve them, these are some of the question this session tries to answer.

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    Madhavi Ledalla - Gamification –an essential element for vibrant retrospectives.

    Madhavi Ledalla
    Madhavi Ledalla
    Agile Coach
    ADP
    schedule 2 years ago
    Sold Out!
    90 Mins
    Workshop
    Intermediate

    High performance agile teams are always striving to achieve an effective retrospective that enables the team to discuss the success criteria, and define the areas of improvement further.  This is an important aspect for cross functional teams – the development, operations, database administrators, systems administrators, QA testers, product managers - to focus on excellent communication and collaboration. 

    Over the years, my experience has been that retrospectives can get monotonous with time, and hence tend to become ineffective. The more I engaged with the process, the more I felt the need to revolutionize the process, bring out something new, fun, and exciting to make the retrospectives vibrant.  The other interesting aspect I came across during my research into the subject was the theory of gamification and the universality of its application. 

    During this session the audience will understand how the concept of gamification brings in a completely different dimension of thinking while maintaining the element of fun as we try and apply it to a few everyday situations!

     I have leveraged Luke Hohmann’s Innovation Games, The Conteneo Collaboration Could platform for this concept of gamification so that distributed teams can benefit by this.  

     

  • Liked Vijay Bandaru
    keyboard_arrow_down

    Vijay Bandaru - Enterprise Agility - Not a Cakewalk

    Vijay Bandaru
    Vijay Bandaru
    Agile Coach
    IVY Comptech
    schedule 2 years ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    I worked as a coach and have experience ranging from team level to large scale agile transformation that involves:

    - Multiple teams from different locations
    - Different cultures
    - Variety of structures
    - Component teams
    - Strong silo working culture
    - Legacy code base
    - Different release schedules and processes
    - Wide range of tools
    - And many other challenges

    As part of working on the assignments to help the organizations transforming into agile, I had come across various anti patterns and road blocks at various
    levels. These anti patterns are very critical to understand and help the organizations to tackle them effectively without compromising on the core agile
    values and principles.

    It is very easy for any organization to kick off the transformation but it is very hard to maintain the sustainability and become a matured agile organization. During this period there will be many traps that will force the organization to take a U turn and get back to where they started. Lot of effort, money and time gets wasted in this process. It is important to understand the key areas of enterprise agile pathway and decide the roadmap for the transformation with a clear vision and goal. Periodic inspection and adaption is also critical in this whole process to successfully achieve the vision and goal of transformation. top to bottom of the organization will play very vital role in this journey, without proper collaboration, communication and understanding among these teams, organization cannot transform. 

    Once the transformation kicked off, organization will go through a whole set of different challenges during their release planning, sprint ceremonies, collaboration issues, cross location team challenges, tools and processes and these are also critical humps to crossover successfully. 

    Another important area that usually will not get enough importance in transformation is the "communication" part. Agile emphasizes more on "face to face" communication. But is it just enough talking face to face? Conflict --> Communication --> collaboration --> Value delivery. This path has to be clearly understood at all levels of organization. 

    My topic is going to cover these anti patterns that I had come across in my coaching experience and share them with the audience. As part of this session, I am also planning to conduct a survey to see how many of these anti patterns are common to the organizations that are transforming into Agile. I will collect the survey information from the participants by providing them a quick hand copy of the survey form. This information will help me for my paper that is in progress on the "Enterprise Agile Transformation".

    I am also planning to have some activities within the session by giving the audience some challenges of transformation and try to find suggestions to arrive at solutions to tackle those challenges. This part will make the session interactive and two-way knowledge sharing.

    The anti patterns will be mostly around the following categories:

    - Management responsibility
    - Structural challenges
    - Product teams
    - Portfolio management
    - Scrum teams
    - Scrum Master
    - Support teams (Sales, Marketing, HR, Admin etc)
    - Communication
    - Continuous improvement
    - Tools
    - Processes

    I will also cover, what was done for some of the key anti-patterns to address them as part of the transformation engagements.

  • Liked Sekhar Burra
    keyboard_arrow_down

    Sekhar Burra - Raising the Bar: Being a true influential agile leader

    Sekhar Burra
    Sekhar Burra
    Coach
    Independent
    schedule 2 years ago
    Sold Out!
    90 Mins
    Workshop
    Advanced

    This is a nurturing workshop for Agile Managers to become effective influential servant leaders, to support enterprise agility.

    This is a workshop for Agile Managers and above to help them shed the command and control behavior and be more of a facilitator and coach for their teams. At the end of this workshop, the participants will understand and appreciate the insights and techniques of being an Agile influential leader. The participants also walk out with a concrete action plan on how they support the agile teams and organization. The whole workshop runs on the technique of asking powerful questions to the participants, thus making them think towards the path of self-discovery.

    The number of participants for this session are limited 20-25

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    Madhavi Ledalla - The Essence of Product Ownership.

    Madhavi Ledalla
    Madhavi Ledalla
    Agile Coach
    ADP
    schedule 2 years ago
    Sold Out!
    20 Mins
    Experience Report
    Beginner

    This is an experience report based on my interactions with the Product Owners. 

    Scrum introduces a very vital role called the Product Owner who is the key person responsible for the product success; he is one who is accountable for the customer delight.

     In this session we would talking about essential characteristics  and responsibilities of a PO by discussing some of the challenges using specific scenarios.

    Format of this session:

    1) Commonly seen anti patterns of the PO

    2) Typical challenges that can derail a Product Ownership and what can be done to overcome these challenges. These challenges if not resolved, which agile principle we would not be able to adhere to will also be discussed during this session. The scenarios presented here are the real time scenarios that I have seen with the teams while working with them.

    The idea of this session is to talk about the challenges seen with the Product group  in big organizations that have a legacy of products and multiple teams working on them.

  • Liked Sridharan Vembu
    keyboard_arrow_down

    Sridharan Vembu - Over-selling the "Enterprise Agile Frameworks and Certifications"

    Sridharan Vembu
    Sridharan Vembu
    Head Engineering
    CreditMantri
    schedule 2 years ago
    Sold Out!
    45 Mins
    Talk
    Intermediate
    Agile is only for smaller projects and/or startup organisations - Not Anymore. Taking my own and my organisation's experience, Agile is a proven methodology that is well suited for delivering complex, distributed, multi-year enterprise programs, for many years now.
     
    While this is really a great thing for agile enthusiasts and practitioners, it’s a bit of worrying sign for me the increased recognition and popularity the ‘Agile Certifications’ and ‘Agile Frameworks’ are receiving among individuals and organisations who would like to adopt Agile to stay relevant in current world.
     
    I would like to share my views on the adoption of these frameworks and certifications, why I feel they are not-so-agile and how am I and my organisation are solving similar problems without the need for any of these frameworks and certifications.
     
    I am planning to walk through the complete life cycle of the most recent program that I’m part of (from Inception to Initiation to on-going Execution to Post-Production Support) and bring out the relevant agile principles that we adopted, context based customizations we did and the best practices that we have come up with.
    • For instance, one should know the clear difference between hygienic practices vs context based practices - the first ones are not to be compromised at any cost, whereas the latter ones are to be applied based on the need, not because some framework prescribes it.
    The typical life cycle stages that we follow in any program / project delivery is normally: Discovery - Inception - Initiation - Execution - Transition, whereas the actual set of practices within any of these stages and how they are being implemented could be very different from project to project, team to team. 
    • For example, in the Execution Phase, doing pair programming and following TDD are hygienic practices for us. Having said that, it’s perfectly okay for a pair to split and work on a specific task on a case-to-case basis (we call this Pragmatic Programming) and the pair decides when and how long they would split and when to re-join.
    To give an idea on the complexity, enterprise and distributed nature of the program, some key data points:
    • Started almost 3 years ago, on-going
    • 10 quarterly planning workshops done so far
    • 10+ teams, 7 timezones
    • peak program size: 250+
    • peak team size from my org.: 50+
    • total no of systems: 10+
    • geographical spread: plan: 100 countries, 132 locales launched so far: 53 countries, 56 locales
    • 140 page-views / sec
    • Av. response time: 1.3s
    • Handling 100+K products in the catalog, 15+ K pages , 300+ K responsive images
    • Blue-Green production deployment (zero downtime over 1.5 years)
    • 3 weeks cycle of production releases