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.

 
 

Outline/structure of the Session

I will present some typical problems that many agile projects are facing, and analyse some of the root causes. This will revolve around the lack of a common understanding of what problems need to be solved, and how the software is supposed to behave.

I will give a high level introduction to BDD - which is probably very different than what most people associate with BDD.

My goal is to invigorate people to try out some new techniques to get their half-arsed agile projects back on track.

Learning Outcome

  • Breaking user stories down into rules and examples
  • How to specify with concrete examples
  • Running three-amigos meetings
  • Preventing bugs rather than finding them

Target Audience

Product owners, business analysts, developers and testers

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal

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

    As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

    One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

    How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

    Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

    This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

    In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

  • Liked Naresh Jain
    keyboard_arrow_down

    IAmA (I Am A ... Ask Me Anything)

    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Beginner

    On Reddit, IAmA stands for "I am a" and AMA stands for "ask me anything".

    In an IAmA post, a person will post what they are, and other people will ask the original poster some questions to gain insights about the experience the person has had.
     
    Ex: I'm Jeff Patton, creator of Story Mapping, Ask Me Anything... OR I'm Diana Larsen, co-creator of the Fluency Model and co-author of Agile Retrospectives, Ask Me Anything...

    We plan to take this concept and apply it to the Agile context. We've few luminaries at the conference and we plan to do an live interview with them using this format.

  • Anton Zotin
    Anton Zotin
    schedule 2 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    This workshop will help participants to understand how the Kanban method really works.

    We will learn how to use the Kanban method to visualize your current process ("start where you are"). Will figure out how to limit work in progress (WiP); define and make process policies explicit; measure and manage flow.

    Also we will figure out what does it mean to search for opportunities for continuous improvement. We will learn how to increase your team speed and at the same time decrease pressure at work.

    All of these we will touch through extremely hands-on step-by-step simulation using LEGO bricks.

     

  • Dhaval Dalal
    Dhaval Dalal
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    "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.

  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Why do we see new process or methodology or movement every 10 years or so in the software industry? And why don't successful companies ride on their success forever? Naresh Jain uses the Adaptive Change Cycle (ACC) to explain the rationale behind it. Once you understand ACC, this talk will help you understand how to prepare yourself and your organisation to quickly move through the 4 stages of ACC: reorganise, exploit, conserve and release to constantly keep innovating. If you feel agile methods are stagnating and looking for what to expect next, this talk might give you some ideas.

  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    60 mins
    Case Study
    Intermediate

    Before you write any code, make sure you have a failing test." This was a revolutionary idea, when it was first pitched in the late 90’s. Many successful entrepreneurs have been practicing a similar approach - "Before you build a product/service, make sure you have paying customers." In this talk, Naresh Jain shares his approach of finding effective MVPs to validate his Educational Product and why Agile Methods simply fail to do so. If you are interested in finding out how to maximise your validated learning for minimum investment, then this session is for you. Recently Naresh's article on this topic was published by InfoQ.

  • Aslak Hellesøy
    Aslak Hellesøy
    schedule 2 years ago
    Sold Out!
    480 mins
    Tutorial
    Intermediate

    Behaviour Driven Development (BDD) is a set of practices and tools that enables business analysts, developers and testers to collaborate on a single source of truth: Executable Specifications.

    Executable Specifications are living documents that serve several purposes.

    • For business analysts they are a concise way to express how they want the software to behave
    • For developers they are unambiguous requirements that guide and validate the implementation
    • For testers they are automated regression tests

    Executable Specifications are easy to read by both humans and computers. They are great for building a shared understanding across different roles on a software project. This shifts the focus from finding bugs to preventing them.

    Product owners and business analysts are encouraged to join this session even though the second half will involve a little coding. Non-technical attendees will be paired up with technical attendees to create executable specifications together.

  • Liked Ankur Sambhar
    keyboard_arrow_down

    Promiscuous Pairing - More the merrier !!!

    Ankur Sambhar
    Ankur Sambhar
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    Being Agile developer, have tried & tested various flavors of pair programming over the years while working in highly motivated self-managed team. Some experiments worked while some worked better :)

    This talk is about sharing the personal experience of practicing promiscuous pairing which allowed the team to be always in the beginner's mind state and being able to push the boundaries consistently.

    This experience sharing talk is based on our successful adoption of the promiscuous pairing technique based on very famous research paper by Arlo Belshee "Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience".

  • Liked Prasad Kunte
    keyboard_arrow_down

    Implementing Agile Engineering Practices in Legacy Codebases

    Prasad Kunte
    Prasad Kunte
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    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.

  • Sachin Natu
    Sachin Natu
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    60 mins
    Case Study
    Intermediate

    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.  

  • Liked Yuval Yeret
    keyboard_arrow_down

    Understanding and Implementing DevOps Flow

    Yuval Yeret
    Yuval Yeret
    schedule 2 years ago
    Sold Out!
    480 mins
    Workshop
    Intermediate

    DevOps seeks to extend the agile benefits of Flow, Collaboration, Inspect and Adapt thinking all the way to Production. While DevOps and Continuous Delivery were born in the world of web operations in companies like Etsy, Google, Amazon, Facebook and Flickr (also called Unicorns in the DevOps community) it is now clear that Enterprise IT/Product Development companies (also known as Horses) can  also benefit immensely from the ideas and practices and achieve similar results if they manage the change/journey towards DevOps in a way that makes sense in their context. In this workshop we will introduce the concepts of DevOps and Continuous Delivery and help attendees figure out how DevOps can fit into their world as well as how a “DevOps Implementation” might look like.

  • Liked Ashish Parkhi
    keyboard_arrow_down

    Techniques to Speed Up your Build Pipeline for Faster Feedback.

    Ashish Parkhi
    Ashish Parkhi
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    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.

  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    In order to achieve my goals, as a buyer of your product, I want awesome feature.

    AT: make sure your users stories don't get in the way.

    Users Stories, the tool teams use to break big ideas into small demonstrable deliverable, are easy to describe and challenging to write effectively. In this hands-on workshop you'll learn how to write great user stories that adhere to the INVEST principle. We'll learn various techniques to slice your stories using the vertical-slicing approach. We will discuss what elements should be included in the stories, what criteria you should keep in mind while slicing stories; why the size of your user story is important and how to make them smaller and efficient.

  • Saket Bansal
    Saket Bansal
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Why organizations are adapting towards agile? Is it to get most out of their resources or is it about doing the right thing?

     

    Traditional mind set of achieving high productivity and using resources efficiently does not change easily, even when organization moves to agile they remain more and more worried about the team velocity. When I meet agile practicing companies or I attend event on agile I find that most of

    the focus is on delivering product backlog efficiently. We see lot of talks on how to make team more self-organizing so that they can do the things faster.  Even after moving to scrum or agile we keep ignoring the warning

    “There is nothing so useless as doing efficiently that which should not be
    done at all.”  —Peter F. Drucker

    When most of the organization starts with agile they takes it as an engineering process, and most of the team focuses too much on velocity, while to get maximum out of agile we need to look at Enterprise Agility, we need to look at an organization’s entire value stream—from idea to implementation, from concept to consumption.

    My talk would be focusing on need of organization agility and will introduce one of the monitoring tool “Life Cycle Profitability “which can help organizations in getting answers of questions like :

    • Should we delay the release by one month to fix the defects ?
    • Should we reduce the cycle time by adding one more team?
    • Should we delay the release to add functionality?
    • Should we delay the project by one month to get more innovative ?

    Life Cycle Profitability is based on principle “Take an economic view” introduced in book:The Principles of Product Development Flow , Donald G. Reinertsen . In my talk I will be showing how we can convert proxy variables like cycle time , velocity , technical debts  into Life Cycle Profit.

    I presented part of this concept in one of the conference and got good response, but I will create fresh presentation for this talk, since this time I will put more focus on expanding the model to calculate the Life Cycle Profit.

  • Liked Ashish Parkhi
    keyboard_arrow_down

    Gamifying Agile Adoption - An Experiment

    Ashish Parkhi
    Ashish Parkhi
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    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