location_city Bengaluru schedule Mar 25th 03:30 - 05:00 PM IST place Esquire Hall

"To know, is good. To live, is better. To be, that is perfect." - The Mother

During the Agile adoption, its a common complain that many team in many organizations get caught up in the ceremonies or mechanics of Agile and fail to understand/appreciate the true value and spirit of Agile. And because of this, the original intent of the Agile movement itself is lost. This is a serious issue!

This workshop will highlight, a well-proven approach to transformation (not adoption) and show the distinct steps in this journey that an individual or a collective goes through when learning anything new. Activities, serving as examples, in the workshop, will focus to show the journey - that is, how to begin with rituals, then gradually move to practices, arriving at principles and eventually internalizing the values. Witnessing this gradual process of transformation will help participants discover for themselves their current progression. We hope this will serve as a guiding light during their Agile journey.

Finally, we will leave the participants to ponder upon and discover for themselves their ideals in life and work as this is not only applicable to software development, but also to any discipline where humans are involved, including life itself.


Outline/Structure of the Workshop

To help the participants understand the progression from rituals to values, we'll take 4 common XP/Scrum practices [TDD, Daily Stand-up, User Stories and Retrospective] and show the journey from rituals to practices to principles and finally to values for each of them.

This is a hands-on session, which means the participants will actually take part in this journey. (To hear, is good. To see, is great. But to experience, is priceless.)

  • Stand-up's journey from rituals to values [15 mins]
    • Demo of a very ritualistic way of conducting stand-up [3 mins]
    • Participants help us to move away from the ritual and see the actual stand-up practice [3 mins]
    • Another demo of what a stand-up would look like, if we focused on the core principles behind the stand-up [3 mins]
    • Finally a glimpse of what a stand-up would look like, if we focused on the core values behind the stand-up [3 mins]
    • Recap of the journey and its importance
  • TDD's journey from rituals to values [15 mins]
    • Demo of a very ritualistic way of doing TDD [3 mins]
    • Participants help us to move away from the ritual and see the real TDD in practice [3 mins]
    • Another demo of what TDD would look like, if we focused on the core principles behind TDD [3 mins]
    • Finally a glimpse of what TDD would look like, if we focused on the core values behind TDD [3 mins]
    • Recap of the journey and its importance
  • Similar break-up for User Stories and Retrospective (15 mins each) [30 mins]
  • Recap - Definition of rituals, practices, principles and values [10 mins]
  • Finally define ideals and map them to values. [10 mins]
  • Q & A [10 mins]

Learning Outcome

  • A realization that transformation is a journey from rituals to values.
  • Clear delineation between Rituals, Practices, Principles and Values.
  • What are Ideals and how they map to values.

We hope that it would leave the participants inspired enough to introspect the values they live or ideals they manifest. We expect the participants to go back to work and reflect upon their journey from rituals to value in their work context and refine their approach.

Target Audience

Anyone interested in understanding the true meaning of Agile - Scrum Masters, Developers, Testers, Business Analyst, Product Owners, Agile Coaches, Managers , CxOs



schedule Submitted 7 years ago

  • Aslak Hellesøy
    Aslak Hellesøy
    Cucumber Limited
    schedule 7 years ago
    Sold Out!
    60 Mins

    As lead developer of Cucumber and author of The Cucumber Book, Aslak gets asked to consult with organisations who want to introduce Behaviour-Driven Development (BDD). Time after time, he meets teams who are trapped doing half-arsed agile. They do the easy, obvious, visible agile practices, and none of the powerful, hard-to-master, hard-to-see ones.

    When these teams ask for help learning BDD, we get a chance to remind them how important conversations and collaboration are in software development. We teach them to write tests before they write code, as a way to explore and discover the hidden details of a requirement just before they dive in and start building it. This talk will make you wince with recognition, laugh with despair, and finally inspire you with stories of teams that have finally, after years of flaccid scrumming, discovered the true collaborative heart of agile software development. You’ll see patterns you recognise from your own teams, and gain insights about how to fix them.

  • Ashish Parkhi

    Ashish Parkhi / Naresh Jain - Techniques to Speed Up your Build Pipeline for Faster Feedback.

    45 Mins
    Experience Report

    We would like to share our experience and journey on how we brought down our Jenkins build pipeline time down from over 90 minutes to under 12 minutes. In the process, we would share specific techniques which helped and also some, which logically made sense, but actually did not help. If your team is trying to optimize their build times, then this session might give you some ideas on how to approach the problem.

    Development Impact - For one of our build job, below graph shows how the number of builds in a day have increased over a period of time as the build time has reduced. Frequency of code check-in has increased; Wait time has reduced; failed test case faster to isolate and fix.

    Business Impact - More builds leading to quicker feedback and faster story acceptance and less story spill over.

  • Ashish Parkhi

    Ashish Parkhi / Naresh Jain - Gamifying Agile Adoption - An Experiment

    45 Mins
    Case Study

    While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?

    Dhaval Dalal introduced me to Prof. Kevin Werbach’s definition of Gamification – “The use of game elements and game design techniques in non-game contexts.

    For our 4th ShipIt Day, organized on 25th/26th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention, from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.

    The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.

    Landing Page

    User Profile

    Update -

    1. Deducting points seems to be bothering the individuals. Now we are experimenting with getting rid of negative points and introducing short lived badeges instead e.g. "Build Breaker".
    2. We have now added more badges to recognize individual efforts in various categories.
    3. Working on open sourcing the core app at https://github.com/IDeaSCo/rockstar
  • Prasad Kunte

    Prasad Kunte / Naresh Jain - Implementing Agile Engineering Practices in Legacy Codebases

    45 Mins
    Case Study

    Afraid of legacy code? Don't be!!!

    Most successful product companies are confronted with the problem of legacy code.

    What is a legacy code?

    • A code which is in production for several years.
    • A super-complex, hard to understand code base, written by different set of developers. 
    • Outdated Technology stack.

    But the most hurting reality is:

    Lack of confidence in the code due to zero or poor test coverage.

    Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."

    Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.

    As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.

    One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little. 

    Today we all know this is a BAD option!!!

    Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.

    How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.

    What do we do?

    Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:

    1. Re-structuring the Project code-base
    2. Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
    3. Creating/fixing the build script 
      1. Setting up an auto DB deploy tool and integrating it with build scripts
    4. Set up basic CI pipeline
    5. Write a few work-flow tests to capture the system's flow from user's point of view
      1. Find the inception point in the code from where we can exercise the code
      2. Restify the application at the inception point (one service at a time)
      3. Setup authorization for production and test environment
      4. Build minimal test-data set for different environment 
      5. Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
    6. Write business logic acceptance test to capture various complicated business rules
    7. Test drive the new enhancement or bug fixes
    8. Every time we touch legacy code, refactor the code and improve test coverage at unit level

    This really helped us test driven the new code and implement all the layers of the test pyramid.

    If you've a similar situation, join us, as we share our experience on how to confront legacy code.

  • 60 Mins
    Case Study

    Adopting agile development practices and continuous delivery is becoming a norm in the software industry. Time to market and frequent releases have drastically reduced time available for regression testing. Inspection is considered wasteful. Faster feedback cycles during development is crucial. These have created lot of challenges for testing community, which traditionally relies on manual testing assisted by UI based test automation.

    This is an experience report of transforming testing practices across organization, which decided to embrace Agile. Today our testers are not trying to find defects, instead they collaborate with product management and developers to prevent them in the first place. In fact, during the appraisal process, the defects found by them is ignored, instead we focus on how much time they are able to dedicate to collaboration and exploratory testing. The boundaries between developers and testers have faded away and today quality is whole team's responsibility.

    We started with less than 20% of our testers with automation skills (mostly UI automation) and rest of them relying on manual testing. However, today, all our testers practice BDD. They have picked up Java & Groovy programming skills. They are able to contribute Workflow tests, Integration tests and Business Logic Acceptance Tests. Early collaboration and pairing is the norm. By the time developers are done with their tasks, all checks are already automated and hence we are able to deploy software every fortnight to production.

    Are your testers finding it hard to make this transition to an Agile mindset? This session will give you some concrete ideas based on our transition at IDeaS.