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.

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

We can enrich our demos and reviews with Especification by example, BDD and ATDD using examples to show our products in DEMOS and Reviews while we impact business more with alignment and deliverying what they know from the beginning because they were part of the discovery

In the workshop we explain about BDD and example mapping as a technique to align the 3 amigos ( business, DEV, QA) about what the requirements/user stories are through rules ( acceptance critterias) and Examples, we also show the next steps of BDD with formulation with Gherkin 

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.

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.

Any transformation journey usually has a roadmap that focuses on process, tools, technology and people. Studies have shown that some key reasons why transformations fail are due to cultural aspects. However, culture is often ignored and we expect magic to happen quickly. Hence, a transformation needs to weave in culture shift as a critical part of the roadmap.

We delve into…

• What constitutes culture?
• Why should a transformation look into culture shift?
• A ‘culture gauge’ as a tool to calibrate the cultural aspects
• The E3R model as a recipe to plan the culture shift journey
• The elements of ‘thin slice’ and ‘1% improvement’ as key ingredients

… we weave in our stories of failure, some good practices and envision how we would use the culture gauge and E3R model.

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

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"