This is a story of a small IT service company in India with a capacity of 80-100 people.I worked there in senior leadership role. The key USP of the company was its focus on technology innovation, thought-leadership, have great technology talents and flat hierarchy. It was an IT service company and was implementing XP, Scrum, CI/CD, Distributed Agile practices since 2006 to its core.

The company environment was very open. Employees were encouraged to consider organisation like a clean slate. They could write on it whatever they want as long as it brings improvement in status quo and a group of colleagues are convinced about the idea.

If anybody felt uncomfortable the way things are working in the organization, she could initiate a discussion in the company around the change and if idea makes sense, it gets implemented.

Considering all mentioned above, it was not a surprise anymore to see a big focus on the following mantra in the company.

Scratch your own itch. If it’s itching you hard, fix it.

Essentially people were encouraged to come up with solutions and actions to execute, instead of just listing problems. Everybody in the company was considered an equal partner in improving things.

The result was – anybody could start any initiative, which he/she thinks to be beneficial for the organization. Senior management helped in shaping up the ideas. However people themselves had to sell their ideas to fellow colleagues and garner support.

To provide some impetus and catalyst to these cultural changes, we started promoting some activities like writing blogs, creating videos on our technical expertise, groups on Software technology design aspects, participating as speakers in various technical conferences, exploring new technologies and then doing sessions for the entire company.

Initially everything worked as expected. However after few months or so, to my surprise, steam began to die down. Many people backed out when it came to do some work, though they expressed their keen interest initially.

Another important fact was – only few selected people were participating in most of the activities. Just 5-10 out of 70-80 people was not an encouraging number. Again this is what I saw in many other organizations.

Rest of the story is about the turn-around of the company when we started aligning people's passions and interests towards the long-term organizational goals. After some time we started getting sustainable and dramatic results.

At one point, people writing on corporate technical blog were around 5–10% of total number of people. That changed to around 50–60% people in the organization.

Initially that happened because of the interest shown by truly interested people about it and then because of healthy competition among the colleagues.

We started finding the involvement of people in various activities like hiring improvement initiative, building technology guilds, multimedia and marketing, software design competition, organizing events, innovation and speaking in conferences.

This whole system evolved in a well-oiled engine which was ready to take any technological challenge from any client. It obviously improved employee morale. With the word of mouth and good feedback, we started getting great employee references.

The 3 questions based Daily Scrum is the defecto way of doing Daily Scrum across teams. For years people have been finding it inadequate as it tends to focus on individuals rather than team and sprint goal, promotes status update kind of discussion rather than collaborative sync-up and becomes an accomplice in promoting zombie Scrum.

The 3 questions based Daily Scrum, unfortunately, doesn’t require collaboration as a mandatory prerequisite. Without mandatory collaboration, no team becomes self-organized as the Development Team continue to be dependent on someone like Scrum Master to organize them as a team.

In 2017 update of Scrum guide, because of all these reasons, 3 questions based Daily Scrum became one of the many Daily Scrum implementations.

However in the absence of any better alternate, people continue to use 3 questions based Daily Scrum.

This alternate implementation of the Daily Scrum, called Collaborative Daily Scrum considers collaboration (pair programming, swarming or mob programming) as the mandatory aspect of the Daily Scrum. The focus is on sprint goal and working as a team and not on individual updates anymore. At any point of time, the team plans to finish at most 2-3 stories collaboratively which helps in automatically limiting the WIP on the Scrum Board.

This implementation has been well received which was published through an AgileBuddha blog post. The post includes the inputs from James Coplien (inventor of daily standup).

This session helps in understanding problems when teams move towards Agile but leadership is still stuck with waterfall mindset. It also helps in understanding why Agile transformations fail.

Even after making transformation efforts for multiple years, in many enterprises, people start doing Agile "process" eventually. But the whole setup, organisational culture, hierarchy, siloed mindset, delays across departments remain same. Even after spending millions, the benefits remain negligible. The enterprise doesn't become agile enough in coming out with innovation and anticipating disruptive changes in the market

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)