Sorry, no proposals found under this section.
 
Sorry, no proposals found under this section.
 
  • Michael O'Reilly
    Michael O'Reilly
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    Test Requirement Driven Development(TREDD) places a renewed emphasis on quality and accountability, and provides the insight to allow your product development and management teams to make the necessary changes in order to produce outstanding quality products on schedule, in a cost-efficient and highly collaborative manner.

    What separates TREDD from other development methodologies like TDD (test driven development), ATDD (acceptance test drive development), or BDD (behavior driven development), is the status of the test requirement when the product development lifecycle concludes.

    Test Requirement status is the breakthrough element that allows test requirement to provide an objective measurement to the quality of the product development team, so that adjustments can be made for subsequent product development iterations that will ensure quality improves, as well as increase the effectiveness of the product development team.

    Come and learn how your TREDD will catalyze your SCRUM team toward greater capabilities, quality, accountability, and satisfaction!

  • Liked Niraj Bhandari
    keyboard_arrow_down

    Adopting Agile - Will you end up missing the soul of your product

    Niraj Bhandari
    Niraj Bhandari
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    The aim of this session is to sensitize the audience about the need to have a holistic approach to Agile product development than a blind faith approach.

    Let us take this through an example. Can you name some of the success stories of agile. I did a google search and the list comprised mainly of startups who are anyway doing quick fire work. Try searching for established players and the name which crops up is Salesforce. Facebook is another example which people are quick to point, but facebook doesn’t acknowledge using the Agile as such.

    Let us try and drill down further using these two examples. Salesforce acknowledges that it has tremendously improved the delivery of its features using agile methodologies over time. Great, but wait a point, is the promise of agile to speed execution. No, the premise of agile is to improve the quality of your deliverables and by quality I mean the value derived by a user/consumer. It helps you build the right product. Unfortunately there is no easy way to measure the value delivered by saleforce to its user through these new features.

    Let us now shift gears and look a bit more closely at facebook. Facebook releases features very frequently, almost on daily basis, sometimes even on hourly basis. They are betting big on test automation and continuation integration to ensure that new features don’t cause a breakage. They also seem to be following the agile’s premise of “fail early” by quickly pulling out features which don’t get desired traction from users. So far, it looks a great story and if you are a technical person, you are etching to work for such a company which allows you to experiment with your ideas and put them in production to get instant feedback. Now let us through an alternate perspective – what if some of the features need gestation period before people start liking them. Not every features becomes an instant hit. Remember the classical “Crossing the Chasm” technology adoption lifecycle (couldn't add the image because of editor limitations)

    Some features would need a push to cross the chasm and become successful, but if they are pulled down based on initial traction, you may be losing some of the valuable features. Another twist in tale in this case is what the user research/product management do in this scenario. Aren’t they supposed to do some upfront work to figure out which features have better chances of being accepted and focus energy on helping them cross the chasm. That leads us back to the question we started out with – In our drive to do frequent releases, putting the features out for customers to experience and try, are we missing big picture and just building the product rather than creating a product with a soul. Or is it like we should spend some time upfront to create a “soulful” product and then go full steam in building incremental features. At this point of time it may also  be useful to look at the stories coming out regarding the potential failure of Universal Credit program in UK, which supposedly used Agile but has all but abandoned it. Here are the links, which we would use to structure a discussion around exercising caution while practicing Agile as compared to just rushing into it because everybody else is doing it.

    Resources for structuring discussion around Universal Credit Discussion-

    https://www.techwell.com/2013/07/worlds-biggest-agile-development-project-collapses

    http://www.computerweekly.com/blogs/public-sector/2013/05/dwp-drops-agile-from-flagship.html