La deuxième présentation à la Conférence Agile France 2011 proposait six bases essentielles pour mettre en place un environnement de travail Lean ou Agile. Comme toujours il y a de bonnes nouvelles et de mauvaises nouvelles:

• La bonne nouvelle: Lean et Agile ne sont pas de la magie, entre temps on sait pourquoi, où et comment ça marche
• La mauvaise nouvelle: ce n’est pas compliqué, mais c’est vraiment dur de mettre en place les prérequis nécessaires.

La présentation ne donne qu’un aperçu de chaque élément. Voici des ressources pour les 3 premiers élements, qui peuvent vous aider dans vos recherches. Les 3 autres éléments seront décrit dans un billet suivant.

1. La Théorie des Contraintes

Originalement décrite par Eli Goldratt dans le roman “Le But”, cette théorie se résume très facilement:

• Le résultat de chaque système est déterminé ou limité par un de ces élements, le goulot d’étranglement
• La seule façon d’améliorer les résultats est de travailler sur le goulot.
• Améliorer les autres élements du système n’apportera pas de bénéfices, cela aura souvent un effet négatif!

Comme mon grand-père savait déjà: “pour rendre une chaine plus forte, il faut renforcer le maillon le plus faible”.

Le “Jeu du Goulot d’étranglement” vous fait vivre les conséquences qui vont souvent contre le “bon sens”.

2. Les Real Options

Au lieu de prendre des décisions difficiles le plus tôt possible, comme nous encourage toute la littérature sur l’architecture informatique, il faut

• attendre jusqu’au “bon” moment pour prendre chaque décision. On peut calculer exactement quand c’est le bon moment: la date de livraison – le temps d’implémentation de l’option
• jusq’au moment de la décision on garde toutes les options ouvertes
• on utilise le temps gagné pour rechercher plus d’informations ou pour créer d’autres options
• on essaie de réduire le temps d’implémentation de chaque option afin de repousser vers l’arrière le moment de la decision

L’heuristique que j’utilise:

• Une décision difficile à défaire doit être prise tard. J’essaie de réduire le temps d’implémentation pour avoir plus de temps de reflexion et évaluation.
• Une décision facile à défaire peut être prise tôt. J’essaie de convertir des décisions difficiles à défaire en décisions faciles à défaire.

Exemples concrets:

• Les User Stories nous donnent l’option de prendre des décisions difficiles de planning et contenu du produit plus tard que d’habitude
• Du code clair, facile à comprendre, bien factorisé avec des tests automatiques nous permet de défaire des décisions de design et architecture à faible coût qu’on a fait auparavant pour implementer de nouveaux besoins
• Le tableau Kanban permet à l’équipe de voir les goulots en temps réel et de réagir en conséquent.

L’article “Real Options Underlie Agile Practices” par Chris Matts (en anglais) explique les Real Options et le lien avec Agile et lean. Il y a un résumé des Real Options sur le site Agile Coach.

3. Gérer par la valeur, pas par les coûts

Au départ de nos projets on se met d’abord d’accord sur notre définition commune de “valeur”. Don Reinertsen appelle cela un “Project Economic Framework” dans The Principles of Product Development Flow: Second Generation Lean Product Development. Nous appellons cela un “Business Value Model” ou “Modèle de la Valeur Métier”.

Bien définir la Valeur avec toute l’équipe apporte beaucoup de bénéfices:

• Toute l’équipe est alignée
• Comme nous comprenons mieux le vrai but, il est plus facile de trouver des vraies solutions
• Il est très facile de prioriser
• Les projets deviennent plus petits parce qu’on élimine ce qui n’ajoute pas ou pas assez de valeur

La présentation

La semaine passée j’ai présenté comment résoudre les conflits avec le “Diagramme de Résolution des Conflits” à la Conférence Agile Paris. La présentation est disponible ci-dessous. Plus d’informations sont disponibles sur le site Agile Coach.

A la fin de la présentation il y a deux questions pour voir si vous avez compris la leçon:

1. Est-ce qu’il est possible de former un gouvernement belge avec cet outil? Si oui, pourquoi? Si non, pourquoi pas?
2. Est-ce que vous pouvez résoudre ce conflit récurrent entre Product Manager et Développeurs:
   • Le Product Manager a besoin d’estimations et de planning très détaillé et fiable pour publier une roadmap qui dit quand quel fonctionnalité sera livrée quand ET livrer ces fonctionnalités comme promis
   • Les clients, qui souvent sont des grandes entreprises avec plusieures filiales dans les monde et beaucoup d’utilisateurs, ont besoin de cette roadmap pour planifier quand ils vont implémenter une nouvelle version
   • Les Développeurs sont “passés au Kanban”: ils ont arrêté de faire des estimations ou des plans. Cela prenait beaucoup de temps et ce n’était jamais correct.
   • Les Développeurs “éliminent le gachis” parce qu’ils doivent aller de plus en plus vite pour satisfaire les requêtes d’un nombre de clients qui toujours croissant.
   • Tout le monde veut livrer les fonctionnalités au client au moment où les clients attendent ces fonctionnalités.

Vos réponses et questions dans les commentaires…

D’abord essayez de clarifier le conflit.

Puis, découvrez les suppositions derrière chaque étape du raisonnement.

Translation

I presented an interactive tutorial on how to apply the “Conflict Resolution Diagram” at the French Agile conference in Paris. You can see the English version of the presentation at the Agile Coach site.

At the end of the French version of the presentation there are two tests to see if participants understood the tool:

1. Can you use this tool to form a Belgian Governement. If yes, why? If not, why not?
2. Can you resolve this common conflict between Product Manager and Developers:
   • The Product Manager needs detailed estimates and accurate planning because she has to create a long-term roadmap which spells out which features will be delivered when AND deliver those features when promised to keep customers’ trust
   • Customers, who are typically large multi-site companies with many users of the product, need the roadmap because they need to plan when they will roll out which version throughout the enterprise
   • Developers have “gone Kanban” and have stopped estimating and planning because the estimates took too much time and were incorrect anyway
   • Developers stopped estimating and planning to decrease waste so that they can keep up with the increased demand for features from the increasing user base
   • The whole company wants to deliver the features customers ask for when customers expect them.

Answers on a postcard or a comment…

First, try to clarify the conflict.

Then try to find the assumptions behind each step of the reasoning.

Portia Tung and I ran the “Agreeing on Business Value” session at the Mini XP Days Benelux 2011 conference. In the workshop participants have to create a “Business Value Model” for a case we provided. The Business Value Model shows the most important goals and measures of the company and the relationships between goals. We often run this workshop to let a team come up with a common definition of “Business Value”. As a result of the workshop, everybody’s has a clear and common understanding of the value the project or product is going to deliver.

We asked the teams to add what they learned at the workshop on the posters. Here’s a gallery of the outputs of different groups. Click on the images to get a larger picture.

Team 1

In the model different types of goals have different colors: financial goals are blue, organisation goals are green and people goals are yellow. At the top are the “lagging measures” (those that can only be measure late). At the bottom are the “leading measures” (that can be measured early) that will be used to predict the achievement of the desired lagging goals. Arrows indicate that one goal has an effect on another. You’ll see that most things are interrelated. The good news is that achieving one goal can help achieve other goals in reinforcing loops. The bad news is that you may have to achieve many subgoals to achieve your desired goals.

This team identified the following learnings:

• Makes a complex project more clear
• Business alignment. Today business cases are made individually
• Helps to give an overview of goals for all stakeholders
• Make decisions at goal level, not at feature level
• (You can use this for) portfolio management!
• Thinking about measures

Team 2

Here we se a simpler model, but still representing the financial, organisational and people goals with their relationships. Everything leads to “Make Profit”

What they learned:

• When we talk about business value, we need to think about how to measure leading and lagging indicators
• Adding the relationships generated new insights
• Plan-Do-Check-Act
• Eliminate “business value” that doesn’t really add value

Team 3

Another very clear model with positive (+) and negative (-) effects between different goals. In the end, it all results in “Cost Cutting”

What they learned:

• It starts with a vision
• You involve everybody
• To build a model, iterate over the following steps until satisfied:
  • Identify goals
  • Define Lagging and Leading measurements
  • Identify relationships (“Diagram of Effects”)

Team 4

This model has exactly one leading and one lagging indicator per area. Together, the goals result in profit.

This team created a diagram of what they learned:

• Value is not just money
• Value must be measurable
• We have leading (“early”) and lagging (“late”) measures
• We need to identify the relationships between the measures

Team 5

This team considered more lagging (yellow) and leading (pink) goals. Many of the goals have more than one possible measurement. If you have multiple ways to measure a goal you can choose the cheapest measure to collect or find some data that’s already being collected.

The important points for this team:

• Identify
• Categorise
• Quantify
• Relationships

What the presenters learned

• Everybody got the same case, but there are differences in the models. There is no “right model”, the team has to find one that’s useful. Over the lifetime of a product or project the business value model will probably change, as different goals change in importance
• The case is not too simple, and there’s lots of information, just like a real project. Despite that complexity teams of six “strangers” came to a clear agreement on the goals of a project within 90 minutes. How long does it take in your project to come to agreement on goals and priorities. If your projects are like mine, probably the whole duration of the project
• Making our definition of business value clear, finding ways to measure and thinking about effects and relationships helps to come up with new insights
• Participants don’t ask many questions. We were available the whole time to answer questions about the technique or the case, but despite having real live “customers” in the room, participants concentrated on the written materials
• We started by describing and drawing the company vision on the whiteboard. Most teams quickly lost sight of the vision. Once they “rediscovered” the vision, they found that it answered some questions about value and priority. It would be good to remind people of the vision before every turn. Maybe we could do this in our work too? Why not start each project meeting with a reminder of the vision?

If you want to know more, head on over to the agilecoach.net site where you’ll find more about Business Value Modeling and some other useful tools.

If you applied any of these techniques, let us know how it went.

In this interactive tutorial you’ll be able to apply “Business Value Modelling” on a case study, to decide on the goals and definition of value for an improvement project.

Come and play with us!

See you there on April 7th!

See you on April 1st in Mechelen.

XP Day session tryout: Agreeing on Business Value with Systems Thinking

Cap Gemini will host the next Agile/XP Belgium usergroup meeting. This session is a tryout for XP Days Benelux.

We talk a lot about “maximizing business value”. We ask business people and product managers to prioritise by estimating the business value of user stories. But what exactly do we mean by business value?

Over the past few years we’ve worked with many teams to define their “Business Value Model”, a clear definition of the value a project will bring to the organisation. The exercise hasn’t always been easy but it has always brought significant benefits:

• Measurable business value in units that impact the organization (such as revenue €€€, customer satisfaction, staff retention)
• Everybody involved was more motivated because there was a clear reason for the project and they finally understood what it was
• The whole team was aligned around one vision because we had clear criteria to define success
• We came up with more innovative solutions because everybody on the team, not only “the business” or “product managers/owners” could take product-related decisions based on the model
• We could deliver a lot faster than anybody expected because the Business Value Model allowed us to easily distinguish between value-adding and non-value-adding features
• We spent a lot less time writing and prioritising user stories because we were able to derive the user stories from the value definitions
• The Business Value Model guided us to explore new product ideas: the business value model was a hypothesis that we could test and refine each time we released or performed user testing.

In this interactive tutorial you’ll apply some Systems Thinking techniques, such as the Diagram of Effects and Intermediate Objectives Map) to define the business value model of an example project. We’ll show you the techniques we used and discuss how you can apply those techniques in you context so that you’ll be ready to start building a business value model with your team.

Agenda:

• 18:00 – 19:00 – Welcome with snacks and drinks
• 19:00 – 21:00 – Session

Address: Bessenveldstraat 19, B-1831 Diegem, Belgium

Register here for this free event

XP Days Benelux 2010 will be held in Kapellerput, Heeze (near Eindhoven), The Netherlands on 25-26 November

The program for XP Days Benelux has been published. This year we have more sessions than ever before: 41 sessions over 2 days. As always, it’s going to be hard to select only one session from the five parallel tracks.

I’ll be presenting “Agreeing on Business Value with Systems Thinking” with Portia Tung. I’ll be doing a tryout of this presentation, which has been updated after presenting it at Agile 2010. Come to the Agile/XP Belgium user group meeting on Tuesday 26th of October.

If you want to see a tryout of the “Database Change Management” session, join us in the Agile/XP Belgium user group meeting on Tuesday 5th of October.

IHC hosts the next Agile/XP Belgium usergroup meeting. There will be two sessions in parallel

Session 1: “A journey into Database Change Management” by Jochen Jonckheere and Pascal Mestdach. This is a tryout for XP Days Benelux.

Abstract:

We will bring you the story of our journey into database change management. We share our experiences with concrete examples/common situations and explain the different parts of Database Change Management along the way. During our journey we encountered several problems. We let participants reflect on how they would solve these problems, before we show the solution we picked. This is an interactive technical session where you will see 2 developers working together, writing some small sql scripts, breaking and fixing automated builds and even in the end a tool for handling Database Change Management in an automated way in the .NET environment.

Session 2: To be decided

Agenda:

• 18:00 – 19:00 – Welcome with snacks and drinks
• 19:00 – 21:00 – Parallel Sessions

Register here for this free meeting.

Address: Legeweg 157 E/02, 8020 Oostkamp, Belgium

Last Thursday and Friday I participated in the Lean and Kanban Belgium 2010 conference. I was scheduled to present a session on Friday morning, so I could go to many sessions on Thursday.

Every session that I attended on Thursday said many things I wanted to say:

• Sandrine Olivencia talked about challenging the team for continuous improvement
• Dave Nicolette talked about the dysfunctions around budgeting and the need for IT to integrate, not align, with the value stream
• Anthony Marcano and Andy Palmer explained how analysis can be implemented as a pull system
• Ryan Shriver essentially said all I wanted to say about finding the real goals of our users and quantifying their needs
• John Seddon told tales about really understanding value demand and taking a systems thinking approach to the design of work in his usual, inimitable style

What was left to say? At the end of the day I could scrap about 3/4 of my talk. The good news is that many people are independently reporting that these techniques and approaches work. And they can show results.

In the end, there was more than enough to fill an hour. After the presentation several people asked questions and discussed what I presented.

p.s. I followed Dave Nicolette‘s advice to grow a profitable consultancy: coin a new acronym. I give you “IDD”. You’ll have to watch the presentation to know what it means. And you’ll have to pay me big bucks to come implement it in your organisation

• Pinocchio: On Becoming a Lean Leader
• Agreeing on Business Value with Systems Thinking
• Estimation Games

I hope you enjoyed the session or get some useful ideas from the session materials. Let us know how you’ve applied these tools.

The session will show how using business analysis and kanban techniques we can create a flow from business goals to implementable user stories with acceptance test, focus on value-delivering capabilities and involve the whole team in product development.

The “A3 report” is a standardized report format used within Toyota and other companies to make proposals and report. The standardized and constrained format helps the writer and readers to come to the point quickly, concentrate on the essentials and get the important information without wasting time.

However, when applying this technique we often only implement the superficial elements, the fact that the documents are limited in size and have a standardized format. Sometimes, the exact format of the Toyota reports is copied. And then we’re disappointed because this “cargo cult” application only delivers limited benefits.

In this session we’ll look at and let participants experiment with the social aspects of the A3 report:

• How we define the standardized format to support our goals
• How leaders and managers use A3 report writing by their team members are structured one-to-one coaching
• How to build in iteration and feedback from peers to improve the proposals
• How to use the review process as a consensus building tool
• How to present reports in such a way that they’re heard, understood and accepted

Come and play with us if you want to learn more about this powerful continuous improvement and learning tool.

If you want to know more…

• In “Pinocchio, On Becoming a Lean Leader” (Tuesday August 10, 13:30-15:00) Portia Tung and I help participants along the dangerous journey from toy boy to real boy. You’ll meet all your favourite characters from this Agile Fairytale and come away with some concrete actions to become a better leader.
• “Agreeing on Business Value using Systems Thinking” (Wednesday August 11, 09:00-10:30) is a workshop where Portia Tung and I help participants come up with a “Business Value Model” for their current project. You’ll be able to use the Business Value Model to identify the high value solutions that satisfy your customers. The number of places for this workshop will be strictly limited to 20.
• “Estimation Games” (Thursday August 12, 13:30-15:00) gives participants some rules of thumb to create reliable estimates with little effort. During the session we’ll play some small estimation games to put the lessons into practice. You need never be afraid again of estimating.

If you want to know more…

I’m looking forward to return to Geneva to take part in the second Swiss XP Day. Last year’s event was a lot of fun.

This year, I’ll co-present “Agile Project Management in practice” with Portia Tung and I’ll help Portia run the “Coaching with the Wizard of Oz” Agile Fairytale.

La gestion de projet agile en pratique

Est-ce qu’il y a des chefs de projet dans un projet agile ? Qu’est-ce qu’ils font ? Quelle est la différence avec un Scrum Master ? Quelle est la différence entre la gestion de projet « agile » et la gestion de projet « normale » ? A travers des présentations, jeux et exercices nous vous proposons un ensemble d’outils et techniques que vous pourrez appliquer dès demain pour améliorer le déroulement et les résultats de vos projets.

Apprenez les techniques de coaching avec le magicien d’Oz

Pour pouvoir aider les autres (et soi-même) avec du coaching il faut mettre en pratique quatre activités :

• Poser les bonnes questions
• Écouter ce qui est vraiment dit
• Observer ce qui se passe vraiment
• Donner le bon feedback au bon moment

Le coaching est simple, mais pas facile. Quelque soit votre rôle dans l’équipe, ces techniques seront utiles pour améliorer chaque jour. Apprenez quelques techniques de coaching et mettez-les en pratique. Les personnages du Magicien d’Oz vous aideront sur la longue route de brique jaune vers la cité d’Émeraude.

A bientôt les amis Suisses et Français!

Portia Tung and I will co-present the opening keynote “Pinocchio: On Becoming a Lean Leader” at the Agile Turku Day 2010 in Turku, Finland on March 17th 2010.

Come and play with us to sharpen your leadership skills!

Portia Tung and I will co-present “Solve Conflicts Without Compromise with the Conflict Resolution Diagram” at the SPA 2010 conference in London on May 19th 2010.

Come and play with us to sharpen your problem-solving skills and come up with real solutions to a difficult choice you’re facing.

The Systems Thinking materials for this session are available on the Agile Coach site.

Portia Tung and I will co-present “Pinocchio: On Becoming a Lean Leader” at the SPA 2010 conference in London on May 18th 2010.

Come and play with us to sharpen your leadership skills!

My second visit to Helsinki. Last year’s Scandinavian Agile was great. This year’s was even better.

What Went Well

• Presenting the Toyota Way with Portia. I presented this session for the first time at XP Days Paris 2006. Since then, it has been changed and refined each time it’s run. Most importantly, it includes the stories and experiences we accumulated by applying these techniques over the past years.
• Meeting the other participants over coffee, lunch and dinner and at the pub.
• Running a “Conflict Resolution Diagram” systems thinking session with some 15 participants. More about the technique later.
• Helping Artem Marchenko to run the Business Value Game. It’s always interesting to see how other presenters run the game and “steal” their good ideas.
• The location: beautiful and cold autumn Helsinki. The conference center was ideal for the first day: two large presentation rooms and  three smaller workshop rooms, connected by a large open space with coffee and cakes.
• Getting tips for more books from Tom Poppendieck after the Toyota Way session.
• Visiting the Reaktor offices, getting a tour (including the “Russian” room) and discussing sauna’s, Steve Jobs’ management style and the difference between being able to do business analysis and teaching others to do it.
• Discussing Business Value modelling at the Open Space.
• The open space session announcements became more and more original and fun as each presenter tried to top the presenter before them.
• The conference went smoothly and everything was well-organised. Great job, conference organisers!

What Went Wrong

• I didn’t know the contents of the sessions. The schedule overview only contains session titles, with no way to click through to a detailed session description. There were no “session adverts” at the start of the conference, where session presenters could tell me why I should go to their session.
• The morning program was too cramped: what looked like two back-to-back 60 mins sessions were actually two 50 mins session with a 10 minute break. I prefer longer breaks. For example: at XP Days Benelux we have 30 minute breaks between sessions.
• Overrunning the timeslot for the Toyota Way session. We stayed in the timebox during rehearsals, so we need to ensure that we can do it live too.
• The Open Space didn’t make very good use of the room space: the working groups were too close to each other, so that it was difficult to understand each other with all the noise around us. All working groups stayed in their appointed place, while there was plenty of good space going unused in the middle of the room. That just shows how little we question arbitrary constraints.
• To avoid the noise and overcrowding problem, we ran the Conflict Resolution Diagram session downstairs in the coffee room. Unfortunately, we weren’t the only ones, so the session was still too noisy and cramped.
• A participant told me he walked out of the Toyota Way presentation shortly after the beginning because it  looked “too basic”.

Puzzles

• Why the need to make “controversial” statements and speeches? It seems to me that the Agile community prefers infighting over advancing the state of the art and delivering value. That is, while there is value in the items on the right, we value the item on the left more. Sectarianism (“Scrum vs Kanban”, “Agile vs Lean”) does not help me do my job.
• Why no Post-Its at the Open Space? How can you expect me to work without Post-Its?
• Why are so many sessions only about theory, even the one that told us to distrust presenters who present only theory without any concrete examples? Where did you do this? Who were the people who applied this? What were their results?
• What does a maniac with a power drill pointed at me have to do with involving people in Kanban? Karl, your Kanban presentation scared me

Lessons Learned

• If you want to run an effective open space, you need the right kind of space. Ideally, separate spaces or rooms that are sufficiently private to allow for discussion and work AND sufficiently public so that it’s easy to go from one space to the other.
• The Conflict Resolution Diagram technique is very simple. It’s also incredibly difficult because you have to question openly, approach a problem with an open mind, take the time to understand the real problem before prescribing a solution and be willing to surface and question all your assumptions. But the reward is huge: you’re able to transform “either this OR that”, “this VERSUS that” and “this OVER that” statements into “this AND that” statements. We can have our cake AND eat it too, if we choose to live a meaningful life and learn to apply some systems thinking.
• The Toyota Way presentation can become better and can be delivered better. See for yourself at XP Days Benelux 2009.

Takt time

Takt time is the rate at which customers buy a product. Takt time determines the speed at which a Lean manufacturing runs. For example, say we sell 576 units of product A. If we have a 8 hour shift, we need to make 72 units per hour, or 1.2 units per minute. We have 50 seconds per unit.

Every step in the production process must now deliver their contribution to the product in 50 seconds.

What if there’s a step that can’t deliver in 50 seconds? Then we have a bottleneck. We’ll produce and sell less than we could. We apply the 5 focusing steps to increase the bottleneck’s capacity so that they can deliver in 50 seconds or less.

What if there’s a step that can deliver in less than 50 seconds? They still deliver every 50 seconds, even if they have to slow down. If they delivered more frequently, we’d build up lots of work in process as other steps can’t use its output faster than once every 50 seconds. Or we might build unsold goods.

Slowing down? Isn’t that inefficient? Yes, but we’re not optimising the efficiency of a single step. We’re optimising the whole value stream. If a step has a lot of spare capacity, this could be used to work on another product, but only if it doesn’t endanger the delivery of the first product.

Using Visual Management, the value stream tracks actual production rate regularly. The steps won’t run perfectly as clockwork, there will always be some variation. The production rate displays allow everybody to react (speed up, slow down a bit) to keep to the takt time. The takt time works as a metronome that synchronizes musicians.

Takt time isn’t (always) the drum beat

In Theory of Constraints, the Drum-Buffer-Rope system synchronizes the speed at which each step in production runs. The “Drum Beat” is the rhythm, the steady pace at which the slowest step (the bottleneck) runs. The rest of the system works to that beat. Again, no use producing faster than the bottleneck because we’ll only create more work in process.

The two concepts are quite similar and I sometimes confuse them. There’s one clear difference:

• takt time is customer-focused, outward looking
• drum beat is bottleneck focused, inward looking

If the customer is the constraint, a base (if not outspoken) premise of Lean, takt time equals the drum beat and drum-buffer-rope implements customer pull.

Takt time in software development

What is the equivalent of takt time in software development? If you’re Microsoft, you know approximately how many copies of Microsoft Office are bought every day. You could run your disk duplication and packaging plant at this takt time. But that’s not what I want to talk about.

Takt time = the rate at which you release a new product (version) to users

How often do you put new, valuable features in the hands of your users? Every day? Every week? Every month? Every quarter? Every year?

The logic of slow takt times or how to kill all your Agile teams with one simple decision

Most teams I work with, including Agile teams, have long release cycles. Long by my standards. Some of this is under control of the development team, but the release cycle is often dictated by other concerns. Often, operational teams (systems engineers, DBAs, support) reduce the number of releases.

Operational teams are often stressed, in fire-fighting mode and jerked around as projects miss deadlines and make last-minute changes. To reduce the load and ease the pressure, they reduce the number of releases. Fewer releases means more complex and error-prone releases, as more features are batched up in one release. These releases require more effort and have more issues. Fixing and patching those issues requires more work. Business people, under pressure to generate more value faster push harder to get features out of the door. Corners get cut, features get released under the guise of fixes. More work. The logical reaction is to reduce the number of releases again. Which makes the problem even worse. And so on.

Reducing the number of releases, increasing the overhead of releasing is the perfect way to demoralise and ultimately kill any Agile team. Why should we define short iterations and releases, if it takes so long to get something in production? Why should we collaborate tightly with customers if the software is outdated by the time it gets into the hands of users? Why should we focus on business value if potentially valuable features gather dust in an endless release process? We might as well switch to waterfall.

It doesn’t have to be this way. The first step is to regain the trust of the operational teams: release on time, deliver great quality code, involve operational teams in planning and retrospectives, treat members of operational teams (who are often involved in many projects) as members of your team: listen to them and optimise the whole value stream.

Once we’ve established trust and created one team, we can start to talk about improving and going faster.