What if you could write functional tests without writing a single line of application code? What if those tests are written in plain English (so that anybody could understand) but still it's executable spec or source-code? What if you could generate the documentation from live production source code? Now you don't need to update the requirement doc all the time.

What's Specification by Example? Is it different compared to BDD? Who all participate in defining these specifications? Are functional tests and functional specifications same? These are the questions this session tries to answer.

Lean Startup has revolutionized the startup movement. Startup world is looking like more scientific these days. Because of that reason, a flood of people are trying their hands by opening new startups. However is there anything to learn from Lean Startup for enterprises using agile methodologies currently? This session tries to answer the same - ranging from how to use Lean Startup techniques as part of Agile Product Ownership to changing current Agile practices focused towards validated learning and customer development.

Take away for audience from this session is:

• How Agile Product Management can scientifically define, what exactly to build and why?
• How some important Agile practices need to improvise themselves based on Validated Learning and Customer Development concepts of Lean Startup?
• Instead of building the MVP or product features directly and finding out later that customers don't need them, finding that out sometimes without writing even a single line of code or with minimal investment and resources.

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.

What if you could write functional tests without writing a single line of application code? What if those tests are written in plain English (so that anybody could understand) but still it's executable spec or source-code? What if you could generate the documentation from live production source code? Now you don't need to update the requirement doc all the time.

What's Specification by Example? Is it different compared to BDD? Who all participate in defining these specifications? Are functional tests and functional specifications same? These are the questions this session tries to answer.

What if you could write functional tests without writing a single line of application code? What if those tests are written in plain English (so that anybody could understand) but still it's executable spec or source-code? What if you could generate the documentation from live production source code? Now you don't need to update the requirement doc all the time.

What's Specification by Example? Is it different compared to BDD? Who all participate in defining these specifications? Are functional tests and functional specifications same? These are the questions this session tries to answer.

What about a case where the whole team is completely distributed, i.e. every team member works from a different distributed location, possibly from a different country or from a different time-zones. What about the challenges faced while working with a team where time-zone changes can be 7-8.

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.

Way back in 2008, when I started working in Agile, there was enough material available on Scrum and. However when it came to distributed aspect of it, people were still struggling with it. Based on working for years in this fashion, I realised that communication, trust, transparency and innovation are the core fundamental values towards successful distributed Agile implementation.

In other words, as most of the problems were caused by softer aspects of skills (misunderstanding, miscommunication, non-availability of people, mistrust etc), humanizing the distributed team experience looked like the key for successful distributed Agile implementation.

Based on working with distributed teams over the years, we discovered some distributed Agile patterns. Some of them got blogged from time to time. Those already available in form of blogs are as follows:

• Distributed Pair Programming
• Local Retrospective
• Agile way of documentation
• One Team Multiple Projects
• The nut/bolt pattern for distributed Scrum development
• Chain-Link Pattern
• Virtual One Room

The session is to share the these patterns and more (when to go for distributed Agile and when not etc)

When it comes to software quality, everybody wants good quality software only. However when it comes to define, measure and achieve it objectively, confusion prevails. Different people and different perceptions.

So how to define software code quality, how to measure it and build a culture towards great code quality software, take proactive steps instead of reporting based reactive steps? These are some important aspects this session will touch-base.

On top of that, we all have heard about Continuous Integration, Continuous Delivery and Continuous Deployment, but what's this Continuous Inspection all about? What all is involved to achieve that and how to achieve that with Jenkins and with other Continuous Integration servers? Along with answers of all these questions, a hand-on demo will be given as part of the session.

Way back in 2008, when I started working in Agile, there was enough material available on Scrum and. However when it came to distributed aspect of it, people were still struggling with it. Based on working for years in this fashion, I realised that communication, trust, transparency and innovation are the core fundamental values towards successful distributed Agile implementation.

In other words, as most of the problems were caused by softer aspects of skills (misunderstanding, miscommunication, non-availability of people, mistrust etc), humanizing the distributed team experience looked like the key for successful distributed Agile implementation.

Based on working with distributed teams over the years, we discovered some distributed Agile patterns. Some of them got blogged from time to time. Those already available in form of blogs are as follows:

• Distributed Pair Programming
• Local Retrospective
• Agile way of documentation
• One Team Multiple Projects
• The nut/bolt pattern for distributed Scrum development
• Chain-Link Pattern
• Virtual One Room

The session is to share the these patterns and more (when to go for distributed Agile and when not etc)