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)

Ever feel like the market moves faster than your marketing team? Or, wonder how flexible your finance (& leadership!) teams would really be if self-direction glitched and blew $1M? Organizations introduce Agile believing it will lead in part to greater responsiveness and resiliency. Yet, why do so many fail to achieve those outcomes?

It isn’t just that they’re structured and operated by default along hierarchical lines rather than by design for iterative work. Achieving the full benefits of Agile comes from shifting the culture and mindset of a whole organization, sometimes as radically as encouraging it to “Make New Mistakes.” This very philosophy was a driver in the fastest division in HP’s history to reach $1B, a hardware division that was focused on manufacturing operations, with razor thin margins, and markets that changed 3x faster than the development lead time.

Through a series of short stories and exercises, attendees will explore 5 practices from that business which led to roaring success. We’ll probe their parallels in Lean / Agile practice. With each one, you’ll briefly self-inspect the state of your own organization, as well as create a backlog you can use to adapt in your “real world” beyond the conference.

Do you have, or want, a vision that takes you beyond high performing teams, to a high performing, resilient business? Come hear how you can help your organization shift from mechanics that “do” Agile, and walk away with a feel for what’s possible when not just development, but a whole organization surfs the flow of “being” Agile.

Agile Principle # 12 defines that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. From Scrum to Kanban and other agile frameworks, this is accomplished through retrospectives and continuos improvement processes. The key to being a successful agile practitioner is to identify areas of improvement and then experiment ways of improving it. But it doesn't stop there; positive improvements ultimately become success stories for other teams and motivates them to experiment with newer ideas which eventually leads to innovation. A negative outcome isn't bad either since it adds to the experience of situations where ideas may not apply. Thus the key to this process lies in being a child, an explorer, and inculcate an experimentation mindset. The SLICE framework addresses this in the following way:

• S hare: Share an area of improvement
• L earn: Explore the area for ways of improvement
• I mplement: Search & apply the learning to identify the success factors
• C ollateral: Publish blogs, white papers, presentations, etc. as observations of the implementation
• E xpansion: Grow, Seed, and Split in order to explore new venues for success

In this workshop, I create an environment that inculcates an experimentation mindset and utilize the SLICE framework to drive the exploration.

Session is for Lean Agile Leaders which will help them manage portfolio Agile way.

Lean Agile principles when applied to portfolio management, will help you keep pace with fast changing business by giving you a disciplined approach to implementing you strategic vision as realistic work plan.

Keeping up with the new pace of change requires light weight processes and an adaptive mindset.

It will cover the following main pillars of Agile Portfolio Management

- Work Management

- Capacity Management

- Financial Management

- Value Management

- Continuous planning

- Continuous Visibility

APM session will help you look at the portfolio in different way; and help you outpace changing business.

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".

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.

Most often people think that when anyone has an idea, they innovate. But why is that you have people around you who have lots of idea but never get them into "existence".

The reason is that it's not with an idea that Innovation starts.

Its easier to discuss challenges to get the ideas from concept to cash. But there finer human behavioral elements when we talk about innovation and this session tries to address fundamentals of how innovations starts.

This session is mainly about the myth that "Innovation starts with an idea" backed up by research of centuries and essence from Hindu Vedas

This session had got a round of applause and appreciation in APGI 2016 conference

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.

This topic is not meant to demean the profession of Product Ownership and doesn't mean that the Product Owner is not essential so killing them would solve the problem; rather it highlights the amount of dependencies a development team may end up building around the Product Owner that may end up killing the credibility and value chain driven by product ownership.

Keeping aside the fact that organisations today recruit Scrum Masters and Product Owners as designations instead of scrum roles, the role of product ownership has been misunderstood as a one person job, which kills the entire purpose of being a Product Owner - voice of the customer to maximise ROI. PO doesn't own the product alone and definitely doesn't own the implementation details. Enough said, this scrum role needs a deeper understanding. Then again, who performs this role in XP or Kanban or SAFe or a no framework setup?

In this session, I execute 3 iterations to highlight the team's dysfunctions, and apply practices a team can perform so a Product Owner can function much better and improve the credibility of this role. It's pretty quick and enlightenting; all hands-on, no PPT.

Agile transformations are no child's play. There is inertia, restlessness, impatience and the constant desire to run away. Traits that anyone who has been a parent to little kids has encountered, and learnt in their own way how to handle.

This session looks at parallels between parenting and trying to influence teams through an agile transformation. We look at some of the things that successful parents do that can be done by leaders trying to take their teams through a transformation.

Because if teams sometimes behave like children, the leader needs to be a parent too!

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.

Introduction

Culture eats strategy for breakfast, said Peter Drucker. We all agree to that. If our organisational culture is not building up to our goals, we will never reach them. The main question is, how can you create an organisational and team culture that contributes to your goals, to productivity and success? The key for change is to form the right habits, within our agile teams. Like exercising regularly and losing weight you can develop habits for being healthy, happy, more productive and successful at work. Therefore it is important to understand the human nature and its potential for transformation. In this workshop participants get all the insights and best practices to develop habits for an happy and fulfilling (work)life and organisational culture.

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.

Over the years, with all our experience and skills, one thing has remained constant - we just can't seem to hit out deadlines! Why is this the case?

I deep dive to help explain why this would continue to be the case, unless we learn to ask the right questions and then change the way to execute to deliver to the expected deeadline. I explain how Lean thinking gives us a solid mathematical basis to understand how Cycle Time forecasting works and what we need to do improve our probability of success - not based on subjective assessment but based on actual Cycle Time distribution data.

With every product we ship, we learn what we wished we’d known: what customers *really* wanted. What if you could gain those insights before beginning development? What if you could “unit test” a product idea? Or at a bigger level, what if you could “system test” your business idea/plan?

Engineering teams are experiencing productivity gains of 30-300% when applying Agile and Lean practices and methods. These same Agile and Lean principles can be applied beyond engineering, to the business itself. Using a lightweight yet powerful tool, assumptions behind a business plan can be tested and iterated almost on-the-fly. With a hands-on exercise, attendees will learn how to build a map of any business ecosystem, and how to use it to check and iterate solution viability. Come experience the application of Agile to Business so you and your team can focus on your richest opportunities over chasing your competitor’s taillights.

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.