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)

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

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!

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

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.

My session explores different aspects which today's Executives needs to embrace in order to survive Digital Transformations.

Lean and Agile Principles helps them to look at their Blind Spots!

Learn Fast: Stop Starting, Start Finishing, Slow down to go faster

Pivot Early- Accept Hard Truths, Fail Early Fail Often

Embrace Lean- Do Less, Less Waste, Simple Design, Agile Architecture, Set Based Designs, MBSE etc.

System Thinking- Think Big start small

Lead the Change- Lead by Example, Shift from managing for results to designing environments that create results

Today's enterprises operate in highly complex and uncertain digital environment and Agile adoption is highly challenging in such large organizations.

Digital transformation typically involves implementing digital technology to any aspect of the business, introducing disruptive technologies or moving from paper to digital. Enterprises are focusing on leveraging digital channels which include search engines, social media platform, email platform, mobile platform and their websites to find and connect with the current and prospective customers. Digital transformation accompanied by Agile transformation provides an opportunity to improve processes with customer centric approach and not just technological upgrade. Digital technologies can facilitate process change however they are not central to the change. Agile can assist the organisation in working out how the new system might shape better processes and vice versa.

While the context for each Digital-Agile transformation is different and there are several scaling models available, the components of the Agile implementation road map which ensure outcome are of universal nature.

In this session we will cover our model for building the roadmap and the activities to be carried out by Agile leaders and Agile Coaches for successful Agile implementation at scale for Digital transformations. The model covers why to? How to? What to? When to? and Duration? for each component on the roadmap. The model will lay foundation for crafting the Agile implementation strategy and also to write the Agile implementation business case for any Digital transformation. The model is based on our practical experience of large scale Agile implementations.