How many times have we been cautioned to avoid single points of failure?

A team that simply takes orders from a product owner is not utilizing the full
potential, experience, and competence offered by a cross‐functional, multi-disciplined team. A product owner often is a single point of failure when formulating business requirements on behalf of an entire business function and prioritizing them based on business value.

Does the product owner understand the business strategy sufficiently to establish true business value? Does s/he share a common understanding of business value with the rest of the business? This strategy creates many unknowns and risks.

I propose a shift in focus from “solving a problem” to “defining a problem and then solving it”.

In my talk I will share insights and lesson learned on proven technique on how to mitigate this single point of failure.

To all technical members involved with building DevSecOps pipeline this talk is for you.

In today's competitive world, fixing problems in the pipeline is still a human task and how many times have we seen that when pipeline stops, notifications are sent out and then we wait........ for someone to identify, diagnose and resolve the issue. I am sure we have all been there and done that.

Is this good enough?

In my talk I will share some smart ways of infusing self healing into your existing pipeline. We all know it’s good to set thresholds and quality gates in the pipeline, so you can stop the pipeline when the threshold or the gate fails and notify appropriate stakeholders. But in this approach the problem is brought to the attention of the humans to take corrective action what if this issue gets self diagnosed and self healed by the pipeline itself!

Imagine that....

I will shows ways on how self-healing can be built into the pipeline by leveraging the data that gets generated from within the pipeline by converting it into information, and the information into knowledge, and the knowledge into insight to make intelligent data driven decisions and remediation.

If Agile can work in federal agencies, believe it when I say it can work in any organization on the planet. Agile adoption has spread into various federal agencies. Small and large federal agencies now understand the need for an Agile mindset and are adopting Agile to make decisions quickly and expediting the development, requirements, and project management process to become a daily norm.

Federal agencies came late to the Agile and DevOps party. Perhaps that was a good thing, since in retrospect they now have tons of lessons learned and best practices from private industries to do Agile the right way. Lately, some federal agencies have stepped up the game by transitioning from Agile adoption to scaling Agile.

In this session, I will share the journey of one such Agile team at a large federal agency, which had its share of successes and challenges while implementing DevOps, and how this team is driving change in the agency that is inundated with silos.

Federal agencies are unique in the way they’re siloed, which creates issues around ownership. There is also an issue for IT leaders of gaining the trust of the agency leadership and those on the business side. The goal of this session is to share our lessons learned, with hope that it sparks other teams to embark on their successful journey. Federal agencies should be able to replicate this success, and ensure that the organizational process can constantly produce high-performing teams, while not relying on any one individual.

Have you ever imagined how our ancestors built Stonehenge, the Great Wall of China and the Pyramids without the tools and technology that are available to us today? Now imagine today’s world without the internet, smart phones and technology. What do you see? I see that there have been generations before us and there will be generations after us which will develop ways to survive, excel, and perish. One thing that is constant is change. Most of the organizations today acknowledge that change is good and have discussed it in great detail; however, but fall short in realizing the change.

Change is an absolute truth. No one can agree with this more than organizations in today’s cut-throat competition, where constant change is the norm for their survival. Organizations which are slow to respond to change or resist change are on the verge of being obsolete. They need to change for various reasons such as external competition, market pressure, performance issues, changing workplace demographics, globalization etc. Organizations which invest in proactively responding to change are more likely to not only survive or but also emerge as leaders, creating new markets which never existed before. When organizations are successful, they become complacent and continue to do what worked, but in doing so you keep getting what you were getting; where is the growth in that? The main reason for organizations to resist change is in their mindset; change is perceived as negative or with skepticism. How many times have we heard the phrase “if it ain't broke, don't fix it.” Many organizations have fallen victim to this mindset and have become extinct.

Product owner provide requirements and its business value to IT which in turn works on building a solution. Usually the focus is geared towards building the correct solution based on customer’s requirements. But can we guarantee if the requirement and the business value provided by the customer is right? Does the product owner really know if their requirement adds value? We propose a shift in how the requirements should be processed. Instead of accepting requirements based on business value and customer’s need, we suggest a scientific method of evaluating a requirement to see if it really does add any value prior to adding it to the backlog. Most of us in our early school years might have studied in science the scientific method for asking and solving a scientific question.

We all know how paramount collaboration and communication is among members for success in the Agile world. People, Process and Tools are the three pillars of any organization. This session will focus on the people aspect of Agile. Teams are made of people who come together to work on a project from their diverse backgrounds - each of whom bring with them their respective personalities which has developed and evolved over time. According to the Myers-Briggs indicator, there are 16 personality types and each personality type has its own pros and cons. An organization’s success is largely dependent on its team’s personality which in turn is driven by the personality of each and every team member. In this session we will explore questions like – What has personalities to do with Agile? Why do we care? What is the impact of personalities on an organization’s success? Which type of personalities promotes team members to thrive? Which personalities create bully behavior in the team and toxicity in the organization? Can personalities evolve over time?