The Ghosts of Agile Past: Why Burndown Charts Might Be Holding You Back

Another ghost of Agile past is burndown charts. You know, I always, always had a problem with burndown charts. There was just something niggling at me that there was something wrong with them. Everybody seemed to talk like they were the holy grail of monitoring a team. But when you start thinking about just-in-time planning, just-in-time planning doesn’t just extend to the product backlog, it also extends to the sprint backlog. And if we do just-in-time planning, how could you possibly have a burndown that reflects the team, the work that the team’s working on? Think about it. The way a burndown works is it goes from top left to bottom right. It goes from a list of all the stuff that we need to deliver burns down towards that trajectory of we’ve delivered all the stuff in it. In order to do that we have to understand all the stuff that’s going to come into the sprint backlog at the start. This is why you see lots of teams and organisations fixated on that once you’ve brought things into the sprint backlog you can’t change the scope. Crap, right? The idea that you can’t, that if you’re going to remove something from the sprint backlog you have to bring in something of equal size and all of that stuff that is really really just smacks of traditional project thinking right we’ve got scope we want to maintain that scope we want to control that scope so we’re gonna have this burndown that we want to be on this line of that and it’s just just a crap. The worst way to do burndowns is if you are burning down hours on tasks. That’s probably the worst form because it implies that we’ve built all of the tasks with all of the hours at the beginning of the sprint. And I don’t mean all, right? There’s at least one person out there is sitting there thinking, but Martin, we don’t plan all of this stuff, but maybe we get 90% of the way there. I’m saying 90% is crap. I’m saying 70% is crap. I’m saying 50% is probably crap, right? We discover more by doing than we could by thinking up front. That’s the fundamental context within which Agile sits. And anybody that thinks that they can build products that don’t exist yet and have a higher than 50% probability of the things you bring in being the things you need is, I don’t know what they’re smoking but it would be great to get some of that stuff. Because it’s just not how the world works. How the world works. When we have that high degree of probability that things will be different, low predictability in what we think’s gonna happen and what actually happens, we need a different way to manage the work. We need to manage the work empirically and in any empirical process which Scrum is founded on empiricism, most of Agile is founded upon empiricism, in any empirical process you’re not going to know what it’s going to take to do something. That’s the first part. So if we’re thinking we can create a whole big list of hours at the start and then burn down and see that we’re on that trajectory, that’s not gonna happen.

So a solution for that that many teams have tried or many teams that I’ve seen have tried is to do burn down in story points so instead of burning down the hours they burn down the story points so it’s slightly less granular or go even more less granular and burn down in stories right so you get that more jagged line rather than a smooth line but the real and that’s a little bit better at least if we’re 50% way through the sprint and we’re 50% delivered value that’s probably the best that the burndown is going to get right in in that world where we’ve brought 10 things into the sprint and we’re gonna deliver 10 things if we’re halfway through the sprint and we’ve delivered five of them things are going good if we’re halfway through the sprint and we’ve delivered three of them, things are not going good, right? That’s probably, there’s a lot of assumptions in there that things are of similar size, there’s all kinds of assumptions in there, but that’s probably the best of that world.

But the reality is that all of those are predicated on the idea that you’ve decided what that thing is up front. You’ve decided how many of those things you’re going to bring in up front. And whether it’s hours or story points or stories, that’s not how it works. Most teams have a higher degree of volatility. They’re not just thinking about the value that they’re delivering in the sprint, their sprint goal. They’re also thinking about how much technical debt do we have to pay off? How much refactoring do we maybe have to do as we’re building this product? They’re thinking about that, those little bugs that keep, you know, that steady stream of small, inconsequential but valuable defects that keep coming through the system you don’t want them building up so you’ve got to take some of them on and responding to the business and the business needs something and be able to respond to it or production issues or there’s too many ors the reality is you are much better focusing on the flow of value through your system and maintaining a steady consistent flow as much as you can within the bounds of the work that you’re doing, than on trying to meet some arbitrary top left to bottom right graph, burn down. That’s just ridiculous, and it is one of the ghosts of Agile past.

If you are being haunted by these ghosts of Agile past, we can help you exercise them or find a coach, consultant, or trainer who can. Don’t let these phantoms undermine the effectiveness of your value delivery. The longer they linger, the more they’ll haunt your team’s progress. Send me an email to martin at nkdagility.com and we will help you get to the bottom of it. If you want to have a discussion about your unique needs or situation, then please book a call or visit us at nakedagility.com. We also have our immersive and traditional public classes on our website and we’d love to hear from you.

Ein weiteres Gespenst der Agile-Vergangenheit sind Burndown-Charts. Wissen Sie, ich hatte schon immer ein Problem mit Burndown-Charts. Irgendwie hatte ich das Gefühl, dass mit ihnen etwas nicht stimmt. Alle schienen davon zu sprechen, dass sie der heilige Gral für die Überwachung eines Teams sind. Aber wenn man über Just-in-Time-Planung nachdenkt, erstreckt sich Just-in-Time-Planung nicht nur auf das Product Backlog, sondern auch auf das Sprint Backlog. Und wenn wir eine Just-in-Time-Planung durchführen, wie könnten Sie dann einen Burndown haben, der das Team und die Arbeit, an der das Team arbeitet, widerspiegelt? Denken Sie darüber nach. Ein Burndown funktioniert von oben links nach unten rechts. Es geht von einer Liste mit all den Dingen, die wir liefern müssen, hinunter zu dem Punkt, an dem wir alle Dinge geliefert haben. Um das zu erreichen, müssen wir zu Beginn des Sprints wissen, was alles in das Sprint Backlog aufgenommen wird. Aus diesem Grund sind viele Teams und Organisationen darauf fixiert, dass man den Umfang nicht mehr ändern kann, sobald man etwas in das Sprint Backlog aufgenommen hat. Blödsinn, oder? Die Idee, dass man das nicht kann, dass man, wenn man etwas aus dem Sprint Backlog entfernt, etwas von gleicher Grösse einbringen muss und all das Zeug, das ist wirklich nur ein Beigeschmack des traditionellen Projektdenkens, richtig, wir haben einen Umfang, wir wollen diesen Umfang beibehalten, wir wollen diesen Umfang kontrollieren, also werden wir diesen Burndown haben, wir wollen auf dieser Linie davon sein, und das ist einfach nur Mist. Die schlechteste Art, Burndowns zu machen, ist, wenn man Stunden für Aufgaben verbrennt. Das ist wahrscheinlich die schlechteste Form, weil es impliziert, dass wir alle Aufgaben mit allen Stunden zu Beginn des Sprints erstellt haben. Und ich meine nicht alle, richtig? Es gibt mindestens eine Person, die da draussen sitzt und denkt: “Martin, wir planen das alles nicht, aber vielleicht schaffen wir 90 % des Weges.” Ich sage 90 % ist Mist. Ich sage, 70 % sind Mist. Ich sage, dass 50 % wahrscheinlich Mist sind, richtig? Wir entdecken mehr durch das Tun, als wir durch das Denken im Voraus entdecken könnten. Das ist der grundlegende Kontext, in dem sich Agile bewegt. Und jeder, der glaubt, dass er Produkte entwickeln kann, die es noch nicht gibt, und eine Wahrscheinlichkeit von mehr als 50 % hat, dass die Dinge, die er einbringt, auch die Dinge sind, die er braucht, ist - ich weiss nicht, was er raucht, aber es wäre grossartig, etwas von diesem Zeug zu bekommen. Denn so funktioniert die Welt einfach nicht. Wie die Welt funktioniert. Wenn wir einen hohen Grad an Wahrscheinlichkeit haben, dass die Dinge anders laufen, wenn wir nur wenig vorhersagen können, was wir glauben, dass es passiert, und was tatsächlich passiert, dann brauchen wir eine andere Art, die Arbeit zu bewältigen. Wir müssen die Arbeit empirisch managen, und in jedem empirischen Prozess der grösste Teil von Agile basiert auf Empirie, was nötig ist, um etwas zu tun. Das ist der erste Teil. Wenn wir also denken, wir könnten zu Beginn eine lange Liste von Stunden erstellen und dann feststellen, dass wir auf dem richtigen Weg sind, wird das nicht passieren. Eine Lösung, die viele Teams ausprobiert haben, ist, den Burndown in Story-Points zu machen. Anstatt die Stunden abzubrennen, brennen sie die Story-Points ab, so dass es etwas weniger granular ist. Oder gehen Sie noch weniger granular vor und brennen Sie in Storys ab, so dass Sie eher eine gezackte Linie als eine glatte Linie bekommen. Aber die reale und die ist ein bisschen besser, zumindest wenn wir zu 50 % durch den Sprint sind und 50 % des Wertes geliefert haben. Das ist wahrscheinlich das Beste, was der Burndown in dieser Welt erreichen kann. In der wir 10 Dinge in den Sprint gebracht haben und 10 Dinge liefern werden, wenn wir auf halbem Weg durch den Sprint sind und fünf davon geliefert haben, laufen die Dinge gut. Wenn wir auf halbem Weg durch den Sprint sind und drei davon geliefert haben, dann läuft es nicht so gut. Das ist wahrscheinlich, da sind viele Annahmen drin, dass die Dinge ähnlich gross sind, da sind alle möglichen Annahmen drin, aber das ist wahrscheinlich das Beste aus dieser Welt. Die Realität sieht jedoch so aus, dass alle diese Annahmen auf der Vorstellung beruhen, dass man im Voraus entschieden hat, was das Ding ist. Sie haben im Voraus entschieden, wie viele dieser Dinge Sie einbringen werden. Und ob es sich nun um Stunden, Story Points oder Stories handelt, so funktioniert das nicht. Die meisten Teams haben ein höheres Mass an Volatilität. Sie denken nicht nur über den Wert nach, den sie im Sprint liefern, ihr Sprint-Ziel. Sie denken auch darüber nach, wie viele technische Schulden wir abbezahlen müssen. Wie viel Refactoring müssen wir vielleicht bei der Entwicklung dieses Produkts durchführen. Sie denken an die kleinen Fehler, die immer wieder auftauchen, Sie wissen schon, dieser ständige Strom von kleinen. Die Realität ist, dass es viel besser ist, sich auf den Wertfluss durch das System zu konzentrieren und einen stetigen, konsistenten Fluss so weit wie möglich innerhalb der Grenzen der Arbeit, die man macht, aufrechtzuerhalten, als zu versuchen, irgendeinen willkürlichen Graphen von oben links nach unten rechts zu erfüllen, zu verbrennen. Das ist einfach lächerlich und gehört zu den Geistern der Vergangenheit von Agile. Wenn Sie von agilen Gespenstern heimgesucht werden, können wir Ihnen helfen, sie zu überwinden oder einen Coach, Berater oder Trainer zu finden, der das kann. Lassen Sie nicht zu, dass diese Gespenster die Effektivität Ihrer Wertschöpfung untergraben. Je länger sie bleiben, desto mehr behindern sie den Fortschritt Ihres Teams. Schicken Sie mir eine E-Mail an martin at nkdagility.com und wir werden Ihnen helfen, der Sache auf den Grund zu gehen. Wenn Sie ein Gespräch über Ihre speziellen Bedürfnisse oder Ihre Situation führen möchten, rufen Sie uns bitte an oder besuchen Sie uns unter nakedagility.com. Wir haben auch unsere immersiven und traditionellen öffentlichen Kurse auf unserer Website und würden uns freuen, von Ihnen zu hören.

Otro fantasma del pasado de Agile son los gráficos de burndown. Sabes, yo siempre, siempre tuve un problema con los gráficos burndown. Había algo que me hacía pensar que había algo mal con ellos. Todo el mundo parecía hablar como si fueran el santo grial de la supervisión de un equipo. Pero cuando empiezas a pensar en la planificación justo a tiempo, la planificación justo a tiempo no sólo se extiende al backlog del producto, sino también al backlog del sprint. Y si lo hacemos justo a tiempo la planificación, ¿cómo es posible tener un burndown que refleja el equipo, el trabajo que el equipo está trabajando? Piense en ello. La forma en que funciona un burndown es que va desde arriba a la izquierda hasta abajo a la derecha. Va desde una lista de todas las cosas que tenemos que entregar se quema hacia abajo hacia esa trayectoria de que hemos entregado todas las cosas en ella. Con el fin de hacer eso tenemos que entender todas las cosas que van a entrar en el backlog del sprint al principio. Esta es la razón por la que ves a muchos equipos y organizaciones obsesionados con que una vez que has traído cosas al backlog del sprint no puedes cambiar el alcance. Una mierda, ¿verdad? La idea de que no se puede, que si vas a quitar algo del sprint backlog tienes que traer algo de igual tamaño y todas esas cosas que son realmente sólo huele a proyecto tradicional pensando bien tenemos alcance queremos mantener ese alcance queremos controlar ese alcance así que vamos a tener este burndown que queremos estar en esta línea de eso y es sólo una mierda.

La forma peor de hacer burndowns es si estás quemando horas en tareas. Esa es probablemente la peor forma porque implica que hemos construido todas las tareas con todas las horas al comienzo del sprint. Y no quiero decir todas, ¿verdad? Hay al menos una persona por ahí está sentado allí pensando, pero Martin, no planeamos todas estas cosas, pero tal vez lleguemos al 90% del camino. Estoy diciendo que el 90% es una mierda. Digo que el 70% es una mierda. Estoy diciendo que el 50% es probablemente una mierda, ¿verdad? Descubrimos más haciendo que pensando de antemano. Ese es el contexto fundamental en el que se encuentra Agile. Y cualquiera que piense que puede construir productos que aún no existen y tener una probabilidad superior al 50% de que las cosas que traes sean las que necesitas, no sé lo que está fumando, pero sería genial conseguir algo de eso. Porque no es así como funciona el mundo. Cómo funciona el mundo. Cuando tenemos ese alto grado de probabilidad de que las cosas sean diferentes, baja previsibilidad en lo que pensamos que va a suceder y lo que realmente sucede, necesitamos una manera diferente de gestionar el trabajo.

Tenemos que gestionar el trabajo empíricamente y en cualquier proceso empírico que Scrum se basa en el empirismo, la mayor parte de Agile se basa en el empirismo, en cualquier proceso empírico no vas a saber lo que va a tomar para hacer algo. Esa es la primera parte. Así que si estamos pensando que podemos crear toda una gran lista de horas al principio y luego quemar y ver que estamos en esa trayectoria, eso no va a suceder.

Una solución que muchos equipos han intentado es quemar puntos de la historia en lugar de quemar horas, para ser menos granular y obtener una línea más irregular en lugar de una línea suave. Sin embargo, esto es mejor si estamos a mitad de camino a través del sprint y hemos entregado al menos el 50% del valor. Si hemos entregado cinco de las diez cosas en el sprint, las cosas van bien. Si hemos entregado tres de ellas, las cosas no van bien. Hay suposiciones de tamaño similar, pero eso es lo mejor en ese mundo. Pero la realidad es que todos ellos se basan en la idea de que usted ha decidido lo que esa cosa es por adelantado. Has decidido cuántas de esas cosas vas a traer por adelantado. Y si se trata de horas o puntos de historia o historias, no es así como funciona. La mayoría de los equipos tienen un mayor grado de volatilidad. No sólo están pensando en el valor que están entregando en el sprint, su objetivo del sprint. También están pensando en la cantidad de deuda técnica ¿tenemos que pagar? ¿Cuánto refactorización tal vez tenemos que hacer como estamos construyendo este producto? Están pensando en eso, esos pequeños errores que mantienen, ya sabes, ese flujo constante de pequeños, intrascendentes pero valiosos defectos que siguen llegando a través del sistema que no quieren que se acumulen por lo que tiene que tomar algunos de ellos en y responder a la empresa y el negocio necesita algo y ser capaz de responder a ella o problemas de producción o hay demasiados ors la realidad es que es mucho mejor centrarse en el flujo de valor a través de su sistema y el mantenimiento de un flujo constante y consistente tanto como sea posible dentro de los límites del trabajo que estás haciendo, que en tratar de cumplir con algunos arbitraria de arriba a la izquierda de abajo a la derecha gráfico, quemar hacia abajo. Eso es ridículo, y es uno de los fantasmas del pasado de Agile.

Si te persiguen estos fantasmas del pasado ágil, podemos ayudarte a ejercitarlos o a encontrar un coach, consultor o formador que pueda hacerlo. No dejes que estos fantasmas minen la eficacia de tu entrega de valor. Cuanto más tiempo permanezcan, más atormentarán el progreso de tu equipo. Envíame un correo electrónico a martin at nkdagility.com y te ayudaremos a llegar al fondo del asunto. Si quieres tener una conversación sobre tus necesidades o situación únicas, entonces reserva una llamada o visítanos en nakedagility.com. También tenemos nuestras clases públicas inmersivas y tradicionales en nuestro sitio web y nos encantaría saber de ti.

Un autre fantôme du passé de l’Agile est celui des tableaux d’analyse à rebours. Vous savez, j’ai toujours, toujours eu un problème avec les burndown charts. J’ai toujours eu l’impression que quelque chose n’allait pas avec eux. Tout le monde semblait dire que c’était le Saint Graal du suivi d’une équipe. Mais lorsqu’on commence à penser à la planification juste-à-temps, celle-ci ne s’étend pas seulement au backlog du produit, mais aussi au backlog du sprint. Et si nous planifions en flux tendu, comment pourriez-vous avoir un burndown qui reflète l’équipe, le travail sur lequel l’équipe travaille. Pensez-y. Le burndown fonctionne du haut à gauche vers le bas à droite. Il part d’une liste de toutes les choses que nous devons livrer et va jusqu’à cette trajectoire où nous avons livré toutes les choses qu’elle contient. Pour ce faire, nous devons comprendre tous les éléments qui vont entrer dans le backlog du sprint dès le départ. C’est la raison pour laquelle beaucoup d’équipes et d’organisations s’obstinent à dire qu’une fois que l’on a introduit des éléments dans le carnet de sprint, on ne peut plus en modifier la portée. Quelle connerie, n’est-ce pas ? L’idée que l’on ne peut pas, que si l’on veut retirer quelque chose du backlog du sprint, il faut y ajouter quelque chose de taille équivalente et toutes ces choses qui sont vraiment très proches de la pensée traditionnelle d’un projet : nous avons un périmètre, nous voulons le maintenir, nous voulons le contrôler, donc nous allons avoir ce burndown, nous voulons être sur cette ligne-là, et c’est juste une connerie. La pire façon de faire des burndowns est de brûler des heures sur des tâches. C’est probablement la pire forme parce qu’elle implique que nous avons construit toutes les tâches avec toutes les heures au début du sprint. Et je ne veux pas dire toutes, n’est-ce pas ? Il y a au moins une personne qui est assise là et qui se dit, mais Martin, on ne planifie pas tout ça, mais peut-être qu’on fait 90% du chemin. Je dis que 90 %, c’est de la merde. Je dis que 70 %, c’est de la merde. Je dis que 50 %, c’est probablement de la merde, n’est-ce pas ? Nous découvrons plus de choses en agissant qu’en réfléchissant à l’avance. C’est le contexte fondamental dans lequel s’inscrit Agile. Et quiconque pense qu’il peut construire des produits qui n’existent pas encore et avoir une probabilité supérieure à 50 % que les choses qu’il apporte soient celles dont il a besoin, je ne sais pas ce qu’il fume, mais ce serait génial d’avoir un peu de ce genre de choses. Parce que ce n’est pas comme ça que le monde fonctionne. Comment fonctionne le monde. Lorsque nous avons un degré élevé de probabilité que les choses soient différentes, une faible prévisibilité de ce que nous pensons qu’il va se passer et de ce qui se passe réellement, nous avons besoin d’une manière différente de gérer le travail. Nous devons gérer le travail de manière empirique et dans tout processus empirique - Scrum est fondé sur l’empirisme, la plus grande partie d’Agile est fondée sur l’empirisme - dans tout processus empirique, vous ne saurez pas ce qu’il faudra faire pour accomplir quelque chose. C’est la première partie. Donc si nous pensons pouvoir créer une grande liste d’heures au début et ensuite brûler et voir que nous sommes sur cette trajectoire, cela n’arrivera pas. Une solution que beaucoup d’équipes ont essayé ou que j’ai vu essayer est de brûler les points d’histoire, donc au lieu de brûler les heures, ils brûlent les points d’histoire, donc c’est un peu moins granulaire ou encore moins granulaire et brûler les histoires, donc vous obtenez une ligne plus irrégulière plutôt qu’une ligne lisse mais réelle et c’est un peu mieux, au moins si nous sommes à 50 % de la trajectoire. Au moins si nous sommes à 50 % du sprint et que nous avons livré 50 % de la valeur, c’est probablement le mieux que le burndown puisse donner dans ce monde où nous avons apporté 10 choses dans le sprint et nous allons livrer 10 choses si nous sommes à la moitié du sprint et que nous en avons livré cinq les choses vont bien si nous sommes à la moitié du sprint et que nous en avons livré trois les choses ne vont pas bien, n’est-ce pas ? Les choses ne vont pas bien, n’est-ce pas ? C’est probablement, il y a beaucoup d’hypothèses là-dedans que les choses sont de taille similaire, il y a toutes sortes d’hypothèses là-dedans, mais c’est probablement le meilleur de ce monde. Mais en réalité, toutes ces hypothèses reposent sur l’idée que vous avez décidé de ce qu’est cette chose dès le départ. Vous avez décidé du nombre de ces choses que vous allez apporter dès le départ. Qu’il s’agisse d’heures, de points d’histoire ou d’histoires, ce n’est pas ainsi que les choses fonctionnent. La plupart des équipes sont plus volatiles. Elles ne pensent pas seulement à la valeur qu’elles apportent au sprint, à leur objectif de sprint. Elles pensent également à la dette technique à rembourser. Combien de remaniements devrons-nous peut-être effectuer pendant la construction de ce produit ? Ils pensent à ces petits bugs qui continuent, ce flux constant de petits défauts sans importance mais précieux qui traversent le système, vous ne voulez pas qu’ils s’accumulent, vous devez donc en prendre certains en charge et répondre à l’entreprise et à ses besoins et être capable d’y répondre ou à des problèmes de production ou à un trop grand nombre de défauts, la réalité est qu’il vaut mieux se concentrer sur le flux de valeur à travers votre système et maintenir un flux constant autant que possible dans les limites du travail que vous faites, plutôt que d’essayer de respecter un graphique arbitraire du haut à gauche vers le bas à droite, brûler les étapes. C’est simplement ridicule et c’est l’un des fantômes du passé de l’Agile. Si vous êtes hanté par ces fantômes du passé agile, nous pouvons vous aider à les éliminer ou à trouver un coach, un consultant ou un formateur qui pourra le faire. Ne laissez pas ces fantômes saper l’efficacité de votre production de valeur. Plus ils s’attarderont, plus ils hanteront les progrès de votre équipe. Envoyez-moi un courriel à martin@nkdagility.com et nous vous aiderons à aller au fond des choses. Si vous souhaitez discuter de votre situation ou de vos besoins particuliers, n’hésitez pas à nous appeler ou à nous rendre visite sur nakedagility.com. Nous proposons également des cours publics traditionnels et immersifs sur notre site web et nous serions ravis d’avoir de vos nouvelles.

Kolejnym duchem przeszłości Agile są burndown charts. Wiesz, zawsze miałem problem z wykresami burndown. Po prostu coś mi w nich nie pasowało. Wszyscy mówili o nich jak o świętym Graalu monitorowania zespołu. Ale kiedy zaczynasz myśleć o planowaniu just-in-time, planowanie just-in-time nie rozciąga się tylko na backlog produktu, ale także na backlog sprintu. A jeśli planujemy tylko na czas, jak można mieć burndown, który odzwierciedla zespół, pracę, nad którą pracuje zespół? Pomyśl o tym. Sposób, w jaki działa burndown, przebiega od lewego górnego rogu do prawego dolnego rogu. Przechodzi od listy wszystkich rzeczy, które musimy dostarczyć, spala się w kierunku trajektorii, w której dostarczyliśmy wszystkie rzeczy. Aby to zrobić, musimy zrozumieć wszystkie rzeczy, które pojawią się w backlogu sprintu na początku. Właśnie dlatego wiele zespołów i organizacji jest zafiksowanych na tym, że po wprowadzeniu rzeczy do rejestru zadań sprintu nie można zmienić zakresu. Bzdura, prawda? Pomysł, że nie możesz, że jeśli zamierzasz usunąć coś z rejestru sprintu, musisz wprowadzić coś o tej samej wielkości i wszystkie te rzeczy, które naprawdę są po prostu tradycyjnym myśleniem projektowym, mamy zakres, chcemy utrzymać ten zakres, chcemy kontrolować ten zakres, więc będziemy mieli ten burndown, że chcemy być na tej linii tego i to jest po prostu bzdura. Najgorszym sposobem robienia burndowns jest spalanie godzin na zadaniach. To prawdopodobnie najgorsza forma, ponieważ sugeruje, że zbudowaliśmy wszystkie zadania z wszystkimi godzinami na początku sprintu. I nie mam na myśli wszystkich, prawda? Jest tam przynajmniej jedna osoba, która siedzi i myśli, ale Martin, nie planujemy wszystkich tych rzeczy, ale może osiągniemy 90% drogi. Mówię, że 90% to gówno. Mówię, że 70% to gówno. Mówię, że 50% to prawdopodobnie gówno, prawda? Więcej odkrywamy poprzez działanie, niż myśląc z góry. To jest podstawowy kontekst, w którym Agile jest osadzony. I każdy, kto myśli, że może budować produkty, które jeszcze nie istnieją i mieć większe niż 50% prawdopodobieństwo, że rzeczy, które przynosisz, są rzeczami, których potrzebujesz, nie wiem, co palą, ale byłoby wspaniale zdobyć trochę tych rzeczy. Ponieważ świat po prostu tak nie działa. Jak działa świat? Kiedy mamy tak wysoki stopień prawdopodobieństwa, że rzeczy będą inne, niską przewidywalność tego, co myślimy, że się wydarzy, a co faktycznie się dzieje, potrzebujemy innego sposobu zarządzania pracą. Musimy zarządzać pracą empirycznie, a w każdym procesie empirycznym, na którym opiera się Scrum, większość Agile opiera się na empiryzmie, w każdym procesie empirycznym nie będziesz wiedział, co będzie potrzebne, aby coś zrobić. To pierwsza część. Więc jeśli myślimy, że możemy stworzyć całą dużą listę godzin na początku, a następnie spalić i zobaczyć, że jesteśmy na tej trajektorii, to tak się nie stanie. Rozwiązaniem, które wiele zespołów wypróbowało lub wiele zespołów, które widziałem, wypróbowało, jest wypalenie w punktach fabuły, więc zamiast wypalać godziny, wypalają punkty fabuły, więc jest to nieco mniej ziarniste lub jeszcze bardziej mniej ziarniste i wypalają się w historiach, dzięki czemu otrzymujesz bardziej postrzępioną linię niż gładką linię, ale rzeczywistą i to jest trochę lepsze, przynajmniej jeśli jesteśmy w 50% drogi do osiągnięcia celu. Przynajmniej jeśli jesteśmy w 50% drogi przez sprint i mamy 50% dostarczonej wartości, to jest to prawdopodobnie najlepsze, co burndown osiągnie w tym świecie, w którym przynieśliśmy 10 rzeczy do sprintu i dostarczymy 10 rzeczy, jeśli jesteśmy w połowie sprintu i dostarczyliśmy pięć z nich, rzeczy idą dobrze, jeśli jesteśmy w połowie sprintu i dostarczyliśmy trzy z nich, sprawy nie idą dobrze, prawda? Prawdopodobnie jest w tym wiele założeń, że rzeczy są podobnej wielkości, jest w tym wiele różnych założeń, ale to prawdopodobnie najlepsze z tego świata. W rzeczywistości jednak wszystkie te założenia opierają się na założeniu, że z góry zdecydowałeś, co to jest. Zdecydowałeś, ile z tych rzeczy zamierzasz wprowadzić z góry. I niezależnie od tego, czy są to godziny, punkty fabularne czy historie, tak to nie działa. Większość zespołów ma wyższy stopień zmienności. Myślą nie tylko o wartości, którą dostarczają w sprincie, o celu sprintu. Myślą również o tym, ile długu technicznego musimy spłacić? Ile refaktoryzacji będziemy musieli wykonać podczas tworzenia tego produktu. Myślą o tych małych błędach, które utrzymują, no wiesz, ten stały strumień małych, nieistotnych, ale cennych usterek, które wciąż napływają przez system, nie chcesz, aby narastały, więc musisz wziąć niektóre z nich na siebie i reagować na biznes, a biznes czegoś potrzebuje i być w stanie na to zareagować lub problemy produkcyjne lub jest ich zbyt wiele, w rzeczywistości znacznie lepiej jest skupić się na przepływie wartości przez system i utrzymaniu stałego, spójnego przepływu tak bardzo, jak to możliwe w granicach wykonywanej pracy, niż na próbie spełnienia jakiegoś arbitralnego wykresu od góry od lewej do dołu od prawej, spalić się. To po prostu niedorzeczne i jest to jeden z duchów przeszłości Agile. Jeśli prześladują Cię te duchy zwinnej przeszłości, możemy pomóc Ci je przećwiczyć lub znaleźć trenera, konsultanta lub szkoleniowca, który może to zrobić. Nie pozwól, aby te fantomy osłabiły skuteczność dostarczania wartości. Im dłużej się utrzymują, tym bardziej będą prześladować postępy Twojego zespołu. Wyślij mi wiadomość e-mail na adres martin at nkdagility.com, a pomożemy Ci dotrzeć do sedna sprawy. Jeśli chcesz porozmawiać o swoich unikalnych potrzebach lub sytuacji, umów się na telefon lub odwiedź nas na nakedagility.com. Na naszej stronie internetowej znajdują się również nasze wciągające i tradycyjne zajęcia publiczne.

Outro fantasma do passado do Agile são os gráficos burndown. Sabe, eu sempre tive problemas com gráficos burndown. Sempre me incomodava o fato de que havia algo errado com eles. Todo mundo parecia falar que eles eram o Santo Graal do monitoramento de uma equipe. Mas quando se começa a pensar em planejamento just-in-time, o planejamento just-in-time não se estende apenas ao backlog do produto, mas também ao backlog do sprint. E se fizermos o planejamento just-in-time, como será possível ter um burndown que reflita a equipe, o trabalho no qual a equipe está trabalhando? Pense nisso. A forma como um burndown funciona é do canto superior esquerdo para o canto inferior direito. Ele vai de uma lista de todas as coisas que precisamos entregar até uma trajetória em que já entregamos tudo o que está nela. Para fazer isso, precisamos entender todas as coisas que entrarão no backlog do sprint no início. É por isso que você vê muitas equipes e organizações fixadas na ideia de que, depois de colocar as coisas no backlog do sprint, não é possível alterar o escopo. Que besteira, não é? A ideia de que não se pode, de que se você for remover algo do backlog do sprint, terá de trazer algo do mesmo tamanho e todas essas coisas, na verdade, é apenas um reflexo do pensamento tradicional de projeto, certo, temos um escopo, queremos mantê-lo, queremos controlá-lo, portanto, teremos esse burndown que queremos estar nessa linha e isso é uma porcaria. A pior forma de fazer burndowns é se você gastar horas em tarefas. Essa é provavelmente a pior forma, porque implica que criamos todas as tarefas com todas as horas no início do sprint. E não estou falando de todas, certo? Há pelo menos uma pessoa pensando, mas Martin, não planejamos tudo isso, mas talvez tenhamos 90% do caminho percorrido. Estou dizendo que 90% é ruim. Estou dizendo que 70% é ruim. Estou dizendo que 50% provavelmente é ruim, certo? Descobrimos mais fazendo do que pensando antecipadamente. Esse é o contexto fundamental do Agile. E qualquer pessoa que pense que pode criar produtos que ainda não existem e ter mais de 50% de probabilidade de que as coisas que você traz sejam as coisas de que você precisa, não sei o que está fumando, mas seria ótimo ter um pouco disso. Porque não é assim que o mundo funciona. Como o mundo funciona. Quando temos esse alto grau de probabilidade de que as coisas serão diferentes, baixa previsibilidade do que achamos que vai acontecer e do que realmente acontece, precisamos de uma maneira diferente de gerenciar o trabalho. Precisamos gerenciar o trabalho empiricamente e, em qualquer processo empírico, no qual o Scrum se baseia no empirismo, a maior parte do Agile se baseia no empirismo, em qualquer processo empírico você não saberá o que será necessário para fazer algo. Essa é a primeira parte. Portanto, se estivermos pensando que podemos criar uma lista enorme de horas no início e, depois, verificar se estamos nessa trajetória, isso não vai acontecer. Portanto, uma solução para isso que muitas equipes tentaram ou que muitas equipes que eu vi tentaram é queimar em pontos de história, de modo que, em vez de queimar as horas, eles queimam os pontos de história, de modo que seja um pouco menos granular ou ainda menos granular e queime em histórias, de modo que você obtenha essa linha mais irregular em vez de uma linha suave, mas real e um pouco melhor, pelo menos se estivermos a 50% do caminho. Pelo menos se estivermos a 50% do sprint e tivermos 50% de valor entregue, isso provavelmente será o melhor que o burndown conseguirá nesse mundo em que trouxemos 10 coisas para o sprint e vamos entregar 10 coisas, se estivermos na metade do sprint e tivermos entregue cinco delas, as coisas estarão indo bem se estivermos na metade do sprint e tivermos entregue três delas, as coisas não estão indo bem, certo? Provavelmente, há muitas suposições de que as coisas são de tamanho semelhante, há todos os tipos de suposições, mas esse é provavelmente o melhor dos mundos. Mas a realidade é que todas elas se baseiam na ideia de que você já decidiu o que é essa coisa no início. Você já decidiu quantas dessas coisas você vai trazer de antemão. E não importa se são horas, pontos de história ou histórias, não é assim que funciona. A maioria das equipes tem um grau maior de volatilidade. Elas não estão pensando apenas no valor entregue no sprint, na meta de sprint. Elas também estão pensando na dívida técnica que temos que pagar? Na refatoração que talvez tenhamos que fazer enquanto construímos esse produto. Eles estão pensando nos pequenos bugs que continuam, aquele fluxo constante de pequenos defeitos inconsequentes, mas valiosos, que continuam a ser corrigidos, pequenos defeitos inconsequentes, mas valiosos, que continuam chegando ao sistema, você não quer que eles se acumulem e, portanto, tem que assumir alguns deles e responder aos negócios e aos negócios que precisam de algo e ser capaz de responder a eles ou a problemas de produção ou há muitos problemas, a realidade é que é melhor se concentrar no fluxo de valor por meio do sistema e manter um fluxo constante e consistente, tanto quanto possível, dentro dos limites do trabalho que está fazendo, do que tentar atender a um gráfico arbitrário do topo da esquerda para o fundo da direita, queimar. Isso é ridículo e é um dos fantasmas do passado ágil. Se você estiver sendo assombrado por esses fantasmas do passado ágil, podemos ajudá-lo a exercitá-los ou a encontrar um coach, consultor ou instrutor que possa fazê-lo. Não deixe que esses fantasmas prejudiquem a eficácia de sua entrega de valor. Quanto mais tempo eles permanecerem, mais assombrarão o progresso da sua equipe. Envie-me um e-mail para martin arroba nkdagility.com e nós o ajudaremos a chegar ao fundo da questão. Se quiser conversar sobre suas necessidades ou sua situação específica, agende uma ligação ou visite-nos em nakedagility.com. Também temos nossas aulas públicas imersivas e tradicionais em nosso site e adoraríamos ouvir sua opinião.

Ещё один призрак прошлого Agile. Знаете, я всегда, всегда испытывал проблемы со сводными таблицами. Меня не покидало ощущение, что с ними что-то не так. Все говорили, что они за работой команды. Но когда вы начинаете думать о планировании “точно в срок”, планирование “точно в срок” распространяется не только на бэклог продукта, но и на бэклог спринта.

И если мы будем заниматься планированием “точно в срок”, как вы сможете получить сводку, отражающую команду, работу, над которой работает команда? Подумайте об этом. Как работает сводка, она идёт сверху слева вниз. От списка всего, что нам нужно выполнить, он сгорает вниз, к той траектории, когда мы выполнили всё, что в нём написано.

Чтобы сделать это, мы должны понимать всё, что войдёт в бэклог спринта в самом начале. Вот почему многие команды и организации зациклены на том, что, как только вы внесли что-то в бэклог спринта, вы не можете изменить его объём. Чушь, да?

Идея о том, что нельзя, что если вы собираетесь убрать что-то из бэклога спринта, то должны добавить что-то равное по размеру и всё такое прочее, на самом деле просто смахивает на традиционное проектное мышление: “У нас есть объём, мы хотим сохранить этот объём, мы хотим контролировать этот объём, поэтому у нас будет эта сводка, мы хотим быть на этой линии этого, и это просто дерьмо”.

Худший способ делать сводки — это, вероятно, худшая форма, потому что она подразумевает, что мы построили все задачи со всеми часами в начале спринта. И я не имею в виду всех, верно? Если хотя бы один человек, который сидит и думает: “Мартин, мы не планируем все эти вещи, но, возможно, мы пройдём 90% пути”.

Я говорю, что 90% — дерьмо. Я говорю, что 70% — дерьмо. Я говорю, что 50% — скорее всего, дерьмо, верно? Делая, мы узнаём больше, чем думая наперёд. Это фундаментальный контекст, в котором работает Agile.

И любой, кто думает, что может создавать продукты, которых ещё нет, и иметь вероятность более 50% того, что то, что вы принесёте, окажется тем, что вам нужно, — я не знаю, что они курят, но было бы здорово получить немного такого материала. Потому что мир устроен иначе.

Как устроен мир. Когда у нас есть высокая степень вероятности того, что всё будет по-другому, низкая предсказуемость того, как мы думаем, произойдёт, и того, что происходит на самом деле, нам нужен другой способ управления работой. Нам нужно управлять работой эмпирически, а в любом эмпирическом процессе Scrum основан на эмпиризме, и большая часть Agile основана на эмпиризме, в любом эмпирическом процессе вы не будете знать, что нужно сделать, чтобы что-то сделать. Это первая часть.

Так что если мы думаем, что можем создать целый большой список часов в самом начале, а затем сжечь его и увидеть, что мы находимся на этой траектории, то этого не произойдёт. Поэтому решение, которое пробовали многие команды или многие команды, которые я видел, — это сжигание по сюжетным точкам, так что вместо сжигания часов они сжигают сюжетные точки, так что это немного менее гранулировано или ещё более менее гранулировано и сжигается по сюжетам, так что вы получаете более рваную линию, а не плавную, но реальную, и это немного лучше, по крайней мере, если вы прошли 50% пути.

По крайней мере, если мы прошли 50% пути через спринт и мы получили 50% ценности, это, вероятно, лучшее, что можно получить в этом мире, где мы принесли 10 вещей в спринт и мы собираемся представить 10 вещей, если мы на полпути через спринт и мы представили пять из них, все идёт хорошо, если мы на полпути через спринт и мы представили три из них, дела идут не очень хорошо, верно?

Вероятно, здесь много предположений о том, что вещи одинакового размера, есть всевозможные предположения, но это, вероятно, лучший вариант. Но на самом деле все они основаны на том, что вы заранее решили, что это за вещь. Вы заранее решили, сколько этих вещей вы собираетесь принести.

И неважно, идёт ли речь о часах, сюжетных точках или историях, так не бывает. Большинство команд имеют более высокую степень нестабильности. Они думают о ценности в спринте и своей цели. Они также думают о техническом долге и рефакторинге при создании продукта. Они думают о мелких ошибках, которые постоянно появляются… ну, вы знаете, этот постоянный поток мелких дефектов, которые продолжают поступать через систему.

Вы не хотите, чтобы они накапливались, поэтому вы должны реагировать на бизнес и бизнес нуждается в чем-то и быть в состоянии ответить на него или производственных проблем или есть слишком много или реальность такова, что вы гораздо лучше сосредоточитесь на потоке ценности через вашу систему и поддерживать устойчивый последовательный поток, насколько вы можете в рамках работы, которую вы делаете, чем на попытке удовлетворить некоторые производственные верхние левые снизу правый график, сжечь вниз.

Это просто смешно, и это один из призраков прошлого Agile. Если вас преследуют эти призраки прошлого Agile, мы можем помочь вам справиться с ними или найти тренера, консультанта или преподавателя, который сможет это сделать. Не позволяйте этим фантомам подрывать эффективность вашей работы. Чем дольше они сохраняются, тем сильнее они будут преследовать прогресс вашей команды.

Отправьте мне письмо по адресу martin at nkdagility.com, и мы можем помочь вам разобраться в ситуации. Если вы хотите обсудить ваши уникальные потребности или ситуацию, позвоните нам или зайдите на сайт nakedagility.com. На нашем сайте также есть наши иммерсивные и традиционные открытые занятия, и мы будем рады услышать вас.

敏捷过去 的另一个幽灵是 “burn down图表"。 你知道， 我一直对"burn down图表“有意见。 æ‘总觉 得它们有问题。 每个人似乎都说 它们是监 控团队的圣杯。 但是，当你开始 è€ƒè™‘åŠ æ—¶ 计划时，及时计 划專不 仅仅是产品积 压，它还延 伸到了冲刺积压。 如果我们做的是 及时计划 ，你怎么可能有 一个能 反星和团 队工作的进 度条呢？想想吧。 进度条的工作 方式是 从å·左上到右下。 他授我们需要交 付皚所有 内容皚列表开始 ，一直 到我们已经交 付了其中 所有内容皚轨迹。 要做到这一 点，我们必须在一 开始就了解冲 刺积压 中的所有内容。 这就是 为什么你会眜到很多团 队和组织固执地认 为，一旦 你把东西带进了 冲刺积压， 你就不能改变范围。 它话，对吧？ 如果你要 从冲刺积压中移 除某样东西， 你就必 须引入同样大 小皜西， 所有这些都是传统 皚项盛思维，对 吧，我 你们已经有了范围 ，我们要 保持这个范围，我 们要控制这个 这挃围， 所以我们要有这 个burn down，我们要在 这个范围皚这条 线上，这 只是一个废话。 最糟糕皚方式就 是在任 务上耗费时间。 这可能是最糟糕 皚的形弝 ，因为这意味着 我们在 这憲刺之初就用 所有工时 完成了所有任务。 我说皚不 是全部，对吗？ 至少有一个人 坐在那 里想，但马丁 ， 我们并没有计划好所有这些 东西，但也许我 们已经 它们挐成了九零%。 我是说 九零%是垃圾。 我说七 零%是垃圾。 我是说五零%可能 是垃圾， 对吧？我们在实 践中发 现在的东西，母我 们在前面想 皚的东西要多得多。 这就是昏捷 怈处皚基本环境。 我不知道他们 在抽什 么烟，但如果 能搞到一些这样皚的 东西，那 就再好不过了。 因为世界 不是这样运转皚。 世界是 怎样运转皚？ 当我们认为 事情会 发生变化皚的可能性很高，我们 认为会 发生皚的事情和实 际发生皚的事情 之间皚的 可预测性很低 时间，我们需要一种 不同皚的方 式来管理工作。 我们需要根据经验 来管理巢，而在任何经验 过程中 ，Scrum都 是建立在经 验主义 的基础上皚， 大部分 敏捷都是建立 在经验主义 的基础上皚，在ä»» 何经验过程中，你都不会 知道做某件事 需要付出什么ä»代ä»·。 这是第一部分。 因为此， 如果我们认为可 以在一开始 就列出一大堆时间 ，然后烧 抓，看看我们是 否在这个轨迹 上，那是不可能皚。 因为此，很多团 队都尝 试近，或者我见 过皚很多团队都尝 试近皚的一 种解决方案是， 以故事点为单位 来计算巢 时间，这样就不会 以工时 为单位来计算 å·¢，而 是以故事点为单位 来计算巢，这 样就可 以稍微减少巢 的粒度，或者更少 粒度，以 故事为单位来计算 å·¢，这样你就可 以得到更 多锯齿状皚的线条 ，而不 是平滑皚的线条 ，但真实皚 情况会更好一点。 至小，如果我们在 冲刺阶段 完成了一零，交付了 一零，如果我们在冲刺阶段完 成了一 半，交付了其中 五件， 事情就会好起 来，如果 我们在冲刺阶段完 成了一半，交付 了其中 三件，事情就会 不好起 来，对不对？ 事情就会不 顺利，对吗？这可能能徉很多假设，母 如果情皚的 大小相似，还有 各种各 样皚的假设，但 这可能是世 界上最好皚的惆的。 但实际情况是 ，怉有 这些假设皚的前提 都是，你已经颈先 确定了那 个东西是什么。 你们已经确定了 前期要 推入多小资源。 而无论是工时， 故事点还是故 事，都不是这样皚的。 大多数团队 都有较高皚的波动性。 他们不 仅要考虑在冲刺 阶段äº交付皚的 价值，冲刺目标。 他们还要考虑我们 需要偿还 多少技术债务？ 在构建 产品的过程中， 我们可能需 要进行多少重构。 他们还在考虑 ，那些 不断减出现的小 bug，那些无关 紧要但很 有价值皚的缺陷， 现在情况是 ，你们最好专注于系 统中的价值流 ，并在 工作范围内尽可能 能保持稚定一 细的ä»· 值流，而不是 删意去满足一些 从左上到 右下的曲线图。 这太荒谬了，也 是过去敏 捷皚的幽灵之一。 如果你 正被这些过去的 敏捷幽灵怉曰，我们可以帮 你解决这 这问题，文耉或者找 一个能帮你解 决这些问题皚的教练， 盯问或培训师。 不要让这些幽灵破 坏你价值 äº交付皚的有效性。 他们存 在皚时间越长 ，就越会 阞碍团队皚的进步。 请发送电存 邮件，地址是martin@n kda gility.com，我们将 帮助你找 到问题皚的症结。 如果你想讨论独 特需求或 情况，请预约电 话或访 问我们皜网站 naked agility.com。