Building team working agreements with an emphasis on remote teams.
In any enterprise, small or large, software drives the business to not meet the customer demands but also to delight them. The firms should embrace agile to stay ahead in the market. But agile transformation is an evolution and a journey through which these enterprises have to gradually wade through! We will discuss the different stages of this transformation journey through that every enterprise irrespective of its size should experience to achieve true business agility.
What does success look like for an agile organization? How do we measure it?
More than ever, organizations must be focused on their investments and efforts. We cannot expect that tomorrow will be like today. With all of our assumptions called into question, the ability for organizations to be agile is what will help them pivot and sustain. To achieve true business agility, organizations must not only grow and support self-reliant, cross-functional, self-organizing teams, they must also change the way their organizations oversee their agile initiatives. They must believe in feedback and allow that feedback to work. However, defining success with old measures like “on time” and “within budget” or simple output metrics like “velocity” are not useful when markets and customers are constantly changing, potentially resulting in delivering great solutions to problems that no longer exist.
In this session, Patricia Kong will introduce a framework called Evidence-Based Management (EBM). EBM helps organizations focus on seeking goals, improving outcomes, and reducing risks by defining measures of success that are meaningful to them in 4 dimensions: Unrealized Value, Current Value, Time to Market, and Ability to Innovate. She will also share some challenges and results from organizations using EBM.
This session will help you understand how Cynefin was used for the management of SARS in 2003, and how some of the good practices were easily adapted for COVID, and how some failed and allude to constraint management.
Feature Toggle is one of the key practices for Continuous Delivery, but not enough has spoken about the same. Feature branching is popular, but everyone knows about the “merge hell”, a common issue because of long-lived branches or infrequent integration. How do you continuously merge, test and release software with great confidence without spending too much time on merging and fixing conflict issues? That is where Mainline development, one of the key practices of Continuous Delivery, comes into the picture and Feature Toggle works in conjunction with the same. Feature Toggle [also referred to as Feature Flip, Feature Switch, Feature flag] is a simple technique which allows you to turn on or off a feature through configuration. Feature toggles give you the flexibility to toggle features in specific environments i.e. turn on a feature in testing or staging servers and turn it off the same in production. This also helps to rollback features, as rolling back is as simple as turning off the feature and deploying.
During the current horrific pandemic I started researching how people
have survived other traumatic experiences. It’s amazing how resilient we
are as a species and what interesting approaches we have created to help
us survive. I’d like to share one evidence-based technique that just
might help you grow and improve as we all learn more about ourselves.
It’s called expressive writing. It fits well with a lot of cognitive
neuroscience that I’ve been talking about over the past several years.
Many times, it’s just not worth it!
I have been championing MicroServices for well over a decade. But I don’t always go to a MicroService solution for my clients’ problems. In this talk, I will characterize the traits that should drive you to avoid MicroServices, and instead look toward more traditional or even SOA alternatives. Included in the talk is my recent experiences in two Norwegian government projects, both very successful, with minimal MicroService influences.
“If you aren’t doing MicroServices, you are building an obsolete system!”
“MicroServices are the way to go if I want to keep my job.”
“If it is good enough for Netflix, it should be good enough for us.”
I hear all of these things as I attend conferences. And I feel apprehension for these companies, suspecting that the vast majority will fail. And failure will come from several sources:
* Little or no experience with MicroServices.
* Processes from traditional systems being forced on MicroService projects.
* MicroServices is not the appropriate architecture for the problem!
In this talk, I will focus on the latter issue. The other two issues will resolve themselves with time and experience. The latter issue will always be fatal!
First, we will discuss the problem domains particularly appropriate for MicroServices. Then we will address the radical differences in processes, team organization, and business management of MicroService and non-MicroService approaches.
Finally, we will touch on two recent projects for the Norwegian government, their overall architecture, and their minimal use of MicroServices. We will note, however, that they do exploit event buses, continuous deployments, and modern languages. So despite not being MicroService-based, they are being successfully deployed.