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)

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

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

Agile adoption crafts innovation in the DNA of the organization. At every iteration boundary, review leads to evaluation of the business and technical stories, customer feedback and inspect & adapt cycle.

Unintentionally or intentionally business agility leads to technical agility with the outcome of software being delivered to the customer which has inherently gone through several innovation cycles.

Technical Agility for innovation requires through implementation of Agile Architecture.

In this session I will talk about Agile Architecture, Agile designs and guidelines,Role and Agile mindset for Architects which will help to catalyze the innovation.

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.

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

Business agility is all about getting results out in an agile pace. Self organized teams would seem like an answer here.

An honest look into why self organization is a buzz word now. Why is it so important, why are companies shifting gears now. Is something terribly wrong with the normal top-down organizations?

Takeaways:

1. An answer to an important question - Do you need this shift?
2. The bare necessities to get you started towards self organization
3. How you should kill the boss in you
4. From coding to finalizing a new office space