The key predictive IT delivery metrics uncovered by the book Accelerate and the State of DevOps Reports - aka “DORA metrics” - point the way towards flow-centric operating models for every modern enterprise building and running software-enriched services. However, improving flow of value within an organization is often difficult due to cross-team dependencies and coupling: everything is tangled. In an organization with 700 software engineers, if 60% of the time is spent waiting on other teams - a typical industry flow efficiency - the financial penalty of dependencies and coupling is high. It is vital, therefore, to invest in decoupling and removing team dependencies - untangling - to enable value to flow better and more efficiently.
In this talk, Matthew Skelton - founder at Conflux and co-author of the book Team Topologies - explores techniques and metrics to help you untangle your software delivery, together with real-world examples of organizations successfully applying Team Topologies and related approaches to decouple teams and improve flow:
Independent Service Heuristics (ISH) User Needs Mapping (UNM) The 4 key metrics (DORA) Flow efficiency and proxy measures
Increasingly, the ideas and patterns in Team Topologies (TT) are being applied worldwide not just in software/IT but increasingly in non-IT contexts like legal services, healthcare, education, and HR, resulting in quicker time-to-market and better ROI. These applications of TT point the way to an operating model for fast flow organizations.
In his new book, “The Rise of Superman: Decoding the Science of Ultimate Human Performance,” Steven Kotler discusses flow triggers – circumstances that facilitate the entry into the flow state Kotler groups the 17 flow triggers into several buckets: psychological, environmental, social and creative. Since we are attempting to explain team performance, our interest lies primarily in the social triggers, defined as “ways to alter social conditions to produce more group flow”. It is uncanny how Scrum is almost precisely designed around these triggers. Could this be the reason why, as Scrum evangelists claim, you can get more done faster, with fewer people, and with higher quality, effectively breaking the “iron triangle”?
Most of Kotler’s social and environmental flow triggers map closely to Scrum practices or principles. Let’s look at the ones that fit:
Serious concentration: To create flow in social settings, you need to ensure everyone has their maximum attention to the here and now, and is blocked off from other distractions. Scrum practices frozen scope for timeboxed iterations, i.e. no changes in the team’s direction are allowed during a sprint. This is done in order to create the necessary period of uninterrupted, focused work, which is precisely what the teams need to achieve higher levels of productivity. Shared, clear goals: Groups need to be clear about what their collective goal is in order for flow to happen. Practices described above, like information radiators and visualizing things like scope, progress and task status serve exactly that purpose. Good communication: This one is almost self-explanatory. Constant communication is necessary for group flow, according to Kotler. Scrum practically forces constant, open, intense many-to-many communication, where everyone not only has a voice, but is fully expected to use it. Familiarity/common language: Kotler stresses the importance of common language, a shared knowledge base and a communication style based on unspoken understandings. This is almost precisely the description of the emergent tacit knowledge emphasized by all Agile methods. Equal participation: Flow is most likely to happen in a group setting when all participants have an equal role in the project. This is reflected in the cross-functional and self-organizing nature of Scrum teams, as well as such practices as collective code ownership (which stems from Extreme Programming but is widely used by many Scrum teams). Risk: There’s no creativity without failure, and there’s no group flow without the risk of failure. The group has to have some skin in the game to produce group flow. Scrum teams are constantly making clear commitments to their customer (internal or external, in the case of outside partner teams) and there is always the risk of underdelivering on those commitments. Sense of control: Kotler defines sense of control as the combination of autonomy (being free to do what you want) and competence (being good at what you do). Again, this is precisely how Scrum is set up: competent, highly motivated, self-organizing, cross-functional teams that are not micromanaged, but rather choose their own implementation path and are accountable to the customer for the ultimate results.
In order not to overload the process you simply need to control how much work is allowed to enter it across the arrival point. Getting a balanced process is the single most important step towards predictability; and how WIP is limited is less important than actually doing it. In Tameflow, the amount of work that is allowed to enter into the process is limited to the amount of work that can be handled by the constraint. All and any prioritization is done only when capacity is available and only to the extent that can be handled by the Constraint. The state of the process must be taken considered when making prioritization and pull decisions.
By representing the “Done” states, the waiting time between any successive steps of the process is captured and portrayed in the Cumulative Flow Diagram.
Any violation of the assumption of Little’s Law will become visible on the Cumulative Flow Diagram.
You must keep track of the times of arrivals and departures of the single work-items into and out of each state of the process.
You must avoid depicting backlogs and projections on a Cumulative Flow Diagram.
A MMR is a work package that has been truly committed to.
With an MMR, the Cumulative Flow Diagram will look like an S-Curve, due to work being started from zero at the beginning, and then going back to zero at the end.
With MMRs you must take into account that the average Cycle Time will be skewed because of the initial batch transfer.
The notions of Cycle Time skewing and of the S-Curve effect need to be fully understood and considered if you are using MMRs.
With actionable agile metrics, you can run experiments with your process and see what gives the best measured outcome in your context.
The horizontal difference between any two lines represents the Approximate Average Cycle Time.
Typical patterns and shapes that may develop on a Cumulative Flow Diagram reveal common flow problems and process dysfunctions.
The purpose of a Cumulative Flow Diagram is to trigger the right questions about the process, trigger them sooner, and suggest improvement actions.
Cumulative Flow Diagrams should not be used to identify bottlenecks.
We will now continue to see what Dan has to teach in chapter 7, 8 and 9 which are all about Conservation of Flow
À l’instar des autres pratiques de développement, la revue de code ou le mob programming ne peuvent pas se mettre en place indépendamment de considérations sur la culture de l’entreprise qui souhaite encourager ces pratiques. Certaines cultures d’entreprise favorisent activement la formation d’équipes en cohésion (principalement en ne plaçant pas d’obstacles à leur formation). Dans d’autres cultures, la notion même d’équipe est dénuée de signification réelle. De la même manière qu’aucune pratique de développement ne saurait être « copiée/collée » d’une entreprise à l’autre sans considération du contexte, il est apparent que toutes les entreprises ne sont pas égales devant le défi que constitue le développement d’un logiciel de qualité. La présence ou non des revues de code dans leur corpus de pratiques est à mon sens une preuve de cette inégalité.
The Flow System is a holistic FLOW based approach to delivering Customer 1st Value. It is built on a foundation of the Toyota Production System (TPS/LEAN) and the new Triple Helix of Flow creating the DNA of Organizations.
The Flow System enables business growth through eliminating non-value-added activities, fostering an environment for innovation, enabling the rapid delivery of value, and shortening the time to market. The Flow System provides a re-imagined system for organizations to understand complex problems, embrace distributed leadership, and build high performing teams.
The Triple Helix of Flow relates to the interconnected nature of the three helixes:
Complexity Thinking Helix &; A new form of thinking to aid the understanding of uncertainty and complex adaptive systems.
Distributed Leadership Helix &; An emergent hybrid leadership model that is capable of making bold and disruptive moves across an industry.
Team Science Helix &; A multidisciplinary field that studies all things related to teams and small groups in the workplace.
The Triple Helix identified the interactions between and among agents (people, machines, events&;) that emerge into new patterns, networks, and knowledge to advance an organization&;s ability to be more innovative, adaptive, resilient, and agile when operating in complex environments.
&;The Flow System shows how to generate and nurture self-organizing teams that mobilize the full talents of those doing the work to cope with dizzying change and complexity, while also drawing on the contributions of those for whom the work is being done&;the customers.&;&;Steve Denning, author of The Age of Agile
David Anderson explains his reason for encouraging teams to abandon the use of words such as "priority" and "prioritization" to achieve a shift in mindset to a flow-based approach.
The Flow System elevates Lean Thinking in an age of complexity by combining complexity thinking, distributed leadership, and team science into the Triple Helix of Flow, which organizations can use to become more innovative, adaptive, and resilient. This second article on The Flow System dives into the three helixes of complexity thinking, distributed leadership, and team science.
Et bien justement : c’est une bonne question : comment faites-vous car la distance induit souvent des relations asynchrones, une proximité moins forte et donc une collaboration moins fluide ?
Notre seul sujet dans le cadre des collaborateurs remote est de faciliter la collaboration. Remote ne signifie pas nécessairement asynchrone. C’est le cas si la différence entre les plages horaires est élevée. Mais s’il s’agit de collaborateurs à Belgrade ou au Portugal par exemple, il n’y a qu’une heure de décalage. Un exemple de question que nous nous posons sur le sujet du point quotidien : comment rendre cela agréable pour des personnes extérieures, qui ne sont pas sur place ? Nous avons digitalisé quelques visuels mais pas tous car c’est important d’en conserver un certain nombre en physique.
L’enjeu est lié à la clarté de la communication orale. Il est aussi important d’apprendre à bien converser à l’écrit, dire l’essentiel en peu de mots. Nous faisons aussi levier du pair-programming. Nous invitons à des changements fréquents de pair-programmers pour éviter le sentiment d’isolation et renforcer l’esprit de communauté de l’ensemble de l’équipe.
Enfin notre approche par one piece flow, nous impose d’avoir, dans la mesure du possible, un maximum de personnes qui travaille sur une même feature simultanément afin de la livrer au plus vite. Cela contribue aussi à créer des liens forts même pour les personnes à distance.
Read the story of Ericsson Finland’s 10-year change journey to a lean and agile mindset – through learning, enablement, empowerment, emotion and growth.
Flow debt is when the cycle time of a task in progress is reduced by borrowing cycle time from other tasks in progress. Team members preferentially work on this task at the expense of others in the process. Any shift in priorities, deviation in the management focus, or other interruption in the middle of the process can generate flow debt.
As with financial debt, the short-term benefits of accumulating flow debt can be worth the long-term costs associated with it. Focusing all team efforts on resolving an emergency may be the best course of action. In these cases, it is essential to understand how build-ups of flow debt affect your whole process.
The delay of other work items is the less costly effect of the flow debt. What is more crucial is that the flow debt has a negative impact on the predictability of your whole Kanban workflow and makes your estimates less accurate.
I was slow to pick up on Flow in late 2017, initially putting in down as another Kanban, but it's a lot more with faster cycles & outside in experimentation, supported by DevOps. See https://www.flow-academy.org/.
Lean Kanban, Professional Scrum with Kanban, and Flow share the following:
support for knowledge work
acceptance of variation
capability (if due care is taken) to deal with complex work
where there are unknown unknowns
creativity with visual signals practices
Lean Kanban and Professional Scrum with Kanban are strong with optimization of flow, metrics, workflow definition, design & management, and probabilistic forecasting.
Flow is stronger with alignment, faster cycles, and outside in thinking, for now.
The concept of “Flow” is defined in that, the cards should flow through the structure as evenly as possible, without having to wait for long or causing blockages. All the stuff that block the flow need crucial examination and attention. There are various techniques used in Kanban, metrics and models, and in case they are persistently put, it causes a norm of continuous improvement (Kaizen).
For effective, modern, cloud-connected software systems we need to organize our teams in certain ways. Taking account of Conway’s Law, we look to match the team structures to the required software architecture, enabling or restricting communication and collaboration for the best outcomes.
This talk will cover the basics of organization design using Team Topologies, exploring a selection of key team types, and how and when to use them in order to make the development and operation of your software systems as effective as possible. The talk is based on the forthcoming 2019 book Team Topologies and first-hand experience helping companies around the world with the design of their technology teams.
Key takeaways:
1. Why using the “Spotify Model” of team design is not enough
2. The four fundamental team topologies needed for modern software delivery
3. The three team interaction modes that enable fast flow and rapid learning
4. How to address Conway’s Law, cognitive load, and team evolution with Team Topologies
The Flow System is a built on a foundation of The Toyota Production System, known as TPS & LEAN, plus a triple helix structure, the DNA of Organizations.
Being agile is all about controlling the flow. Like many technology movements before it, agile is is more about your organizations ability to execute
Mickael Ruau's insight:
Like TQM, Six Sigma, and E-Business, Agility will require changes to the fundamental way that a business operates. An analogy of this process can be as benign as a person recovering from knee surgery or as complex as recovering from a stroke depending upon what the business wants to accomplish and how they are organized currently. Along the way, people will most likely be the biggest hurdles to success.
When change of this magnitude occurs, employees tend to become very myopic of their own situation. To mitigate this risk, it is critical that changes are reviewed with employees prior to change, during implementation and after the change is enacted. Management must gauge if employees are struggling because the complexity of the change or because they personally don’t agree with the change.
Let’s reveal the role that flow plays in knowledge work, and how utilizing the main flow metrics enables you to establish predictable delivery systems.
Mental state in terms of challenge level and skill level, according to Csikszentmihalyi’s flow model.
In 1997, Csikszentmihalyi published his flow model, illustrated to the right. It shows how getting the right balance between challenge in a task and the skills you have to perform the task can help you achieve flow. If the balance is not right, say, for instance, that both the challenge and your skill level is low, you will not achieve flow. Instead you’ll fall into apathy. However, if both the challenge is high and your skill level is high, you can potentially achieve flow. We’ll talk more about these two conditions for flow in a minute.
But first: There are more than just a perfect balance of challenge and skills that are necessary to achieve flow. 16 years after Csikszentmihalyi, in 2013, Owen Schaffer, Lead Usability Analyst at HFI, proposed 7 flow conditions. They include Csikszentmihalyi’s “challenge” and “skills”, but also other conditions:
Passer à une “Culture Flow” c’est changer sa vision du temps. Plusieurs principes structurants nous aident à y arriver. Pourquoi des principes ? Parce qu’il résistent au temps là où les méthodes et pratiques évoluent pour s’adapter aux environnements.
Nous allons donc passer en revue 13 principes structurants, c’est-à-dire dont la mise en place générera des changements tangibles.
Mickael Ruau's insight:
Les principes “bleus”
L’industrie du développement logiciel étant maintenant mature, ces principes peuvent être appliqués sereinement et sans risque, leur objectif est d’aider à créer le flux de valeur. De nombreux formations et accompagnements existent pour aider à leur mise en oeuvre qui ne nécessite pas d’expérimentation préalable tant ces derniers font consensus.
Toute décision est prise suite à un événement et non une date planifiée. ⇒ il convient d’accepter l’incertitude, réduire la taille des lots et limiter l’encours
Chaque équipe connaît son flux, elle sait où et comment le réguler.
La répétabilité des événements en accroît la maîtrise. ⇒ la qualité logicielle au coeur afin de garantir une stabilité et une capacité de livraison de chaque instant
Rendre visible les problèmes.
Faire le lien entre la production et la stratégie de l’organisation à chaque niveau de l’organisation. ⇒ la transparence de haut en bas et de bas en haut
Les principes “jaunes”
Ces principes doivent faire l’objet d’une expérimentation avant toute généralisation et d’un accompagnement afin d’en adapter la mise en oeuvre et d’en estimer l’impact. La plupart de ces éléments sont appliqués par les industries fonctionnant en flux.
Passer des changements de comportement à de nouvelles habitudes. ⇒ régulièrement se challenger et ajuster nos habitudes
L’écart entre les prédictions et la réaliser permet de se repositionner par rapport à la cible. ⇒ partager une vision commune et des futurs possibles, mesurer, ajuster
Les feedbacks sont une aide à la décision. ⇒ intégrer des boucles de retours, interne et utilisateurs
Les organisation techniques et humaines sont liées (dite loi de Conway)
Organiser les écosystèmes de sorte à minimiser les frictions par rapport à la stratégie ⇒ étudier les différents typologies d’organisation (chaîne de valeur / domaine)
Les principes “rouges”
Ces principes sont une source d’inspiration qui doit être discutée avec un expert du domaine afin d’en étudier la mise en oeuvre.
Nous apprenons quand nos réflexes mentaux évoluent. ⇒ générer de la divergence, ouvrir ses chakras
Le système doit être capable d’accepter une dose de désordre. ⇒ chacun doit prendre le maximum de risque possible à son niveau de sorte à se laisser expérimenter, sinon le risque va devoir être pris plus haut et il sera plus risqué
Se donner du rythme pour le changement, pour accompagner un mouvement permanent. ⇒ le changement ne doit pas être permanent, il faut l’accompagner en continu
En résumé, les principes bleus permettent d’initier et de rendre palpable le flux, les principes jaunes et rouges ouvrent la voie à l’atteinte d’un flux dit “laminaire” (sans heurts) et d’en augmenter progressivement le débit.
The Flow System elevates Lean Thinking in an age of complexity by combining complexity thinking, distributed leadership, and team science into the Triple Helix of Flow, which organizations can use to become more innovative, adaptive, and resilient. This first article explores the importance of quality, getting fast feedback from customers, the concept of flow, and The Flow System.
I used to play the famous Ball Point Game when providing Scrum training or introducing the Agile and Scrum way of working in teams. Now with all the remote sessions and training’s I created a nice and energetic online replacement. Instead of tennis balls the participants choose an object everyone have. For example a pen.
The learning goals are:
learn to estimate feel how it is to be in flow experience the power of the retrospective what is velocity (after the game)
High flow efficiency is vital to sustaining a scalable, productive business. Learn how you can calculate, analyze and improve your flow efficiency to deliver value faster.
In working with hundreds of product teams, I hear a recurring question: how do I create more flow in my process so that I can create more valuable outcomes? Creating flow in product development comes down to limiting work in progress, defining small batches of work, and shipping new bets faster. In this video and article, I get into what that looks like and ideas to make it happen in your organization.
The Flow System is a built on a foundation of The Toyota Production System, known as TPS & LEAN, plus a triple helix structure, the DNA of Organizations.
To get content containing either thought or leadership enter:
To get content containing both thought and leadership enter:
To get content containing the expression thought leadership enter:
You can enter several keywords and you can refine them whenever you want. Our suggestion engine uses more signals but entering a few keywords here will rapidly give you great content to curate.
Your new post is loading...
Scoop.it!
