Looking to move to Continuous Delivery? Worried about the quality of your the code? Helping your developers understand clean-code practices and getting the right testing strategy in place can take a while. What should you do to control the quality of the incoming code till then? This talk shares our experience of using PRRiskAdvisor to gradually educate and influence developers to write better code and also help the code reviewer to be more effective at their reviews.

Every time a developer raises a pull-request, PRRiskAdvisor analyzes the files that were changed and publishes a report on the pull request itself with the overall risk associated with this pull request and also risk associated with each file. It also runs static code analysis using SonarQube and publishes the configured violations as comments on the pull request. This way the reviewer just has to look at the pull request to get a decent idea of what it means to review this pull request. If there are too many violations, then PRRiskAdvisor can also automatically reject the pull request.

By doing this, we saw our developers starting paying more attention to clean code practices and hence the overall quality of the incoming code improved, while we worked on putting the right engineering practices and testing strategy in place.

Being a start-up we are discovering new business models and experimenting new client behaviour. Our platform is a B2B insurance digital platform which redefines customer experiences of an Insurance retailer / broker. Having 7 paying customers, now all of us are spending time with client on boarding and removing blockers related to legal, contracts and procurements process. We thought we are smart in having a separate team to focus on new discovery / new ideas so that our creative juices keep flowing in the midst of all the chaos of client on- boarding etc.. but this turned us into dysfunctional discovery - delivery teams, we started becoming silo organisations one focusing on discovery and other focusing on delivery.

This case study is about how we experimented a dual track model to regain our agility in experimentation and discovery.

As an industry, we’re not very good at managing tech debt. Yesterday's big balls of mud will likely become tomorrow’s big buckets of glue. Wouldn’t it be great if we could:

• Balance and evolve quality while delivering features?
• Pinpoint hotspots in code? At multiple levels of detail?
• Heighten situational awareness of system health and hygiene?
• Conduct data-driven, constructive critiques within our team?
• Automate (useful) measurement, putting quality gates in place to self-govern as a team?

In this talk, I’ll share my lightweight approach and toolchain for realizing these aspirations. Expect lots of tips and tricks for combating entropy in long-lived, software-intensive products shared by teams and large organizations. Some of these tools can be a little daunting for beginners, so I’ll take a demo-driven approach sharing the cheat codes I use to get to value as quickly as possible.

Ultimately, I'll show you how to start building a system for visualizing, prioritizing, and managing your software product's evolution and technical debt side by side with new feature development.

Automotive industry is in the cusp of it's biggest transformation, Digital transformation in this industry is twice the speed of average adoption rates across technology areas. As the cars of future would be tagged as Autonomous, Connected, Shared and Electric, the change in parts of the car (BoMs), ecosystem(Charging , shared data, safety) software engineering platforms (Car Operating System), external connectivity(5G) and Sytem on Chip needs will bring the digital the key pillar . This would be the epitome of Agility at the center and will establish new standards for a personalized, digital driven connected world under a reliable and secure delivery platform for automotive. The outset of the session is sharing ways to bring the external disruptive collaboration perspective within the organization walls.This session is about sharing my experience of my journey of re-positioning IT for Digital and disruptive automotive industry, re-structuring the organization keeping agility in mind, successful implementation reference like cloud transformation for engineering, nurturing teams to embrace the change.

What defines a high performing team? Why do some succeed while others fail? This workshop will introduce you to both the VTS method and the findings of Google's "Project Aristotle". A multi-year rigorous research study, Project Aristotle found the critical success factor to be Psychological Safety - a team climate characterized by interpersonal trust, risk-taking, and mutual respect. To succeed, each and every team member must feel confident speaking up and making mistakes. This session is an extension of my talk "Art For Agilists: VTS & High Performing Teams". During this session, you'll learn how VTS increases both critical thinking skills and psychological safety - leading to happier, more productive, and more innovative teams. We take a deeper dive into the method and also cover the basics of facilitating sessions in your own environment. In addition to in-person sessions, you'll learn how to conduct online sessions for remote teams.

Visual Thinking Strategies, or VTS, is a cross-disciplinary technique applicable to anyone working in a collaborative setting. VTS develops observation, reasoning, and collaboration skills by viewing and discussing works of art in a group. It is backed by over 30 years of field research showing its effectiveness and accessibility. By allowing individuals to talk about art - without needing a background in the field - VTS advances skills you can use to create more relevant products and stronger teams: Observing, Brainstorming, Cultivating a Point of View, and Revision & Elaboration. As you participate you'll also learn how VTS can help to create an environment of psychological safety. Because there are no right answers , VTS creates a safe space, one that encourages participation from all viewers. Empathy, Communication and Collaboration skills are enhanced along with Comfort with Ambiguity, Openness to the Unfamiliar, Civil Debate, and Willingness to Participate in Group Thinking.

During our fun interactive exercise, we’ll discuss selected works of art as a group. We’ll create an environment and process for looking, thinking, reasoning and revision - skills that are mission-critical to anyone working in a software design or development role. You'll discover new ways to engage teammates and highlight the value of diverse points of view.

After our group discussion, participants will learn the basics of image selection and facilitating VTS sessions within their own organizations. You'll discover how creating psychological safety within your teams leads to innovation and a more inclusive environment.

In 2016 I had the good fortune to join a massive DevOps initiative as a head coach. The goal was to, in a 7000+ person technology organization, get product development teams fluent in topics such as CI/CD, automated testing, and product management. Over the course of six months our team tuned an initiative a successful, impactful program.

In this talk, I’ll share the experiences and learnings from my 6-month journey. We’ll start with the concept of a DevOps Dojo and explore it from four perspectives: product, place, process, and, most importantly, people.

Product: Elaborating on the classic “coder’s dojo” - where the focus is on building technical skills - to a “DevOps Dojo” where we perfect technical skills while delivering on product learning goals.

Place: We’ll go on a virtual tour through of a massive engineering space designed to promote collaboration, learning, and rapid product feedback.

Process: How we managed to scale the program to 12 concurrent dojo teams of 4-16 people with a custom pull system (kanban) featuring unusual-but-realistic WIP limits.

People: What skills (some quite surprising) does it take to make a program like this succeed? I’ll share the framing tool we developed for rapid team alignment during onboarding.

What defines a high performing team? Why do some succeed while others fail? This talk will introduce you to both the VTS method and the findings of Google's "Project Aristotle". A multi-year rigorous research study, Project Aristotle found the critical success factor to be Psychological Safety - a team climate characterized by interpersonal trust, risk-taking, and mutual respect. To succeed, each and every team member must feel confident speaking up and making mistakes. During this session, you'll learn how to use VTS to increase both critical thinking skills and psychological safety - leading to happier, more productive, and more innovative teams.

Visual Thinking Strategies, or VTS, is a cross-disciplinary technique applicable to anyone working in a collaborative setting. VTS develops observation, reasoning, and collaboration skills by viewing and discussing works of art in a group. It is backed by over 30 years of field research showing its effectiveness and accessibility. By allowing individuals to talk about art - without needing a background in the field - VTS advances skills you can use to create more relevant products and stronger teams: Observing, Brainstorming, Cultivating a Point of View, and Revision & Elaboration. As you participate you'll also learn how VTS can help to create an environment of psychological safety. Because there are no right answers , VTS creates a safe space, one that encourages participation from all viewers. Empathy, Communication and Collaboration skills are enhanced along with Comfort with Ambiguity, Openness to the Unfamiliar, Civil Debate, and Willingness to Participate in Group Thinking.

During this fun interactive exercise, we’ll discuss selected works of art as a group. We’ll create an environment and process for looking, thinking, reasoning and revision - skills that are mission-critical to anyone working in a software design or development role. You'll discover new ways to engage teammates and highlight the value of diverse points of view.