Since its founding, Google has created six products that each have at least a billion monthly users. Google continues to innovate rapidly, and in many new areas. The organizing principles and cultural elements that drive this monster of innovation are a hot topic among designers. So what are they? Find out in this engaging talk by Google’s Chief Evangelist, Brand Marketing.

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.

In this age of a variety of cloud-based-services for virtual Mobile Test Labs, building a real-(mobile)-device lab for Test Automation is NOT a common thing – it is difficult, high maintenance, expensive! Yet, I had to do it!

Attend this talk to understand the Why, What and How I built my own MAD-LAB (Mobile Automation Devices LAB). The discussion will include –

• Understanding the context,
• Why no cloud-based solution worked for me,
• The automation strategy for Android / iOS / Web platform,
• The tech-stack (cucumber-jvm / Appium), and,
• The core implementation to build your own MAD-LAB! (already open-sourced)
• How this results in Continuous Delivery (CD)

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.

Every organization aspire for faster time to market, release of features on demand, reducing the time between concept to cash and better quality of products. Agile has been a popular choice to achieve this objective. While agile was becoming a streamline approach, software industry saw the advent of DevOps. By adopting DevOps practices, organizations were trying to bridge the gap that existed between different groups within the organization, such as business, delivery, QA, Operations, Infra, etc. In spite of adopting agile practices, organizations were not fast enough to respond to changes. And one of the major reasons was the misalignment of purpose and processes withing these groups, hence while features were dev ready but it would still take the same amount of time to release to market as it was before. That's where organizations found the missing piece in DevOps in the entire delivery process.

Everyone started hoping on it without realizing the complexity involved in its adoption. It is now a big buzzword in the industry. DevOps involves bringing changes not just in the delivery but also in the operations. with greenfield projects its a bit easier than doing it with legacy systems because greenfield projects have the opportunity to start from scratch which legacy systems lack.

The purpose of this proposed talk is to share experience of devops implementation on such legacy systems which are complex and not just on its own but a web of multiple systems working together. How scaling devops practices becomes a necessity when working with enterprise applications.

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.

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.

Purpose of the session is to discuss about Agile implementation approach and acceptance

I would like to take an analogy of comparing the Scrum Framework with a human body. The human body consists of cells, tissues, organs and the human body system relies on collaboration and coordination of all the parts of the human being in self-organization way to keep the body healthy and functioning. Similarly in scrum framework, the roles, events, artifacts and rules together work like a human body to keep the scrum sustain and work for not only to it but to everyone.

Human body cells employ iterative and incremental approach. They divide and multiply. That allows the body to grow and to replace damaged or worn cells. Similarly, in iterative and incremental manner, Scrum helps to build more valuable products over a period of time.

Empiricism is like the sensory experience which helps in the formation of ideas and making decisions. Also the introspection at regular intervals and taking corrective actions to improve as an individual is similar to the empiricism. Three pillars for the individual’s existence are Body, Mind, and Spirit. Balancing is the key to create an extraordinary life.

Similarly, Transparency, Inspection and Adaptation are the three pillars to sustain the Scrum framework. Also the principles of shared visual work space, self-organization and empirical process which make a scrum team successful.

Similarly i will be providing a view on all the scrum essentials analogy

Purpose of the session is to share experience of implementing Agile in Maintenance teams and have discussion to learn about challenges faced by others and guide them or learn from them

Retrospectives are hard. It’s hard to run a valuable retrospective and it’s hard for all team members to feel that the value has been delivered for themselves, the team and organisation. While facilitating retrospectives many of us has faced a problem of team lacking interest and engagement. Why is that some people embrace retrospectives as a way of getting better and some just feel alienated by it? Even with extremely capable scrum masters and facilitators we often end up with very few actionable team items and we feel not satisfied with team results.

In my experience in retrospective facilitation one of the main reasons is that, we focus on solving the problems that are being discussed between team members and we only give attention to loudest, outspoken team members who can explain their issues very well. We forget about the whole layer of unseen communication. We forget about “what is not being said.” In my opinion that’s the big problem and challenge worth considering.

This session will focus on discovery into non-verbal communication, active listening and enabling team members to share more openly and without hesitation. We will consider techniques for increasing team ability to listen and respect others opinions. We will discuss team and individual biases including some practical experiments that everyone can use with teams during next retrospectives.

I will share with you a few techniques to dig deeper, to try to discover real reasons behind people's opinions and views. We will play the 5 why’s game and see how scrum masters can increase their own empathy.

Together we will consider other aspects of communications including.

• Body language
• Individual and team psychological safety
• “No problem” problems

I will share with you different activities, games and experiments you can run to learn more about yourself and explain those issues to your teams. My talk is designed for people who work with teams on continuous improvements and it does apply to much wider applications than just retrospectives, standups and agile practices.

At the end of the session you will learn practical knowledge how to run a better retrospective, have your team members learn more about themselves and how that knowledge can impact the team deliveries.

We will consider ways to grow individual team members, as well as whole teams. We will also focus on helping scrum masters understand their current failures and learn from them and us. Trust me, we all have been there! At ucreate we failed more times that we can count but no matter what, we never stopped and we are still learning new and better ways to hear “what has not been said”

As you probably realised there are no silver bullets to sort out all your communication issues. But there are practical ways to help team members share more and there are ways to learn more from them even when they don't speak. It will enable you you to focus on unheard voice of retro, to be an active listener, to hear what people want to share or simply “to hear what is not being said”.