To think again about something we’ve become acquainted with, often we need to approach the subject from another view point.
What new thoughts might we find if we approach work systems not as a line, a sequence, but instead as an artificially constrained system with inherent self-organizing properties.
How can we grapple with flow in open systems that reconfigure themselves in response to ecosystemic change?
Rather than engage in endless debates about whether technologies are making us better or worse, Nolen Gertz investigates what we think "better" and "worse" mean, and what role this thinking has played in the creation of our technological world. Using Nietzsche's philosophy of nihilism, Gertz explores the ways in which our values mediate how we design and use technologies. Examining our technological practices—practices ranging from Netflix and Chill to Fitbit and Move to Twitter and Rage—reveals how nihilism and technologies have become intertwined, creating a world of techno-hypnosis, data-driven activity, pleasure economics, herd networking, and orgies of clicking.
Cette session sera l'occasion d'aborder une autre façon de développer, en montrant un exemple de Pair Programming et de Test-Driven Development en live et peut-être vous convaincre de ses avantages.
Nous aurons pour mission de compléter une simple application de jeu web, réalisée notamment avec Angular. Nous aurons ainsi l'occasion d'évoquer quelques éléments intéressants de la stack.
Organisations are incentivised to adopt maturity models (sometimes also disguised as frameworks) when seeking to improve on their capabilities. A major reason for their popularity is that they provide a context-free assessment of people’s abilities, which empowers people in authority to make judgments about other people’s capabilities without a need to acquire such capabilities themselves or taking their context into account. Maturity Models also tempt the executive because they describe a target culture as an idealised future state.
Maturity models can be successfully adopted if the practitioners have insight into how the model can be contextualised for the current environment, how it fits into the current culture and that ability of contextualising is more critical to the adoption than depth of expertise in the model.
This talk introduces Maturity Mapping, a practice of applying Social Practice Theory (SPT) using Wardley Mapping in order to guide organisational transitions by enabling contextualisation for the adoption of capabilities. It is not only an antidote to maturity models, but shifts the focus of improvement away from who we are (investigation of individuals’ inner lives) to what we do (investigation of socio-technical interactions of collectives). Maturity Mapping allows us to visualise what we need to do and learn to execute a strategy, as well as informing what strategy options exist in our current context.
While Maturity Mapping is philosophically motivated and theory lead, the talk will explain the practice by showing examples of where it has enabled better outcomes.
Le cycle de vie d'une application est un chemin nébuleux et plein de dangers. La complexité ne fait que croitre durant les mois et les années d'utilisation. L'un des plus gros challenges d'un développeur est de pouvoir la contrôler tout en ajoutant de nouvelles fonctionnalités (features).
Des solutions existent : le ré-écriture de code ou encore la maitrise de la dette technique. En effet, ces deux actions permettent de lever "la complexité accidentelle". Mais que faisons nous de la "complexité essentielle" ? La complexité qui n'est pas liée au code.
La seule solution : Supprimer des fonctionnalités ! Ce talk vous expliquera comment perdre la surcharge featurale de vos applications en comprenant la différence entre la complexité essentielle et la complexité accidentelle, mais aussi en vous donnant des clés pour mener à bien ce changement dans vos équipes projet.
We finally have an answer to the question: "how big should a microservice be?". And the answer is: This question has been closed as off-topic. Size is really not the first thing you should be thinking about when designing boundaries. It's probably the last. Size gives us almost no indicators about the quality of our service boundaries unless we are at extreme ends of the scale.
This would be a great time to insert my silver bullet solution, but actually the Bounded Context Canvas is quite simple and boring. We made a checklist of the most important things you should think about when designing a service, and we turned it into a canvas. We then made it creative commons and put it on github. Over the past year we've been developing the canvas in the open as a community and it's currently version 4.
While the canvas is "boring", using it is fun. It reminds you to ask the important questions, and it tells you in a friendly voice "hey, the design of this bounded context has a few flaws you might want to consider".
The Bounded Context Canvas is no lone ranger. It won't magically help you find those perfect service boundaries. But when combined with a couple of other techniques like EventStorming and message flow modelling, it will set you off in the right direction and give you and your team a visual and collaborative way to design your service boundaries and interactions.
How many software products have you worked on that have been ruined by cynicism? Not just scepticism but downright cynicism. As a software tester, a large part of my role is to be a skeptic but sometimes this crosses over to cynicism. Identifying risks in code, architecture and products is helpful, dismissing ideas is not, especially as this behaviour can rapidly spread. What if the team becomes cynical? How can we break out of the cycle and actually start building software?
It’s very common for a team to pick up a piece of software and look at what has been written and decide, it’s simply trash. People believe that it can be built better. That the tools that the seemingly legacy software was built in have been superseded and the product is no longer fit for purpose. Cynicism for what is deemed as legacy but optimism for the brave new world.
Gwen will look at cynicism, scepticism, optimism and more as attitudes to building products, legacy and green field. She will identify some attitudes that help build, strong, long lasting products. If cynicism isn’t cool anymore, then what is?
Who designs the architecture of your software systems? Conway's Law suggests that HR may be strongly shaping software architecture by deciding how teams are composed and interrelate. Do you want HR designing your software architecture?
Organization architecture and software system architecture need to be co-designed to avoid friction from Conway's Law.
Many organisations rely on strategic systems that are becoming harder and harder to maintain. The business is unhappy because features are taking longer to be built and they cannot react fast enough to market demands. Developers are unhappy because the code is messy and negatively affects their productivity. Testers are unhappy because of the volume of work they have and they still cannot guarantee the quality of the software. Clients are becoming disenchanted because of the lack of quality and slow frequency of updates. Strategic software cannot become a burden to the organisation—they need to remain strategic and continuously enable business agility. In this talk, Sandro will cover the key aspects of software modernisation initiatives and why they are needed.
Shift from a culture of permission to one of intent. Our old idea of good leadership is where the leader knows all, tells all and is always in control. In fact, it’s difficult for us to change because those old habits are so hardwired in our brains! Intent-Based Leadership™ offers a way for us to rewire: to give control, trust and learn to be okay with not having all the answers. It's a way of leading where the leader sets the environment for others to excel and act to the maximum extent of their creativity and intellect; where team members come to the leader describing what they see, what they think, and what they intend to do. The result: the culture of the organization shifts from one of permission and waiting, to intent and action, and people feel more valued and come to better solutions. Jenni will share the principles of Intent-Based Leadership™ – what it takes to give control and achieve excellence in your organization.
Organisations increasingly turn to Kanban to improve their Lean Agile practices, but few people know the inside story of how and why Kanban was created. The Secret History of Kanban pulls back the curtain and gives you a first-hand account of how Kanban went from being a colossal failure to a startling success. Learn how a team turned theory into practice, what it means for the future of Agile, and how you can apply those lessons in your own organisation. We’ll finish by transitioning from history to the future and what we, as a community, might do to not repeat the errors of the past.
As the world changes, and we start adjusting to "new normal's, it becomes more important than ever to be conscious of the harm our products can cause. Roisi will teach you how to run a remote "Black Mirror" workshop for your organisation, allowing you to fully acknowledge the risky directions your Product could take, and help you avoid them.
Cloud native – the perfect recipe for innovation, adaptability, and engineering excellence. Right? Well, when it goes right. When it goes wrong, sometimes it’s monster spaghetti, sometimes it’s a quality headache, and – worst of all – sometimes it’s exactly as clunky and slow-to-change as what it’s replacing. As a consultant, Holly gets to see really good practices and also the anti-patterns; in this talk, she’ll share stories of what happens when things go wrong.
How cognitive bias and ranking can foster an ineffective architecture and design
The power of collaborative modelling comes from having a diverse group of people who, together, have a lot of wisdom and knowledge. You would expect that all this knowledge will be put to use, co-creating, and to design a model. In reality, we don’t actually listen to all the available input and perspectives due to cognitive biases and ranking. Because not everything that needs to be said has been said, we will end up with sub-optimal models and architecture. Even worse, people don’t feel part of the solution and don’t commit to it. Good architecture and design needs all the insights and perception. If you are not aware, cognitive biases and ranking kills those insights and wisdom and kills the effectiveness of your models!
Join us in this talk where we will explore how we can improve our facilitation skills and focus on neuro-inclusiveness. We will dive into techniques and methods from Liberating Structures and Deep Democracy the Lewis Method. We will demonstrate how you can combine these inclusive techniques with well known collaborative modelling tools like EventStorming, Example Mapping, Impact Mapping, and User Story Mapping. We will let you leave with the knowledge on how to observe sabotage behaviour, battle oppression, and to create safety in exploring alternative perceptions. We will show you how you can really let the group say what needs to be said and take a collective autocratic decision in designing your software models.
La seule chose dont nous sommes maintenant tous convaincus, c’est que nul ne sait à quoi ressemblera notre travail dans 6 mois ou même demain.
Dans ces conditions, comment notre organisation du travail pourrait-elle nous permettre de satisfaire les processus naturels d’apprentissage tels que définis par le docteur Maria Montessori à l’origine de la pédagogie du même nom ?
En 1h je propose de vous présenter ma compréhension de son enseignement (les tendances humaines au service de l’apprentissage continu en entreprise), et quelques exemples de mise en pratique dans le cadre de transformations agiles.
Nous pourrions même réfléchir ensemble à des mises en application qui sait ?
Your IT organisation is surrounded by problems preventing it to satisfy market demand on time with the required quality. Where do you start?
35 years ago, Eliyahu Goldratt introduced the Theory of Constraints in his seminal book "The Goal" as a new management paradigm to running manufacturing plants. Back then, manufacturing plants had similar problems: The production work floor was surrounded by inventory, resulting in late deliveries having poor quality. The Theory of Constraints solved that problem for manufacturing by introducing the five focusing steps - a guideline to systematic improvement and continuous learning.
Today, the Theory of Constraints is one of the underlying foundations for the DevOps movement. It hasn't lost any of its potential for organising thought, and as a driver for continuous improvement.
During this session, we will present the basic principles of the Theory of Constraints, and how it applies to the software industry. It will be a mix of theory, related stories and experiences, and practical advice applicable to the day-to-day work of an IT department.
We live in a competitive world. That competition forces change. It has always forced change. Change is normal. The question is not whether our organizations will change, that’s a given, but can we ride the ebb and flow of change or are we simply rudderless boats being battered by wave after wave?
To answer the question we need to understand our landscape, the economic forces at play, the context we operate within, how evolution flows through our context and our situational awareness of this. During this talk we will examine these issues across Government and the private sector.
Transformations come from individuals who deeply believe in change, in experiences and learning to evolve, to reach another level. In order to foster a culture of transformation at the corporate level, we must rely on these individuals, on the diversity of thoughts, the diversity of visions.
This talk is about creating the conditions for change... not at a corporate level, but at a personal level. How going outside our comfort zone can change the way we think, the way we see our environment, the way we act.
Using personal examples, we will draw the lines between trying diversity in our lives and the results we can achieve.
How thinking small is changing software development big time.
The world is changing fast. More precisely, the world is changing at increasing speed. This means things that were not possible five years ago come into reach. Incumbent organizations need to adapt fast to keep up with new competitors that use new technologies easier, faster and better than they do. As a result, every aspect of software changes towards smaller. Even smaller teams or even micro-teams, less management, flatter organizations, even shorter cycles, and smaller components.
Le premier jalon d'un système Kanban est souvent de retrouver de la sérénité au sein de l'équipe, de trouver un équilibre perdu il y a longtemps. La transition est tellement forte qu'après les systèmes Kanban risquent de vivoter. Comment continuer à insuffler de l'énergie dans son système Kanban pour qu'il continue à être une source d'amélioration continue ? Il faut continuer à se poser des questions ... oui mais lesquelles ?
Dans cette conférence, je vous partagerai un socle de questions qui pourront réinspirer, réorienter les systèmes Kanban pour les amener dans une nouvelle phase. Vous verrez que votre système vous soumet en permanence des questions qui vous amèneront à faire évoluer chacune des facettes de votre système : les demandes, l'objectif du flux, ses activités, ses règles, la collaboration, la stratégie produit, etc.
A la fin de la session, toutes les questions posées seront partagées sur mon blog.
Pour profiter de cette session, vous devez savoir ce qu'est la méthode Kanban et ses 6 principes.
- Apprendre à questionner un système avec Kanban pour le réinventer
COVID-19 sent everyone home to work. And many remote working naysayers saw that when necessary, it was actually possible to work together anywhere. It has, however, been a rough ride as we all discovered that working at home during a pandemic is not the usual way of remote working. But, many of us did it! And in the process, as we smoothed out the bumps, we realized that remote working was not only possible, in some instances, it was preferable. Many offices will not be able to open and operate at full capacity for a long time. At the same time, some people don’t want to go back to the office, even when it’s safe to do so. Now is the time to set up your remote workforce to succeed - no matter where they work. In this presentation, we will discuss, how can we navigate the new world of working as a hybrid team.