Every organisation has problems to overcome. At first glance they seem daunting: software bugs, financial issues, staff troubles, operational woes.

However: what if all these problems weren’t disconnected, but actually stemmed from the same underlying cause? What if - by tackling that underlying cause - we could make all those obstacles disappear in one go? And, what if it was surprisingly simple to find that underlying cause?

This talk draws on the Theory of Constraints and aims to provide you with the tools you need to understand and uproot the cause of complex, cross-functional problems that cause widespread pain and all too often go unaddressed.

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

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 

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"