Most of us these days develop applications and deploy them on servers, either on-premises or in the cloud. We need to plan well ahead in time as to how much server, storage and database we need. We also need to plan for deploying all the hardware and software necessary to run the application. The question here is, if is it possible to avoid all this planning? Are we looking for a new model that can handle all the underlying infrastructure deployment for us? This session is going to describe about serverless architecture and application in detail. The session will also cover on building microservices using serverless architecture. Hands-on exercise will be part of this session.

The moment I ask about Devops, I start hearing about lots of tools and automation. While working with various organizations I observed that we read about importance of communication and collaboration for Devops. However we ignore that and focus more on tool adoption and automation as learning new tool is easy and more interesting to any technical person. In this session I’m going to talk about how we could make communication and collaboration between two teams, Dev and Ops, more effective. How we could break down the silos between these two teams so that they can work as a single team for same goal and reach the state of Devops in reality.

Developing product with Built-in quality is always desired outcome. Organizations follow various strategies for the same such as horizontal slicing, acceptance criteria and end-to-end automation testing. In this session I'm going to explain how it can be achieved through:

Vertical slicing is a technique used to develop software by driving a thin vertical slice (cross-sectional slice through the layers), which is functionally coherent and demonstrable, then progressively widening it with consecutive slices

BDD stands for Behavior Driven Development and BAs, Dev and testers collaborate and write scenarios to cover expected behavior of application

Test Pyramid highlights that we should have more low-level tests (such unit tests) than high-level tests (end-to-end tests).

I have used them effectively while coaching various teams. I'm going to share my experience supporting real time examples through this session.

A common misinterpretation is that BDD is another way to automate the functional testing or just a synonym to Acceptance Test Driven Development (ATDD). However, it’s not correct understanding. BDD doesn’t talk about testing rather it focus on development which is driven by expected behaviour of application/system. It helps to share the understanding by examples among three amigos (BAs, Developers and Testers) and helps to explore unknown. It describes what business/end users want the system to do by talking through example behavior.

In this workshop, the actual concept of BDD is explained using case study of various real-time projects. It also covers the myths, challenges, benefits and best practices along with tools used to adopt it.

Its a simple game which helps to learn how to estimate or calculate the business value of user stories.

The intent of this game is to provide more insight on prioritization of User stories or Epics. Even though we do backlog grooming, we see that the PO is not able to bring US prioritization in the real context to the team. We can also observe that teams are not really challenging the PO about the prioritization.

This workshop is about how to involve the team more on the prioritization excercise. The PO will come out with Business value and the team will come out with the cost estimation. There will be discussions with PO and the team to understand the, what is the priority and why? As a result the the team will know why they do, what they do. This will maximize the value of their outputs.

We have used this in our work with various teams and seen it is very effective. We will talk about the examples as well.

This talk is intented to demonstrate, Agile adoption is not just process change. We will elaborate the need of engineering practices adoption as well. This will help organization to re-look at their transformation or adoption strategy.

This talk will touch upon the basics of Continous Delivery adoption and practicess like

• Different approaches like, Scrum, Kanban,Scrumban
• Behaviour Driven Development
• Test Driven Development
• Pair Programming
• Continuous Integration
• Feature Toggling
• Trunk Based development
• Continuous Deployment
• Infra as Code

We will stich together these various practices and procesess together to showcase how a balance of process and engineering practices can help Agility.

Often we find it difficult to incorporate any changes in a software project during later phases of its development, or during post-delivery maintenance. Primary reason for this is inflexibility in design and code which makes it difficult for changes to be incorporated. This inflexibility substantially increases the cost of making changes and this metaphor has been termed as Technical Debt.
While Technical Debt cannot be eliminated completely, its burden needs to be reduced. Many agile practitioners have suggested some practices to avoid or eliminate Technical Debt.
In this session I shall discuss about a method to get relief from Technical Debt and talks about nine proven practices that a developer can follow to minimize Technical Debt. These practices help to:

• Change the coder's mindset so that they should use technical practices i.e. various refactoring techniques to reduce technical debt in code and design
• Developers to plan and manage the time to pay down the debt i.e. determine your living budget
• Take minimal technical credit in design and code

These practices have been used and found to be effective when implemented in projects which will be used as a case study.