Using examples from his award-winning design consultancy, Alan Cooper shares the secret to his success: working backwards. Working backwards means taking the time to ask the hard questions before wading into unfamiliar territory. It can be scary (and for some, frustrating), but it's the only way to innovate.

Story is a profoundly important device to unite design teams around a shared product vision. This powerful communication tool helps us retain information and empathize with others. As companies scale and teams sprint through product iterations, it’s easy to lose sight of how your product should fit into the lives of your customers. The best way to keep everyone pointed in the right direction is with a clear, compelling story—a story that will unite and guide teams towards success.

But how do we fold storytelling into our design practice? Aarron Walter uses real-world stories of product teams at Disney, Apple, Airbnb, Twitter, and more to show how storytelling improves team communications and elevates design practice.

While microservice architectures allowed teams to scale delivery of independently deployable services, most frontend layers are still run as monolithic applications. Similar to server-side applications, frontend layers often grow into large monoliths that are difficult to maintain and evolve. Building, deploying and consuming frontend components across a diversity of teams and web applications can be a daunting task, especially at scale. To address this issue, at OpenTable we enable fast-moving teams to easily build and deploy front-end components using OpenComponents, an open-source, battle tested, front-end microservice architecture for painless component delivery.

The idea behind micro frontends is to enable multiple teams to work seamlessy together by fostering end-to-end ownership of independently developed, tested and deployed features.

Think about UI as the composition of features which are maintained by independent teams. These teams could be cross-functional allowing them to develop such features end-to-end, from a database to user interface and independently deploy them.

During this session I'll explain how OpenComponents works, how do we use it at OpenTable and how we allows teams to build ship and consume frontend components at runtime across teams and web applications at scale.

The digitalization calls for rapid organizational flexibility and adaptability. This has an impact on all dimensions of a company: its strategy, structure, and the processes. Agile will help implementing some of this flexibility and adaptability yet mainly in terms of processes. Thus, the digital transformation needs companies to change beyond Agile. Beyond Budgeting, Open Space, and Sociocracy provide the missing links for a company to fully embrace digitalization. The combination of these concepts enables a company not only to survive but also to thrive (digital) disruptions.

You have tried Scrum, Kanban, XP, Crystal and other even less known frameworks and methods that claim to help you to become Agile. You have applied them pure, you have tried to tweak them, and even you have made some homemade cocktails out of them. So yet you still can't say your company is Agile. Your Cxx-s are willing to change the company, and themselves. Your employees on all levels genuinely want to step into the Agile journey. Yet there is nearly no progress toward a real organizational agility.

What is the secret? Why is it so hard? Why there are so many crashes on this way in our industry? Why most of the companies will still fail to become Agile, and yours will most probably too.

I'm going to answer all these questions during this talk. We will figure out what aspects of a large-scale agile transformation have a mission-critical impact and how they influence each other. Where to put your efforts? How to cut corners? And moreover, how to survive on this journey.

Infrastructure as a service (IaaS) is an instant computing infrastructure, provisioned and managed over the Internet. Quickly scale up and down with demand and pay only for what you use.

In this demo, we will explain and demonstrate

1. Infrascture as a Code - Key DevOps practice
2. Azure - Key Concepts
3. Script Infrastructure as code
4. Provision Infrastructure
5. Compare and Contrast Azure with other Cloud Providers like AWS / GCP

As part of organizational digital transformation journeys, CIOs are moving from hierarchical models to 'self organizing' Feature teams, in order deliver efficient and effective IT, but still need to retain the deeper functional expertise. Hence the growing importance of building and sustaining "Communities of Practices" (CoPs), as the traditional functional silos are broken down, with the transformation themes.

But if you are a Change Agent responsible for the Transformation, you understand how challenging it is to nurture, and especially "sustain" these CoPs.

So join my session, as I will share my experiences in nurturing and especially "sustaining" enterprise wide Communities of Practice (CoPs), while you recognize the key success and failure patterns in your own journey. In this session, you will learn techniques, tips and strategies that you can apply immediately, and in the end will walk away with practical advice on building "long lived" communities.

First came agile, then came DevOps and Continuous Delivery, now comes Continuous Testing. Managing the balance between speed and quality is a difficult decision for many organizations. In this new reality of rapid releases, incremental changes, and short QA cycles, testing is becoming a bottleneck. The adoption of DevOps has brought this more into the forefront as testers find their place in this emerging area. Continuous Testing is a major opportunity for QA leaders to redefine the strategic role in the organization, specifically as drivers of quality within Continuous Delivery.

We will have an overview of the upcoming challenges that you will face as QA leaders and how Continuous Testing will bring you through these changes on top. We will discuss real time experiences as a tester bringing quality into the DevOps process, with key strategies used to ensure quality is infused in every step of your process. Also we would discuss about the different cases where CI, CT & CD are in practice.

Session name - Outcome based agile coaching

We all want to become good agile coach. But what does that mean? How do you get better outcome from your agile coaching sessions? In this session, participants will experience how to improve outcome of your coaching session. Some areas we will focus in this session are output Vs outcome, why, what, how of coaching, how to make coaching outcome etc.

This will be a hands on workshop with very minimal guidance from facilitator. Participants will have experiential learning through the activities to understand how to align agile coaching to deliver maximum impact on business outcome.

In October 2016 I received a call, "Hey dude, I don’t know nothing about Agile, but I need to become an Agile coach a-s-a-p – my company just got a new contract." I laughed for a second, explained that it takes a bit longer than a week to learn to coach, and wished him luck. I also knew that, shortly, he would be walking into his customer's office in this new role.

Agile Coach is the new black! But how can you, a good coach, stand out from the crowd of less competent peers? Let me offer you this workshop to explore the science of coaching and the ways in which it works. We start with concepts of neuroplasticity and the brain processes of creating new neuron pathways. Then we move to motivation and learn which type is the best. Finally, we finish with the discussion on brain activation states which we practice in a few short exercises. By understanding the new field of coaching psychology, you will become a better practitioner.

I am an affiliate member of the Institute of Coaching at McLean Hospital, the Harvard Medical School affiliate. I studied coaching psychology at Harvard Extension School.

Lies, damned lies and Statistics!

(the phrase is frequently attributed to the British Prime Minister Benjamin Disraeli).

Many of us work in environments that value Agility or are at least attempting to be more Agile.

We frequently turn to data, metrics, reports to help us navigate through our complex software environments, to help make sense of what's happening, to support subjective information we see around us and gain insights about the way we work.

But with the myriad of reports and metrics available to us, it is easy to misinterpret, over-analyze, overlook and generally make a big mess of things.

Through this talk, I will present some of the popular Agile reports and metrics and how they can be misread.

I will also share tips of how to counter some of these "lies".

Product Owners and others responsible for creating and maintaining the Product Backlog often focus on functional items.

With good engagement in the Backlog Management process from the Development Team and Architects, technical and architectural items also find their way into the Product Backlog.

But what about the human-centric items related to accessibility, inclusivity, internationalization and sustainability?

Through the talk and with the help of several supporting examples and a short exercise, I would like to highlight the importance of addressing these aspects in the Product Backlog. The examples will include examples of good and bad backlog items and design decisions.

I will also share some tips on how Product Owners and supporting roles can work these aspects into the Backlog Management process. These will include some ideas from Design Thinking but will not be limited to that.

In Distributed Agile many times, people don't trust members on other shore. My topic will cover few of the aspects which has helped our teams to gain that trust of customer and give co-located results.

In Session I will speak about case study covering below points which helped our customer who is a “first time offshore” to “Trust the Stranger”!

1) Building the Trust

2) Creating Continuous Visibility

3)Rotation of resources between shores

4)XP practices

1)Code Ownership

2)Use of technology to share code/ builds

5) CI CD – tools enhance visibility

6) Test Automation to look at Tested Running Features

7) Speak about my code! - Technical presentations within teams

8) Explore Business Flows!- Business Understanding among Business Owners, Product Owners, Proxy PO, team.

9) Innovations in business areas

10) Distributed Agile – tools techniques

11) Measuring the business Value (using custom Framework)

12) Saying No!

13) Re-Enforcing agile Practices!

The benefits of a high performing team are endless. They are autonomous, empowered, responsible and effective.

At Atlassian, we've pioneered the Team Playbook, which is our way of scaling teams by getting smarter, not bigger, and driving a culture of continual improvement. Utilised by hundreds of teams within Atlassian, we've made our secret sauce not so secret. Don't come to this session for a lesson on theory...come to this session to hear the philosophies and principles of the Team Playbook from Peter Scobie, Program Manager/Team Doctor. You'll leave this session invigorated, engaged and ready to take action.

A lot of organizations don't have version control systems in place for the database. Even if they are, change scripts are being generated manually for deployment process causing significant risks to the releases. In this demo, we will demonstrate patterns that can be used for taking care of database deployments and minimizing the risks

The Key challenge organisations are facing today is having to deal with the exponential rate of change which is happening in the external environment. The extent and pace of change is so disruptive that no organisation, regardless of age or size can take their competitive advantage or even their survival for granted.

The main reason why organisations are struggling to change is that they are modeled as mechanistic or close-ended systems. On the contrary, all natural socio-economic systems essentially which are living systems have dealt with change very effectively since eternity.

This talk is about infusing life into organisations. The speaker will highlight the key characteristics of living systems which enable them to deal with change effectively and also suggest actionable guidelines that will help leaders/influencers to bring their organisations to life. This approach will enable organisations to not only survive but thrive on change.

T-shirt sizing. Fruit Sizing. Planning pokers. You might be familiar with any or all of these estimation (relative sizing) techniques. Story points based estimations (along with velocity mapping) is touted as a predictable method to plan for software delivery. Teams are expected to get a good sense of the effort needed to deliver a piece of work by comparing estimates with references of similarly complex work they have delivered in the past.

The accuracy of point based estimates fares more or less in the same range as sheer gut feel. So, the natural inclination for software teams is to try and make it more accurate than gut feel. Thereby, we obsess with breaking functionality into smaller byte sized stories. We freak out when there is "scope creep". We debate endlessly about ideal days vs. person days. We fuss over the specific visual representation for the burn-up or burn-down.

Does it matter anymore how many days the team spent chipping hard at a feature that added no value to the business? Have we made agile teams into mini waterfall teams by focussing on the wrong metrics? Can product companies afford this?

Process heaviness in product companies can cost a lot. We need to find better ways to invest in success metrics. We need to change the conversation from productivity to value add.

My talk intends to challenge prevalent estimation practices and contest their validity in product companies. I will also introduce ideas around capturing relevant business metrics and sizing stories using business value.

I will focus on a possible transition of organizations who are introducing the agile way of working. Starting with a traditional project setup using permanent PMO (portfolio level) and a temporary PMO (project level). What will happen if the keep the team together as an agile team. What does that mean for the project manager. I will continue my story by adding an agile team. Coordination between the teams can be managed by a scrum of scrum. Still no need for a project organization with a project manager and a project board and no need for a temporary PMO. I add more teams and the coordination asks for a project manager. What dos this mean for a PMO? We can continue and institutionalize the coordination by using frameworks like Nexus, [email protected], SAFe et cetera and has an Integration Manager, a Roadmap Manager or a Release Train Engineer and Product managers and Product Owners. I will add some new to be created teams (aks for a Project Manager to organise) et cetera. I will end with an overview and positioning of different agile frameworks and the role of the permanent PMO (focus portfolio management and Center of Excellence) in an agile world.

In Software Development, Agile is a way of developing code. It is essentially an unspoken promise of new functions, fixed bugs, automated tests etc delivered in a short period of time. Agile has became the reference approach for modern product development in the last few decades. However, we still see a lot of misinterpretation and abuse of its core values. This is so common and I would like to call this unwanted byproduct as fragile. If you don’t handle it with care, it is sure to shatter your product and loudly crash your entire team.Companies worldwide have faced many issues adopting Agile, a lot of the struggles and challenges are shared across different regions.

As organizations embark on agile transformation, many traditional project managers or business and technical leads are thrown into the Scrum Master/Product Owner role after reading a book or two and, perhaps a few days of training. In the midst of changing environments, conflicting mindsets, and other change-related issues, they are expected to start operating within a Scrum team. The main problem I see these days with agile methodologies is that it has become a branding term, many organizations want to "do agile" not because they appreciate or even understand the benefits of doing so, but just because they want to get a sticker that says I'm Agile. You bring a team together, give them some work, and yet they don't meet the organization's or manager's expectations. At the end they fail to jell, fail to perform and fail to deliver.

Why do so many organizations struggle to put in place mature Agile teams that can apply proper Agile principles and deliver awesome products? Some people will say, “Agile is hard” as an excuse to not do Agile or to become frAgile. Here we shall discuss the secrets to reboot any Agile team. Let's discuss why this happens and how we can overcome these to bring in a new cultural shift which will boost the team productivity ?

This talk consist of a series of stories that hopefully can illustrate a different approach of implementing change in the right way. We shall also analyse if what you think of agile is exactly what it is or else what tweak you need to bring in to make it work for you.

Most organizations and teams talk about DevOps practices. Most of them might find it difficult on how to get it started. If you are a Microsoft shop, this would be a good session for you and your team. In this session, we will demonstrate different DevOps practices using Visual Studio Team Services & Docker