If I had a rupee for every time, I heard a CEO, product owner, scrum master or a manager complaining about their teams not caring enough about projects, other team members and users ...

If I had a rupee for every time, I heard a leader asking for advice on how to stop "blaming games" and "political bureaucracy" in his/her organisation...

We learn a lot about an organisation, its culture, and real values not during the times of enormous profits, successful product deliveries or CEO monthly motivational speeches but during the times of greatest struggles. We learn and find out who the real leaders are in moments when everything goes wrong, and everyone is making excuses and finger-pointing at other members or external factors. No one is to blame, and no one knows whose fault was the latest issue? The horror stories of firing employees on the spot, tearing down teams, bullying and threats are familiar to all of us.

I genuinely believe that it does not have to be this way. I believe that there is a more effective way of leading the organisation, teams, and individuals. We have the most extraordinary opportunity to improve, make an impact and improve when things go wrong.

We just have to change our approach to blame and ownership. Together we will learn how to reconsider your leadership skills and how to use them to accomplish team mission effectively. I want the audience to experience what extreme ownership means for them and what it means to be entirely responsible for all possible outputs. Participate in a challenge to create a team with a #noBlame approach to their mistakes. At the same time develop teams where psychological safety establishes an environment where uncomfortable conversations and creative conflict solutions can thrive.

I want to share impactful lessons learned from building teams and company that tries to behave differently in moments of failure. How we started to appreciate opportunities created by accidentally removing production database, what we learned by forgetting to communicate with each other or follow agreed processes, and what happened when we declined to do a very profitable project. How we are seeing signs of people owning their projects entirely, taking responsibility and changing others around them. How we train leaders on all level of organisation and how we share more and more responsibilities with them. Experience our approach to blame concept and #noBlame culture we champion and value.

Modifying the schema of a production database is hard. If something goes wrong, the impact on both customers and the team can be enormous. And it can be hard or even impossible to rollback a database schema change if things go wrong. And the same is true for any architectural change for a production application.

The Branch by Abstraction and Strangler Pattern makes significant application changes easier. Are there any similar patterns we can use to make production database changes less risky?

Indeed, there are. The Expand/Collapse pattern is a blueprint for making the database migration. It makes the remodelling both reversible and safe. By expanding the application to accommodate both the old and the new schemas in parallel, we can give ourselves time to:

• Migrate any downstream dependencies on the old database schema
• Gain confidence that the migration is safe

We contract the application to the new version, once we’ve satisfied that the old schema is no longer needed.

The pattern helps to make significant, but necessary refactorings to your data model in a continuous delivery way. Most importantly, without threatening the robustness of your production applications.

While working with our product, I’ve successfully applied this pattern to make major changes to the core of the application, all while serving customers in production. I’ve learned some important lessons about how to best implement the Expand/Contract pattern.

In this session, I’ll share my experiences on how to avoid pitfalls and succeed at these kinds of major data remodelling with hardly any downtime.

A perfect introduction to the Theory of Constraints in 3 acts. Three compelling stories that represent crucial aspects of ToC including bottlenecks, introducing change in organisations and resolving conflicts to create win-win solutions.

Let us start with ToC premise that at least one constraint limits the achievement of the goal by any system. For the system to improve, the bottleneck has to be identified and exploited.

Experience the pressure felt by ToC experts dealing with "largest marine oil spill in the history" and how creatively and orderly they approached that challenge. I want to share their story and my experiences finding bottlenecks, exploiting them and achieving a higher throughput of value in projects.

ToC has a fascinating way of looking at introducing change into teams and organisations. Participate in considering some uncomfortable "facts" that we all know and believe about our failures. With the help of Eliyahu Goldratt, we will reconsider why some of our attempts at changing the situation around us failed or deliver limited benefits in comparison to initial promises. We will learn what to do next time we face the same dilemma.

Finally, I want to recognise conflicts and ToC way of approaching disagreement resolutions. With the help of the audience, we will build pragmatic Evaporating Cloud to show how to create win-win solutions, forget about compromise and increase understanding between parties. The audience will experience and learn how to stay calm, tips and tricks on how to tackle conflict and how to grow empathy and their conflict solving abilities.

Summary:
Three stories are bringing essential concepts of the Theory of Constraints to life. We will consider the WHY behind the ideas, HOW to practically implement them and WHAT they can do for you, your team and organisation. Fundamentally we will try to answer three crucial questions:

• What to change?
• What to change to?
• How to change it?
  by helping you, find bottlenecks, control the introduction of change and its outcomes and create an environment where conflict is a potential source of interesting conversations.

Most of agile conferences talks focus on "soft side" of being agile. We discuss process guidelines, Scrum Masters responsibilities, team building exercises and servant leadership ideas. In our quest to be agile we sometimes forget about developers and technical members of our teams, their tools, processes and way of thinking. Aspects like code reviews, TDD, CI, pair programming are hard for us to understand and justify spending time on them. We should not forget that at the end of the day great products we create needs great code to run.

All organisations whether startups or large established are products and services using Agile guidelines. But most agile transformations focus on SM and PMs forgetting about developers and their challenges. It's a tough life being a full stack developer these days. They have to keep innovating & adapting latest trends in technology. PO & PM always want changes or ideas to incorporate ASAP, Moreover every line of code is exposed being pushed code to live multiple times a day.

Constant Environment change, New languages and their regular updates, Huge legacy apps, Constant request from business to do more in new cutting edge has increased complexity in writing code. Code that is difficult to understand, hard to modify and challenging to extend is hazardous to developers, users and organizations. So what measures can be used to prove the code quality and the approach for improving the quality of the code base.

“Code review” can be a handy tool catering the developers in real time to groom their skills while keep them focused on the agile process.

Code review actually empowers agility by improving product and code quality and eliminates defects early when they are least expensive to fix. Code review process let developers think of new ideas how to write better code every time. Moreover, when working on project no-one is the only person who knows a specific part of the code base. Code review facilitate knowledge sharing of the code base across the team. Agile teams can realize huge benefits because work is decentralized across the team.

Since 2001 Agile has been reshaping the software development and business world. The word chosen at the gathering in Snowbird, Utah in 2001 is now probably the most used and misrepresented word in our industry. Everybody is talking about "doing agile," "following agile," "being the most agile" and changing the world using "agile methodologies." We all make huge claims in the name of “agile” as if it could magically increase our customer satisfaction, improve the quality of our code, processes, products, make our people smarter, highly engaged and passionate about their work, and speed up our delivery. At this stage there are no reasons not to "do Agile," the claims and promises are large enough to jump in, without really considering what Agile stands for.

We often presume that Agile is the solution to every problem we have, Agile doesn't fix our problems it shines a light on them and exposes all previously unseen issues.

This movement of following Agile blindly, without thinking, context consideration, and direction lead to claims that Agile is dead, famously mentioned by Dave Thomas in one of his talks. Everybody "do Agile" by hiring certified Scrum Masters, bringing Agile coaches, doing standups, retrospectives and expecting great results and a badge of honor in return. My view is that those organizations are just scratching the surface in "doing Agile," not really "being Agile" and for me, there is a considerable difference between “being” and “doing”. I see Agile organizations still following 12 months predefined plans, having QA departments as a separate function and having all decisions driven by Project Managers and their giant charts. There is very little room for incremental improvements, self-reflection, team, and people orientation and culture first approach. Everybody still feels afraid to be themselves, speak out or suggest a new idea.

In my view its time to claim "Agile" back and reconsider what it means and how it can help us achieve our personal, team and organization goals. The talk will focus on strategies, conversations, and examples of what "being Agile" really means. Together we will consider “agile” current situation, why "doing Agile" does not deliver the expected results and what you can do about it when you go back to your office on Monday morning.