While it is true to say that people’s attitudes and beliefs are key to implementing an agile project, or Agile in itself, much of the use of the term ‘mindset’ implies a mental model that can be defined and engineered. In this presentation, we will look at how we can measure attitudes within an organization and use multiple small actions to trigger the rapid evolution of organizational culture, so that it can sustain agile developments. Mindset and the alignment-based ideas of some on the Agile movement too often imply creating homogeneous beliefs and values that will lead to full alignment. In practice, this damages resilience and can be dangerous. This presentation will introduce the idea of coherence instead of alignment - the celebration of cognitive and behavioral differences that can align if needed to support the delivery of sustainable solutions.

We all know what a product is. We buy and use them all the time. But, what does it mean where you work? Are the things you build or make really products or not? Are you creating a successful product, or just doing a job? We’ll talk about what product thinking really means and why you and your company may not actually be using it. And, if you’d like to be more product-centric, some specific principles for doing that.

Because when the pandemic hit, we saw dramatically rapid shifts in strategies, supply chains, and processes designed to accommodate a completely different world than existed in February. The most important one, I think, is that urgent need for technology changes drive just about everything, but the technology change has nothing to do with software and everything to do with supporting some new situation that requires a change in the underlying technology – NOW!

In this new normal there is a clear goal for everyone on a team – we must suddenly shift production from fresh salmon to frozen salmon, or from commercial packages of flour to consumer packages of flour – with specialists in all relevant fields applying their expertise to accomplish that goal. Or we have to shift all teaching to online in a week, accommodating teachers who have never taught online and students who have questionable internet access. The list goes on -but the underlying message is the same – it's not about software, it’s about providing the technology infrastructure to accomplish something urgent and important that is much bigger than software. It never was about software, but never has that been so clear as it is now.

Whether you are a manager, scrum master or engineer, you need to know why and how the technical practices of test-driven development, refactoring, continuous design, clean code and automated testing can help you and your organization be great.

Technical excellence is more than two-week sprints, a burn-down chart and a daily stand-up meeting. The basic rules of Agile or Scrum are not an end in themselves, but a starting point based upon principles and practices that allow and encourage teams to adopt, adapt, and refine their craft. Unfortunately, it may seem to the technical people that agile is just another micro-management approach.

Extreme Programming with its provocative name, got people’s attention in 1999. It is based on sound technical practices. Why do so few agile teams employ engineering practices that support the tight iterative cycles of Agile and Scrum? The creators of Scrum expected the continuous improvement cycle to pull engineering practices into teams once the cycle revealed the problems of poor product quality, hard to change code, wasted time debugging, long stabilization efforts and the ever-growing burden of manual test. This talk will cut through the mystery and show why we should all strive for Technical Excellence.

We are all here for the same purpose: to ensure the systems we build operate reliably. This is a difficult task, one that must balance people, process and technology during difficult conditions. We operate with incomplete information, assessing risks and dealing with emerging issues. We have found Chaos Engineering to be a valuable tool in addressing these concerns. Learn from real-world examples of what works, what doesn’t, and what the future holds.

Perfection is unattainable yet we live in a world where we are encouraged to compare ourselves and our work to an impossible standard. Come here to understand why chasing this goal will destroy the systems, companies, and lives you're supposed to make better and how injecting a little imperfection into your day will help make everything better.

The shift from industrial to product thinking is profound. Digital product thinking is not an evolution of industrial thinking, it is a different thing altogether. Tools and structures that support industrial efficiency work against digital product efficiency, and vice versa. Great industrial leadership doesn't transfer to great product leadership.

Industrial thinking built a 400-million customer, India-wide 4G network from scratch in less than 8 years. Now they are pivoting into a digital platform company. They still need great industrial thinkers and leaders, but they will be sharing the stage with a new generation of great digital product leaders.

This talk contrasts these two mindsets and explores why they are so different, and offers some suggestions for thriving in a hybrid industrial-product world.

Aren’t we fascinated looking at a gymnast performing a routine? A trapeze artist swinging from one side to the other? An acrobat doing his/her amazing balancing act? But, we know little of the mechanics behind such feats of balance. All this is controlled by the ear and the brain. The semicircular canals of the ear act as a gyroscope and accelerometer to control angular acceleration and to help you decide which plane the head is moving. Unfortunately, millions suffer from various balance disorders.

NeuroEquilibrium™ is a pioneer in the field of vertigo and balance disorders aiming to provide advanced and economical medical assistance to people suffering from these conditions. We are making groundbreaking innovations in this field by developing indigenous vertigo diagnostic systems which operate on cutting-edge technology like 3D Printing, Cloud Computing, VR, AI, etc.

In this talk, we'll share our experience building NeuroEquilibrium.

Networks pervade nearly everything we do in software development. Our code runs on networks but it is also a network of relationships among its parts. Our teams are networks too. Our organizations are as well. In this keynote, Michael Feathers will outline several principles of network science that underlie the structuring of workflow, organizations, teams, and code. This common frame can help us make better decisions as we tackle problems in our work.

We overload our terms a lot in this industry. "Coupling" is one such. That word covers situations ranging from essential to accidental to comical to cosmic. Coupling seems to be the root of all ills. It is the molasses that slows our every move. And yet, in the industry from which we borrowed the term, "coupling" was not a dirty word. It meant something ingenious. Let us contemplate coupling for a time and see what we can do about it.

In a complex, interdependent eco-system, where each service is evolving rapidly, we typically end up with an Integration Hell .i.e. the myriad problems that occur when API integrations break down

• Provider and consumer integrations break when their understanding of the API endpoints are out of sync
• Working integrations break when the API developer makes a change without informing the consumer
• Development and testing slow down when the consumer depends on the provider API running in a staging environment:
  • The network may be down
  • The environment hosting the API may be down
  • The staging API may crash, or may not even be started
  • Development can be delayed if the staging API is not kept up-to-date
  • API changes can come in at the last minute, resulting in breakage on the consumer side
  • The provider API may break backward compatibility, resulting in breakage on the consumer

Instead, what if we could make the dependencies between the provider and consumers explicit in the form of executable contracts. These executable contracts provide a common, clear definition of their API endpoints. They give instantaneous feedback about accidental breakage to the teams so that they can work independently. These executable contracts are:

1. Kept up-to-date and acts as a single source of truth
2. Used for service virtualisation, keeping consumers in sync with the contract
3. Run as tests against the provider API to validate it's request and response type definitions
4. Tightly integrated with CI
5. Capable of pinpointing any backwards-incompatible changes to the contract

This is Contract Driven Development, and it heralds the Death of Integration Hell.

Here's a sample contract:

This session will demonstrate all the key points of Contract Driven Development as implemented by the teams using an open-source tool called Specmatic.

As an executive, learn how to create a culture in your Product Development Organisation that Delivers On-Time and Under-Budget, every time.

The Problem: Even when having an Agile organisation, projects tend to deliver late and over budget. As a result, executives can not promise delivery times and meet them, and they can not set prices and ensure a profit.

The Solution: There is now a growing group of companies that do things differently. They have learned how to deliver on-time and under-budget, every time. Maybe even more importantly, they have learned to deliver the expected improvements desired by their customers and stakeholders.

DateTime: This workshop is scheduled on Oct 12th and 13th from 2 PM to 6 PM IST (4 hours each day)

Branch By Abstraction is the lesser-known development practice for software development organizations doing Trunk-Based Development. It is the key technique with feature-flags that allows such teams to implement larger and longer-to-change pieces of work that would otherwise be done on a separate branch. Paul introduced the world to this in 2007 (with materals that made it into the famous Contiuous Delivery book) and talks attendees through the practice.

Servirtium == Service Virtualized HTTP (for Java and other languages) in a record/playback style, making plain Markdown recordings that suits source-control.

Utilization of "Service Virtualization" is best practice towards fast and consistent test automation. This tech should be used in conjunction with JUnit/TestNG (or your language's test framework), etc. Versus alternate technologies, Servirtium utilizes Markdown for recorded HTTP conversations, which aids readability allows for diffing to quickly determine if contracts are broken. That last is an important aspect when Service Virtualization is part of a Technology Compatibility Kit (TCK). All will be revealed in this presentation

When the concept of a Scrum master was introduced to the world, it was way too far to digest. Having a coach to a team was a new time that hardly anyone could understand how to implement in a technical world. Even going back one step for being a trainer who train the team was a mission that not all the companies and the team could understand its benefits, so another one step backward was needed to be done to a facilitator. Along the time , more and more teams became more Agile mature hence the role of a Scrum master could have been gained into the right direction to again become the coach of the team.

If you are frustrated as a Scrum master how to motivate your team, have rare idea how to motivate your team , have no idea what are motivational buttons or are not fabulist with the term intrinsic motivation, the Scrum meetings are considered to be a big waste and you have no clue how to reach the vision (doing nothing while the team is fully self managed), this session was created for you.

In this one-day Workshop, Dave Snowden, the creator of the Cynefin framework and famous in the agile community as an inspiring and sometimes controversial speaker, will address agility from the point of view of complexity. Participants will be exposed to a realistic approach that puts context before dogma and shows a future for Agile that goes beyond fighting over methods and towards a sophisticated application of agility in organizations.

This class will offer an introduction to the Cynefin framework by its creator: the Cynefin framework is a transformational idea that uses a situation-specific approach to making sense of the world in order to act in it, and ensures effective work, decision making, and management even in complex and uncertain environments. For Agile practitioners, this framework supports effectively tailoring methods and practices to different situations. Cynefin-informed methods and practices help Agile organizations harness change and turn complex situations into a competitive advantage for customers and the business.

DateTime: This workshop is scheduled on Oct 12th and 13th from 2 PM to 6 PM IST (4 hours each day)

Many codebases contain code that is overly complicated, hard to understand, and hence expensive to change and evolve. Prioritizing the technical debt to pay down is a hard problem since there's always a trade-off between improving existing code versus adding new features. In this masterclass, you learn how easily accessible development data let us uncover the technical debt with the highest business impact. The techniques cover both technical and organizational decisions around your codebase, and we cover both traditional architectures as well as microservice architectures where you learn to measure non-code properties like team coupling, system mastery, and detect implicit dependencies between services.

• Identify the code that's most expensive to maintain amongst millions of lines of code.
• Put costs on technical debt and assess its delivery impact.
• Detect architectural decay and learn to control it.
• Perform architectural analyses of layers and microservices to uncover team coupling and implicit dependencies.
• Learn refactoring patterns to address technical- and architectural debt.
• Measure how organizational patterns influence code quality and the link to software architecture.
• Uncover the social side of your codebase and use data to mitigate off-boarding risks.

Participants are encouraged to take this opportunity and analyze their own codebases. As part of the workshop, you also get access to CodeScene – a tool that automates the analyses – which we use for the practical exercises. We also look at open-source alternatives, and see how we can use Git itself for data mining; the workshop is not about tools, but rather about the techniques and their applications. This is a new perspective on software development that will change how you view code.

DateTime: This workshop is scheduled on Oct 19th and 20th from 2 PM to 6 PM IST

A crisis is a great motivator and organisations have adapted remarkably well to remote work. Many leaders have been surprised at the smoothness of the transition but there are some emergent challenges. The line between safety in the workplace and safety in the home has become blurred, leaders who relied on command and control to get results are struggling with the paradigm shift, and while some teams (particularly agile teams) are demonstrating productivity gains, the increased risk of alignment gaps means senior staff are increasingly overburdened with virtual collaboration. Meanwhile, several tools have jumped the chasm into mainstream existence and capital is flowing towards a remote future.

In this talk, Andrew will talk about how remote:af, the world's first framework for effective remote working, is helping organisations to navigate the remote now, and the hybrid next. He will focus on patterns that organisations are currently using to support remote leadership teams, to design operating models that are optimised for remote and hybrid working, and to take strategy into execution.

Many systems are full of error checks and conditional logic. They introduce discontinuities that make reasoning difficult. In this workshop, Michael Feathers will present a conceptual framework for dealing with errors, conditionality and decision making at the level of code, architecture and user interface. Participants will walk through examples where error handling and decision-making policy are critiqued and redesigned at all levels of systems. Often by changing design and revisiting requirements we can make various error cases impossible, and make code and architecture simpler as well as more robust.

In 2016 I quit a very successful career in IT which spanned multiple countries including US, Canada, Europe, UK, Singapore & India. I stopped selling software & started selling lehengas! This lead to building Koskii, an ethnic occasion wear brand for women with the learning of an 18 year IT & business career with a global context, working with highly intellectual people and applying those learnings in a local Indian context with a team that was only semi-literate in a business that sold ethnic apparel for women. In this talk, I will be sharing our story and how eventually we managed to set the ball rolling to build a successful retail chain with a vision to scale the world.