"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change "- Charles Darwin

In life and work, we all experience change - big, small, good, bad, dramatic, sometimes it comes in a huge wave, and other times it trickles gently. Despite the presence of change all around us, individuals and organizations, by nature, are resistant to change. They would rather stay in their comfort zone and status quo than change

Change is inevitable not only in life but in business too. The modern workplace is defined by constant change . Organizations are continually being forced to transform and evolve as a result of competition and technology. We may not always agree with changes, but when companies change, so must we.

In this fast-paced world, being adaptive and willing to embrace change guarantees that we see change as an opportunity to learn, explore, and thrive even in the face of adversity.

Research has shown that the ability to embrace change is key for growth in individuals and has a massive impact on the happiness and success of people.

In this talk, through the medium of engaging storytelling, you will learn why do people resist change, explore a tool that aids in enabling change at an individual, team, and organizational level, and learn its practical application through a Case Study.

HIGHLIGHT: You will discover and explore a new model, the "AAAAHA Model" (the original model of the speaker). It is a six-step model for embracing change, which will enable you to accept change naturally and use change as an 'opportunity' and 'strength' to transform your life.

This talk will describe how we can enable the businesses to manage software engineering efforts at scale in a financially sound way, all the while dealing with multiple projects/products or value streams, multiple events or deadlines, multiple stakeholders and multiple teams.

It will show how to resolve the conundrum of dependency management at scale by collapsing the combinatorial explosion of dependency networks into a simple linear queue.

It will describe how to instrument the organization in order to raise leading signals of oncoming trouble in order to trigger intense, frequent and engaging collaboration between all players (business and engineering), leading to an environment that unleashes the organization's collective intelligence via co-creation and social learning.

The talk will highlight techniques employed to foster intense collaboration between engineering and business, at scale.

It has been employed, among others, in a case in the automotive industry involving an organization with 8.000 people, half of which in 120 engineering teams distributed globally across the world, dealing with on average 400 projects in process at any time, and 70,000 change requests per month. The focused approached allowed the organization to improve it's operational throughput by 40% in a matter of months after inception.

The approach is data driven, and takes into account: Flow metrics, Buffer Burn Rate, Virtual Queue Sizes, Operational Throughput, Financial Throughput, Financial Throughput Rate.

The techniques used are a re-elaboration of the Theory of Constraints, taking elements of Drum-Buffer-Rope scheduling and Critical-Chain Project Management, and combining them with queuing theory and Little's Law.

The metrics and signals produced are also used to trigger collective psychological flow states leading to sustainable and optimal human experience at work.

What if the testing scope changed from usual UI or API testing? Instead, the testing scope gets diverted to the testing of docker artifacts like base images (let's say python, node) used in the Dev or QA community. What can be the overall possible quality gates for this ecosystem?

And the most important question is, why the testing scope needs to be changed? Isn't it testing UI or API alone sufficient? 'Not Always'. The exact answer lies in the kind of architecture/ecosystem projects have. But certainly, there are threats that can be avoided at the earlier stage by asserting quality gates, examples:

1. Vulnerability Issues
2. Performance Issues 
3. Infrastructure Configuration Related Issues and many more.

"Universal law is for lackeys. Context is for kings." The best practices are the ones that make sense for you. Embracing DevOps culture is not a binary decision. This thinking often leads to inaction. Should we use distributed tracing? Should there be 100% unit test coverage? Should we use Infrastructure-As-Code? We should when the right time comes.

In this session, we will explore what DevOps practices make sense for companies at different stages operating in different industries, DevOps maturity models, and the role of platform engineering. We will also see how a maturity model was deployed at Blinkit to help teams areas of focus for DevOps maturity.

The aim of this talk is to introduce a technique of imparting knowledge about Agile Tenets to the non-initiated and/or team members who need reinforcement in their understanding of tenets of agility in teams, collaboration, XP practices and dependency resolutions in an agile par lance. The modus of operandi is to take a popular movie, which in this case is Lord of the Rings, and derive analogies from the movie that defines some core concepts of an agile journey with team, dependency resolution and a couple of agile engineering techniques including XP practices that are result driven in this era of distributed agile teams. The intent is to make it a fun session with an audio-visual link for deeper entrenchment and retention of the understanding it intends to impart. This sort of immersive learning with audio visual aims at connecting the learnings to existing neural pathways to create an understanding of the tenets of Agility in a language that everybody understands - "Movies and Fun".

devops for agile coaching collaborative  model

zurück zum Wesentlichen - back to basics

In this paper we are sharing our experiences from the trenches about how we as a agilits ( agile coaches, scrum masters, ATFs. and so forth) can support, accelerate and collaborate with DevOps culture and practices adoption through a collaborative-work inverted Y model 

Digital disruption is all about how fast you can deliver customer and business value in a most efficiently to beat the competition. Most of the transformation efforts are spent on IT as a function and local optimizations but time to value goes far beyond only IT functions. Digital transformations need to focus on several aspects across business and IT. In this session, participants will learn holistic approach of transformation which enables the organizations to truly build products and services in a most disruptive, efficient and innovative ways.

70% of all transformations fail .

Rather than failing visibly, transformations usually decline.CEOs and leaders put in huge efforts, and involve external partners - business targets improve, sometimes radically, those engaged feel they have achieved transformation and then gradually the organization reverts to old ways of working. 

How many times have we heard from top management that "We have gone through three transformations in the last ten years, and each time we are back where we started 12 months prior”

The session help you get answer to these questions - 

• Why do you  struggle to achieve lasting impact in your transformation ? 
• What are Leading indicators of sustainable transformation (or not)?
• How can you make your transformation stick?

As an Agile coach, have you ever struggled with managing expectations of your role in the organization? Has magic in any shape or form been implicitly included in your responsibilities or deliverables? Was it expected of you to be “agile” and re-adjust the definition of your coaching activities with each and every shift of operational context? And what’s more, have you ever felt like carrying the weight of the whole Agile transformation on your shoulders?
Although there may be many heavy-lifting moments and unpredictable turns on the journey of organizational growth and development, there is a way to help you stay firmly grounded in your coaching intent. You can navigate a wide range of situations with more clarity and grace, while nurturing everyone’s commitment to bring change. You can grow trustful relationships and cultivate ownership of development by individual contributors, teams and leaders.
Join this talk to learn how to establish healthy boundaries, structure coaching priorities and enable self-organization from day one. Whether you’re an external or internal Agile coach, you will get many practical tips on how to effectively (re-)frame your Agile coaching engagements as creative partnerships through the lens of professional coaching agreements.

A predictable system is a myth. System failures are inevitable. The only way out is to be prepared for failures by building resilient systems and we explore chaos engineering as a way to do exactly that. Chaos testing, a part of Site Reliability Engineering (SRE), is the art of simulating unexpected system failures to test system response and recovery plan.

Session covers the "How" by showcasing live demo of chaos testing as network disruption and out of storage on workloads deployed on a Kubernetes cluster using Litmus chaos toolkit. Also talk about practical tips on approaching how to get chaos testing as part of your path to production and delivery with confidence. Going to share tips, tricks and gotchas while getting chaos engineering practice in your organisation. 

Data, the way that we process it and store it, is one of many important aspects of software-based solutions. Data is the lifeblood of our organizations, supporting real-time business processes and decision making. It is crucial to the success of software development, and to our organization as a whole, that we apply agile and lean strategies to data-oriented activities. Yet for many organizations their data sources prove to be less than trustworthy and their data-oriented development efforts little more than productivity sinkholes. We can, and must, do better.

This presentation begins with a collection of agile principles for data professionals and of data principles for agile developers - the first step in collaborating more effectively is to understand and appreciate the priorities and strengths of the people that we work with. Our focus is on a collection of practices - the "agile database techniques stack" - that enable you to easily and safely evolve databases. These techniques are vertical slicing, clean architecture and design, agile data modelling, database refactoring, database regression testing, continuous database integration, and configuration management. We call them a technique stack because they build upon each other.

We were part of an engagement with a client who wanted to transform themselves from legacy ways of working and tools to being Agile in terms of tech and business. We had a limited in resources, be it time, people and scope. It was a humongous task and we couldn't get overwhelmed with what we had in hand. 

We had to stick to the basics and focus on the principles of XP rather than bogged down by getting into the immense number of rituals and practices and see where it takes us. And apparently we gained the trust of the clients in 3 months and we where able to get subsequent work.

In modern agile ways of working, team performance is measured by the outcomes of delighting your customer with working software. Data-driven, data-led, data-inspired decisions are increasingly shaping a cultural revolution of fact fuelled delivery. It’s the facts that provide the freedom for hard conversations, decisions and action, right?

Well, sort of. The facts are only half of the picture. We also need context, narrative and the subjective for deeper understanding and truly being able to unleash your team’s mojo. In short metrics need empathy.

Metrics and empathy can sometimes be like oil and water. but they can and do make magic when brought together in the right ways.

In this presentation, participants will get an overview of:

• the key agile success metrics for team insights into HOW (i.e. behaviours and practices) you design, build, review and engage together

• tips and techniques that add team context, narrative and voice (i.e. deeper empathy and understanding) to agile success metrics for a complete picture of team performance

In this session, Varuna will share a specific case study of how an effective test strategy can get away from Push and Pray deployment to Continuous and Confident deployment to production. 

This is a case study of the product, where the very first thing I observed was unclear roles and responsibilities within the QA of an organization. There was a low test coverage as there was no clear testing strategy to follow. Getting deployed to production was Push and Pray method which led to high risk for production. It was also causing inefficient use of QA timing. There was the pain felt throughout the organization in a smaller group and folks kind of accepted this pain. We started by noting down the pain points of producer and consumer teams within organizations and even a third-party team to come up with an effective test strategy for the product. 

Participate in this talk to learn:

1. How do we form a core team to define the external and internal strategy? 
2. How did we apply recursive feedback and updated the strategy when and required after a production release?
3. Internal Test Strategy: A strategy within a Team of the same vertical as checkout API and UI
4. External Test Strategy: An end-to-end test strategy for a product
5. How did it help in getting away from Push and Pray deployment to Continuous and Confident deployment to production? 

We got the motivated QAs across the organizations and better quality products with a Test Strategy across organizations. It had also helped in mapping a QA learning curve with a test strategy within an organization

A lot of businesses and Customers loose trust on teasm, simply because they don't keep their promises regarding delivering value to them.

Teams tell the business, we will deliver this next week. The business tell the customer the same. Then the team fails to deliver this for whatever reason. Bussiness and customers starts to have bad tasts.

if this is repeated more than one time, then they will never rely on this team to give them trustworthy estimations or to deliver on time.

In my talk, I would like to highlight the solution to this problem "Making agile teams reliable and trustworthy"