• Liked Jeganathan Swaminathan
    keyboard_arrow_down

    TDD - the good, bad and ugly part

    Jeganathan Swaminathan
    Jeganathan Swaminathan
    schedule 1 year ago
    Sold Out!
    45 mins
    Workshop
    Advanced

    Being an Agile Coach & TDD Consultant, I have helped many product companies during their Agile transformation journey. I have observed many interesting good, bad and ugly practices followed in industry in the name of TDD. I would like to share my experience with the audience and guide them towards the correct direction and help them extract the true benefit of TDD.

    To give a simple example, using code-coverage as a metrics to measure the effectiveness of the Unit Test Cases is one of the common mistakes committed by many companies. 

    In my presentation, I would like to demonstrate hands-on and discuss, how to effectively follow TDD and what to watch out and avoid bad practices in TDD.

  • Anand Bagmar
    Anand Bagmar
    schedule 1 year ago
    Sold Out!
    60 mins
    Demonstration
    Intermediate

    The key objectives of organizations is to provide / derive value from the products / services they offer. To achieve this, they need to be able to deliver their offerings in the quickest time possible, and of good quality!

    In order for these organizations to to understand the quality / health of their products at a quick glance, typically a team of people scramble to collate and collect the information manually needed to get a sense of quality about the products they support. All this is done manually.

    So in the fast moving environment, where CI (Continuous Integration) and CD (Continuous Delivery) are now a necessity and not a luxury, how can teams take decisions if the product is ready to be deployed to the next environment or not?

    Test Automation across all layers of the Test Pyramid is one of the first building blocks to ensure the team gets quick feedback into the health of the product-under-test.

    The next set of questions are:
        •    How can you collate this information in a meaningful fashion to determine - yes, my code is ready to be promoted from one environment to the next?
        •    How can you know if the product is ready to go 'live'?
        •    What is the health of you product portfolio at any point in time?
        •    Can you identify patterns and do quick analysis of the test results to help in root-cause-analysis for issues that have happened over a period of time in making better decisions to better the quality of your product(s)?

    The current set of tools are limited and fail to give the holistic picture of quality and health, across the life-cycle of the products.

    The solution - TTA - Test Trend Analyzer

    TTA is an open source product that becomes the source of information to give you real-time and visual insights into the health of the product portfolio using the Test Automation results, in form of Trends, Comparative Analysis, Failure Analysis and Functional Performance Benchmarking. This allows teams to take decisions on the product deployment to the next level using actual data points, instead of 'gut-feel' based decisions.

  • Liked Devesh Chanchlani
    keyboard_arrow_down

    Branching for Continuous Delivery? Think Again!

    Devesh Chanchlani
    Devesh Chanchlani
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    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 tealk ends with successful TBD case-studies of Facebook and Google.

  • Neha Rahaman
    Neha Rahaman
    Shashank Kapoor
    Shashank Kapoor
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    This fun group game is a simulation of Kanban methodology in the software delivery cycle. It shrinks the complete delivery cycle in this short game giving a real essence of how Kanban works.

    The WIP limits in the kanban game, just as in real kanban, prevent work from being pushed to the next step and encourages the team to focus on the bottleneck before progressing.

    It uniquely demonstrates the dependencies in the operations, or time constraints and deadlines.

  • Liked ashish kumar
    keyboard_arrow_down

    Exultant Appraisal "Appraisal in Scrum team : The Self-Appraising Team"

    ashish kumar
    ashish kumar
    uday
    uday
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    However exhaustive and meticulous your current employee appraisal process is, chances are you aren't pleased with the outcome. The primary objective of a performance appraisal is performance improvement, starting with the individual and rolling up to the organizational level. But an individual who doesn't fare well in an appraisal feels demotivated, defeating the purpose of the exercise.

    Agile owes its success and failure to its team.

    A lot been discussed on different agile groups related to performing the appraisal of team members when success / failure belongs to team.

    This is an Attempt to provide solution to appraising scrum team members remaining in agile framework and philosophy.

    We would be discussing The Challenges of current appraising process along with the Challenges brought up with adopting agile process.

    To address these challenges we would be sharing 'The proposed solution' and it's alignment with agile philosophy.

     

  • Liked Yogesh More
    keyboard_arrow_down

    Fish for Thought: Hook on to the Agile mindset!

    Yogesh More
    Yogesh More
    Meenakshi Koul
    Meenakshi Koul
    schedule 1 year ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    While adopting the Agile methodology, one of the critical aspects of this change is the mindset change. As is said, Agile is more about the mindset than the process to be followed. If the mind adjusts the process then follows. As with other organizations adopting to Agile, and adapting to it, we too have been through this change management & transformation. The biggest transformation needed is  the agile mindset or agility in thinking & acting, and our experience has been that it takes a while to adjust to it. It needs a mindset and a cultural change in an organization to completely embrace and realize the full potential of Agile.

    How does one achieve the mindset adjustment or get this cultural change in our teams & make it a habit? How does the leadership bring about this transformation in themselves and their teams, especially the teams with prior experience working on waterfall or iterative systems. The challenge to adapt is at all levels viz. at individual, team, and at the leadership level too.

    One of the popular culture change tool and now a philosophy and training is the “FISH PHILOSOHY-Catch the Energy and Release the Potential”. In our experiments on the cultural change, we see this addressing certain aspects of ushering in the agile culture or the mindset within the teams. This is an attempt to bridge this transformation with the techniques of the Fish philosophy. The energy seen due the FISH philosophy at the work place is used as navigate this transformation and bring about the culture of Agile in thinking, then doing would follow easily.  

  • Liked Mohit Jain
    keyboard_arrow_down

    Understanding Story Points as an estimation techniques for Scrum teams.

    Mohit Jain
    Mohit Jain
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    A deep-dive session about story point, and why its gaining acceptance over traditional estimation methods.

  • Liked Sanjay Kumar
    keyboard_arrow_down

    Refactoring Strategy for Big Design Smells

    Sanjay Kumar
    Sanjay Kumar
    schedule 1 year ago
    Sold Out!
    60 mins
    Case Study
    Intermediate

    Agile design or emergent design relies heavily on timely refactoring efforts that aim to improve existing design. Yet often, when the code base grows or when someone else's code is handed over to us, there is a reluctance to refactor existing code - despite an obvious design smell. While the reasons to avoid refactoring may be well-grounded – lack of time, lack of understanding or fear of breaking it – in the long term, delaying code refactoring makes the code rot further. And, as a result, technical debt continues to pile up.

    This session begins by reviewing common design smells, discusses five key features of good code and then discusses a common yet often overlooked design smell in detail – big methods. Using an example of a big method, it proposes a refactoring strategy that will ensure that a refactoring effort does not cause any negative side effects. During the session, participants are walked through a real code refactoring example – step by step.

    Though the session focuses on one particular design smell (big methods), the proposed refactoring strategy should apply equally well to other design smells too.

Sorry, no proposals found under this section.