In the wake of the pandemic and the challenges we have seen around us, organisations have realised how inequities can trickle down to many aspects within the sphere on workplaces, teams and practices we follow. It’s time to revisit old practices in more ways than one. 

Aspects like lack of work-life balance, mental well being, asynchronous communication, extended virtual meetings, prolonged virtual pairing etc. impact us all. 

To address this ThoughtWorks introduced the 'Inclusive Teams - Social Contract' an exercise for teams to re-look at their old ways, to arrive at an aspirational set of behaviours and social norms for inclusive ways of working at both the team and individual level. 

It focuses on 4 key aspects -

1. Building a culture of trust and inclusion - Supporting each other, feedback, empathy and cultivation.
2. Schedules and Meetings - Best practices, setting personal boundaries and context.
3. Communication practices - Tools, patterns and inclusive practices.
4. Norms of engagement - Connecting as team, fun that is inclusive, welcoming & respectful.

The inclusive team social contract helps teams understand and empathise with each other, acknowledge differences and personal context thus increasing team connect, productivity and shared accountability. It’s recommended that teams run this irrespective of whether they are working virtual/F2F/distributed/remote etc. 

For the last 18 months the Agile Alliance Agile Coaching Ethics Initiative has been working on a code of ethical conduct for Agile Coaching.  V1.o of the Code was published in May this year.   This workshop will explore the contents of the code and then go deeper into the Ethics Scenarios the volunteer team are working on.  The scenarios present real world situations and  explore how they can be tackled using the Code as a tool to help guide the conversation.

Modern businesses have disrupted traditional industries by leveraging technology and have created new standards of excellence. They’ve paved the way for new business models to deliver better value to customers and to a larger scale of customers than ever before. Netflix killed the cable TV business. Amazon transformed our shopping experience. Fitbit brought personal health to the forefront. They've created products that are in the hands of millions of people across the world.

Disruption of this magnitude is possible only by intersecting a strong engineering culture with a product strategy that is driven by customer insights. Today, stand-alone products are passè - platforms form a crucial foundation for an ecosystem of consumers, merchants and service providers. They enable businesses to reach a larger customer base, and shake up the industry. 

We relate the story of a true digital disruptor - an organization that chose to focus on turning the insurance industry on its head and changing how people think about their personal health. This is a story of ups and downs, of experiments and learning, of technical excellence and user-centric focus. Follow along with us, from once-upon-a-time-an-idea-was-born all the way through to the-users-lived-healthily-ever-after, in this story of how technology overhauled a traditional industry forever.

The primary challenge which leaders are facing is to evolve their enterprises to deal with increasing complexity in the external environment. Leaders are constantly having to deal with circumstances which are volatile, ambiguous and uncertain, which are the result of increasing complexity.

In this talk, the speaker will focus on one key characteristic of complexity, viz. how interaction between 'agents' in a complex system produces value. The speaker will present a case study of how leaders in an enterprise leveraged this characteristic to create value, in their Agile Transformation journey..

What if we narrate 3 anecdotes about unconventional means to create happy engineers?

Story #1 - How a product owner made the engineers happy by articulating their customers' extra sleep due to the team's work?

Story #2 - How did a 'rewards committee'  come up with a reward for a winner of an in-house contest, with a budget of 0 INR?

Story #3 - How did a 'product team' take on the adventure of killing the mutant invaders using JavaScript while saving money for the organization?

Businesses are building digital platforms with modern architecture principles like domain driven design,  microservice based, and event-driven. These platforms are getting ever so modular, flexible and complex.

While they are built with architecture principles like - loose coupling, individually scaling, plug-and-play components; regulations and security considerations on data - complexity leads to many unknown and grey areas in the entire architecture. Details on how the different components of this complex architecture interact with each other are lost. Generating insights becomes multi-teams, multi-staged activity and hence multi-days activity. 

Multiple users and stakeholders of the platform want different and timely insights to take both corrective and preventive actions.Business teams want to know how business is doing in every corner of the country near real time at a zipcode granularity. Tech teams want to correlate flow changes with system health including that of downstream stability as it happens.Knowing these details also helps in providing the feedback to the platform itself, to make it more efficient and also to the underlying business process.

In this talk we intend to share how we made all the business and technical insights of a complicated platform available in realtime with limited incremental effort and constant validation of the ideas and slices with business teams. Since the client was a Banking client, we will also touch base handling of financial data in a secure way and still enabling insights for a large group of stakeholders.

We kept the self-service aspect at the center of our solution - to accommodate increasing components in the source platform, evolving requirements, even to support new platforms altogether. Configurability and Scalability were key here, it was important that all the data that was collected from the source platform was discoverable and presentable. This also led to evolving the solution in lines of domain data products, where the data is generated and consumed by those who understand it the best.

Whenever we talk about automation we generally limit ourselves to tests (Be them Unit, Integration, or End to End).

Yet, We spend a considerable amount of time on Test Data Creation (Unknowingly and Unwillingly) during many other Day to Day activities.

In this talk, I will demonstrate different tools along with one open-source tool "Corr" (that I made) to write test data as code. One can parameterize, randomize, correlate data creation steps in this code and each code snippet can be directly run from the IDE plugin that supports this data creation code language.

Leading-edge applications are dynamic and adaptive in capabilities that require people to use increasingly dexterous tools and supporting infrastructure, including microservices.

Microservices break traditionally structured applications into manageable pieces that can be developed and maintained independently. Microservices are often decoupled, allowing for updates with little to no downtime, as the other components can continue running. Container orchestration, Securing service-to-service communication, and decoupling authentication and authorization from microservices emerge as a new trend and also a challenge for many. 

Kubernetes being a container orchestrator of choice and Service Mesh comes in handy for secure service-to-service communication, service discovery, resilient service building, canary deployments, etc. It’s required to validate the manifests of k8s and configurations of service mesh much earlier in the development life cycle to provide faster feedback.

Keeping Development teams motivated and productive has always been a challenge even in a pre-pandemic office work environment. In the new Remote-first work reality, these challenges bring new tradeoffs between Developer joy and releasing new features quickly and maintaining a high bar on quality. Add to this the hurdles in communication and this presents a potential obstacle for most businesses and their bottom line. But using gamification exercises, quality gating, guardrails and modified KPIs combined with a reward/objective-based system for distributed development teams can bring in a new way to drive developer effectiveness in teams. Combining learnings from running remote distributed teams for over a decade (as well as through the pandemic) this talk will focus on the wins/learnings/opportunities that can be a blueprint for enabling happy dev teams that deliver consistent quality at high velocity

Are you a frustrated developer who feels like they know enough? However, the success you thought you would have is out of reach. You see others who make better strides but why? Is it a skills gap? Come learn how to set yourself apart as a developer and learn the skills of influence and collaboration.

During the current lockdown, I happened to watch the 2019 movie "The Lion King" . This movie was an eye opener to me and what I learnt in those 120 minutes truly amazed me. The movie has all the learnings & Trappings of What  Servant Leadership is all about.

In the proposed talk, I try to bring this learning to all of you. This talk delves into the reason why Servant Leadership is the need of the hour in this crisis time. I draw inferences & inspiration from the movie "The Lion King" to drive home the relevance of Servant Leadership in our work life.

If you have witnessed enough Agile transformations, you have probably experienced a plateau in the journey; or worse, you have experienced “the great dip”.

Agile Transformations frequently start with a lot of fanfare, see a fast-paced adoption laced with early successes, and then settle into a plateau where we experience little to no improvement OR begin a slow, painful slide into a trough where behaviors start regressing to old ways.

What keeps us stuck on the plateau of change? What might drag us into this great dip?

There are the usual suspects – management has found the next shiny object, coaches and transformation agents only know how to help us get this far, all the easy stuff is done, the frozen middle (management) never really unthawed and so on.

People with a lot of experience in helping with transformations will know to watch out for these and would have developed ways to navigate these obstacles – we know what they look like and we have developed a reliable range of responses to them.

What really blindsides us are the watermelons! Stuff that looks green on the outside but is a dangerous shade of red on the inside. Surprising traits that are superficially positive but can real drag a transformation effort down.

Through this talk I will draw upon my experience of over a decade in Transformation roles to share what these Watermelons are, telltale signs that these are lurking in your system  and ideas to tackle them.

Have you heard of “flaky tests”?

There are a lot of articles, blog posts, podcasts, conference talks about what are “Flaky tests” and how to avoid them.

Some of the ideas proposed are:

• Automatically rerun failed tests a couple of times, and hope they pass
• Automatically retry certain operations in the test (ex: retry click / checking for visibility of elements, etc.) and hope the test can proceed

Unfortunately, I do not agree with the above ideas, and I would term these as anti-patterns for fixing flaky / intermittent tests.

We need to understand the reasons for flaky / intermittent tests. Some of these reasons could be because of issues like: 

• timing issues (i.e. page loading taking time)
• network issues
• browser-timing issues (different for different browsers / devices)
• data related (dynamic, changing, validity, etc.)
• poor locator strategy (ex: weird & hard-wired xpaths / locators)
• environment issue
• actual issue in the product-under-test

In this session, with the help of demos, we will look at the following techniques you can use to reduce / eliminate the flakiness of your test execution:

• Reduce number of UI tests
• Use Visual Assertions instead of Functional Assertions
• Remove external dependencies via Intelligent Virtualization

Demo will be done using the following and sample code will be shared with the participants

• Specmatic
• teswiz
• Applitools Eyes

Mindset and Culture change is at the core of agile and DevOps adoption. While we all know it’s importance, there is no single approach or process to make this change happen.

We have embarked on a mindset transformation Journey at our workplace.

In my session I will cover pragmatic approach of bringing in mindset and culture change. An approach which we are adopting in our workplace and seeing the change resulting in multifold benefits. You will learn Echo system of Mindset, Culture and Behaviors and leave the session with multiple ideas and an insights on how to make cultural and mindset shift in your organization.

Self Organising Teams Vs Self feeding in toddlers ?

Isnt it just easy to give a command and top down align the teams ?

Isnt it easy to just switch on the tv or just force feed a toddler with the menu prepared by you ?

Drawing a parallel on messy toddler - THE POWER OF SELF ORGANIZING!

There are stakeholders associated with every task we accomplish. Stakeholder management/delight is also a key competency of Agile Delivery. Yet a lot of times, (Almost all of us!) have come across a situation where our stakeholders expected something else. At that moment, we feel -What if I knew what they expected!! At many occasions, even sincere efforts don't yield benefits as the key gap of understanding our stakeholder is not bridged.  

Keeping stakeholders happy is an art. But this can be strategised with some simple tips which I call as the "secret sauce".

In my presentation, I aim to present these simple ground rules which could apply to almost any situation. With these tips you can focus on accelerating growth as you'll have happy stakeholders by your side.

Agile transformations happen in a particular context, with two very critical parameters. One is the orientation of the coach who is guiding the transformation. The second is the leaders - who are key stakeholders and decision-makers in the organization transforming. Programs often observe differing results based on these parameters. This model which is a conceptual one attempts to capture the same and looks at the influence of those parameters and possible outcomes. Based on the coach and leader dispositions, the outcomes could range from conflict, checklist agile, or other antipatterns. This model is a thinking tool that can be leveraged by participants to provide insights into and ponder on the state of their agile transformations and how they can move towards better transformation outcomes.

The session will orient the participants towards this model with real-world examples from large-scale implementations.

Design thinking is fundamentally important to product innovation. It is perhaps to product-market fit what the compass and the sextant were to ocean navigation in the age of sail.  Yet as software keeps on eating the world and enterprises face a risk of obsolescence and disintermediation, is design thinking enough to keep disruption at bay? Is it enough for enterprises to focus obsessively on their users? Or is such focus - so vital to every startup - too limited and too limiting, when it comes to driving solutions to Enterprise scale disruption?

We believe that preempting or countering disruption requires supplementing design thinking with Ecosystem thinking. We believe Ecosystem thinking is a distinctive approach, that is far better aligned to the skill profile of large enterprises. Yet it is poorly understood and poorly practiced (if at all).

The purpose of this talk is to create awareness of Ecosystem thinking as a distinctive approach that should the primary sensible default at an Enterprise scale. Given the relative unfamiliarity of many of its key tenets, the goal is to not to overburden the audience with excessive theory about Ecosystem thinking but to have an engaging session that showcases ecosystem thinking in action, centred around the history of the innovation of the typewriter and the establishment of QWERTY as the default standard for typewriters. While the example is somewhat anachronistic, it is intentionally so. The goal is to demonstrate that the core concepts of Ecosystem thinking have lasting applicability and that Ecosystem thinking is a natural successor to concepts like strategic power and game theory that are well established in business strategy but poorly integrated into product innovation frameworks like design thinking.

What is Ecosystem thinking? How different is it from product or platform thinking? Why should Enterprises redesign their innovation playbooks based on Ecosystem thinking? These are some of the questions that the talk will look to trigger.

The usual suspects in change management models plot a familiar curve when describing the impact of change on individuals, teams or enterprises as a whole. When a change is implemented, at first there is a “dip”; in knowledge, in competence, in confidence, in emotional state, in cooperation, in performance. Organisations and their people go through a decline before moving on to realise the desired benefits of the changes they are implementing. But what if we could accelerate the learning and smooth out this "productivity dip"?

The traditional change management discipline seeks to address this issue but the approach is hampered by being inherently linear in nature, having grown up supporting traditional linear program management practices. The more complex an organisation’s change portfolio is, the more the traditional linear approach to change management isn’t going to cut it. As contemporary organisations focus more on enterprise level business agility, opportunities arise for the change management discipline to move away from the fixed time, cost and scope criteria of linear change management, towards an agile organisational change management strategy underpinned by continuous engagement, regular feedback loops and the ability to pivot in response to feedback and changes to market conditions.

The terminology of ‘productivity dip’ or even ‘performance dip’ comes with connotations of activity-based measures and have a way of anchoring the change process into a linear predefined ‘push’ of information. Mia will explore that by re-framing ‘productivity’ as ‘value delivery’, the outcome and impact on people is brought back into focus in the change portfolio. Ultimately, an agile change management approach will help you to build a change program that truly welcomes changing requirements.

Mia will show how Agile change management returns the customer to centre stage. In the context of agile product management rolling out smaller changes more often, agile change management activities can start to genuinely deliver their change management outcomes as intended to decrease the depth and duration of the dip. The change curves modelled for individuals, teams and organisations remain relevant, but each step will be small, anticipated, and normalised. This session will explore how to use Agile Change Management approaches to ensure that business readiness is part of each iteration rather than something that is done later downstream. This means that the productivity dip of the traditional change curve becomes downsized into insignificance in a sustainable ongoing improvement journey founded on the small incremental iterations of evidence-based inspection and adaptation.

How do you introduce yourself at a conference or any event? Your name, your designation, your years of experience probably. How many of the new people whom you have met for the 1st time at conferences do you remember, a handful? Probably none? 

The regular formal introductions don't excite the human brain. In events I have met people who spoke about having horses as pets or people who brew their own beer and I remember them very clearly and attach a memory/rather recall a memory as soon as I bump into them somewhere, versus the people who gave some professional designation, year based introduction etc. 

Human brain works in exciting ways, if I have to explain it with Pixar’s ‘Inside Out’ analogy then it's the personal touch which helps create more memories compared to the dry professional summaries. And this personal touch is the core of the ‘Personal Introduction’ Manifesto. 

While 1. The organization you work at, 2. Educational Background, 3. Designation, 4. Work experience history is important while introducing yourself to someone. We should give more importance to our 1. Geographical origin, 2. Social Structure 3. Interest and hobbies 4. Personal Qualities. Just like the agile manifesto, i.e, while there is value in the items on the right, we value the items on the left more. 

Where can it be used

I have been using the ‘Personal Introduction Manifesto’ since 4 years and it has proved to be of great value 

1. When a new team starts working together, helps build rapport and a personal connect between them
2. When a new member joins an existing team, new aspects of existing members come forward(they cant repeat what they said when the team was built)
3. Works very well for remote teams too
4. Ice breaker in big workshops, inceptions
5. As a team building/bonding activity
6. Visual facilitation, when people draw it themselves
7. Foster collaboration

How does it help

It helps in 

1. Creating a personal connect among new people
2. Learning more about the people you already know
3. Team bonding outside the professional connect
4. Identify people with similar interests and bond
5. Creating your personal introduction map which can be reused 
6. A document with all team member map can also be used in the on boarding deck