A common practice I observe among agile teams is the reliance on burndown charts to gauge progress throughout a Sprint. However, I must confess, I view burndowns as a form of agile banditry. The premise of a burndown chart is that for it to move smoothly from the top left to the bottom right, you must have meticulously planned the entire Sprint upfront. But let’s be honest—when we’re developing products that don’t yet exist, this approach is fundamentally flawed.
The Reality of Product Development
In the world of product development, especially when venturing into uncharted territory, we face a plethora of unknowns. According to the Standish Group’s Chaos Report, a staggering 65% of what we build changes over the product’s lifecycle. Even more concerning is that only 30% of the features we develop are actually utilised by our customers. This data underscores a critical truth: we often know less than half of what we need to figure out as we progress.
Given this level of uncertainty, attempting to plan even the next 10-day Sprint is akin to spinning a fictional tale. Instead, I advocate for a more pragmatic approach.
Sprint Planning: Less is More
When you walk out of Sprint planning, your plan should be minimal yet sufficient to get started. Ideally, you should leave with just enough to kick off the Sprint—perhaps a mere 24 hours’ worth of work. This allows for flexibility and adaptability, enabling you to reassess and plan again every day.
- Key Takeaways for Sprint Planning:
- Start Small: Focus on what you need to begin, not on an exhaustive list of tasks.
- Daily Reassessment: Plan for the next 24 hours and adjust as necessary.
- Minimise Overhead: The less you have to manage, the more streamlined your process will be.
The Burndown Banditry
The issue with burndowns lies in their tendency to encourage excessive upfront planning. Imagine you have five developers and five stories, each with ten tasks. You end up with a mountain of tasks to manage. What happens on day two when you discover that half of your plan needs to change? You’re left scrambling to update a backlog that’s already out of date, diverting focus from delivering value.
Instead of getting bogged down in a sea of tasks, I recommend adopting a just-in-time, just-enough planning approach. This means having a clear, concise plan for your Sprint or product that allows for immediate action without the clutter of unnecessary tasks.
Embrace Continuous Flow
Let’s shift our focus from being agile bandits to fostering a continuous flow of value through our systems. If you find yourself ambushed by agile banditry in your organisation, my team at Naked Agility is here to help. We can assist you in navigating these challenges or connect you with a consultant who can provide the expertise you need.
If you found this discussion valuable, don’t forget to like and subscribe for more insights. Together, we can break free from the constraints of outdated practices and embrace a more effective, agile mindset.
A common thing that agile teams do is they use burndowns to figure out how things are going throughout the Sprint. I’ve got to say burndowns are agile banditry. The whole idea of burndowns, in order for a burndown to move from top left to bottom right in a reasonable linear fashion, you have to have planned the whole Sprint up front. Right? In order to have a project burned down or a product burn down moving from top left to bottom right, you have to have planned the whole product or project up front.
Hopefully, we can all be on the same page that if we’re doing, if we’re building products that don’t exist yet, right? We’re developing products that don’t exist, then there’s too much variance, too many surprises, too much complexity in what it is we’re doing to really plan the next six months’ worth of work. It’s always going to change more than we would like. And if we look at data from like the Standish Group, that do the chaos report, for example, you’ll find that 65% of things that we build change over the life of the product. And in fact, even worse than that, only 30% of the features that we do build are actually used by our customers. The rest are used little, if ever. Right? So that brings those two things together. We have a massive amount of unknowns in what we’re doing. It’s usually always more than 50%. So we know less than half of what we’re going to have to figure out along the way. And that means that being able to plan up front, even the next 10-day Sprint, is just a ridiculous exercise in making stuff up. A ridiculous exercise in telling a fictional story.
The reality is you should walk out of Sprint planning with no more than is needed to get started. That’s how big your plan should be. Getting started in the Sprint, how big should your plan be for your product? Enough to get started, right? Or enough to convince somebody to give you the money. That’s also, you know, you might need more for that. But that ability to get started is all you need. So you maybe walk out of Sprint planning with 24 hours’ worth of work. We’ve planned the next 24 hours because we’re going to get together every 24 hours and plan the next 24 hours after that. So we don’t really need more than the first 24 hours to get started. If we’re going to build a product, we don’t really need that much more than the first Sprint to get started. What of the backlog items we’re going to do maybe during that Sprint? We can come up with, you know, how far out into the future we do want to look. But you want it to be minimal but sufficient. You want to have less stuff to manage, less stuff in these things. That’s why burndowns are one of the reasons that you can’t tell what’s going on.
This is the banditry part of it. Being for bandits, it’s that if I plan the whole Sprint, right? And I’ve got, let’s say I’ve got five developers working on my product, and I’ve got five stories coming into the backlog, and each of those five stories has ten tasks that I’m going to write down as part of my plan. How many per person, right? How many tasks do I have at the end? I have lots and lots and lots and lots of tasks. What happens on day two of the Sprint when you figure out that your plan wasn’t that great and 50% of it needs to change because you figured out something new? It gets out of date. And the reason it gets out of date is because none of your developers, they want to focus on delivering the stuff because we’re under pressure to deliver the product, deliver the value. And yet they need to go and edit or manage these hundred things that are in the Sprint backlog. Right? Don’t have them there. You don’t need them. All you need is a just-in-time, just-enough plan either for the Sprint or a just-in-time, just-enough plan for your product in order to start getting started and get developing your product.
So don’t get stuck in that rut of too much planning up front, which is what a burndown forces you to do. Stop being a bunch of agile bandits and focus instead on continuous flow of value through your system. If you are being ambushed by agile bandits in your organisation, then my team at Naked Agility can help. Or we can help you find a consultant or expert who can. You can set up a no-obligation consultation using the links below. And don’t forget to like and subscribe if you enjoyed the video.
Agile Teams verwenden häufig Burndowns, um herauszufinden, wie sich die Dinge während des Sprints entwickeln. Ich muss sagen, dass Burndowns für Agile Teams obligatorisch sind. Die ganze Idee von Burndowns ist, dass man den gesamten Sprint im Voraus geplant haben muss, damit sich ein Burndown in einer vernünftigen linearen Weise von links oben nach rechts unten bewegen kann. Damit ein Projekt oder ein Produkt von links oben nach rechts unten abgearbeitet werden kann, muss das gesamte Produkt oder Projekt im Voraus geplant worden sein.
Wir sind uns hoffentlich alle einig: Wenn wir Produkte bauen, die es noch nicht gibt, wenn wir Produkte entwickeln, die es noch nicht gibt, dann gibt es zu viel Varianz, zu viele Überraschungen, zu viel Komplexität in dem, was wir tun, um die Arbeit der nächsten sechs Monate wirklich zu planen. Es wird sich immer mehr ändern, als uns lieb ist. Und wenn wir uns die Daten der Standish-Gruppe ansehen, die den Chaos-Report erstellt hat, werden Sie feststellen, dass sich 65 % der Dinge, die wir entwickeln, während der Lebensdauer des Produkts ändern. Und was noch schlimmer ist: Nur 30 % der Funktionen, die wir entwickeln, werden tatsächlich von unseren Kunden genutzt. Der Rest wird kaum oder gar nicht genutzt, richtig?
Das bringt also diese beiden Dinge zusammen. Wir haben eine riesige Menge an Unbekannten in dem, was wir tun. Normalerweise sind es immer mehr als 50 %. Wir wissen also weniger als die Hälfte dessen, was wir auf dem Weg dorthin herausfinden müssen. Und das bedeutet, dass eine Vorausplanung, selbst für den nächsten 10-Tage-Sprint, nur eine lächerliche Übung im Erfinden von Dingen ist, eine lächerliche Übung im Erzählen einer fiktiven Geschichte. Die Realität ist, dass Sie aus der Sprint-Planung mit nicht mehr herausgehen sollten, als Sie für den Start brauchen. So gross sollte Ihr Plan sein, wenn Sie mit dem Sprint beginnen. Wie umfangreich sollte Ihr Plan für Ihr Produkt sein? Genug, um anzufangen, richtig? Oder genug, um jemanden zu überzeugen, dir Geld zu geben. Dafür braucht man vielleicht auch mehr. Aber die Fähigkeit, anzufangen, ist alles, was du brauchst.
So kann es sein, dass Sie aus der Sprintplanung mit 24 Stunden Arbeit herausgehen. Wir haben die nächsten 24 Stunden geplant, weil wir uns alle 24 Stunden treffen und die nächsten 24 Stunden danach planen werden. Wir brauchen also nicht wirklich mehr als die ersten 24 Stunden, um loszulegen. Wenn wir ein Produkt entwickeln wollen, brauchen wir eigentlich nicht viel mehr als den ersten Sprint, um loszulegen. Was sind die Backlog-Elemente, die wir erledigen werden? Vielleicht können wir während dieses Sprints festlegen, wie weit wir in die Zukunft blicken wollen, aber es soll minimal, aber ausreichend sein. Sie wollen weniger Dinge verwalten, weniger Dinge in diesen Dingen.
Deshalb sind Burndowns einer der Gründe dafür, dass man nicht sagen kann, was vor sich geht. Das ist der Teil des Banditentums, dass es für Banditen ist. Es ist so, dass wenn ich den ganzen Sprint plane, richtig? Und ich habe, sagen wir mal, ich habe fünf Entwickler, die an meinem Produkt arbeiten, und ich habe fünf Stories, die ins Backlog kommen, und jede dieser fünf Stories hat 10 Aufgaben, die ich als Teil meines Plans aufschreiben werde. Wie viele pro Person, richtig? Wie viele Aufgaben habe ich am Ende? Ich habe viele, viele, viele, viele Aufgaben.
Was passiert am zweiten Tag des Sprints, wenn Sie herausfinden, dass Ihr Plan nicht so toll war und 50 % davon geändert werden müssen, weil Sie etwas Neues herausgefunden haben? Er wird veraltet. Der Grund dafür ist, dass keiner Ihrer Entwickler sich darauf konzentrieren will, die Sachen zu liefern, weil wir unter Druck stehen, das Produkt zu liefern, den Wert zu liefern, und trotzdem müssen sie gehen und diese hundert Dinge bearbeiten oder verwalten, die im Sprint Backlog stehen, richtig? Sie brauchen sie dort nicht zu haben. Sie brauchen sie nicht. Alles, was Sie brauchen, ist ein “Just-in-time”-Plan, ein “Just-enough”-Plan entweder für den Sprint oder ein “Just-in-time”-Plan für Ihr Produkt, damit Sie anfangen können, Ihr Produkt zu entwickeln, damit Sie nicht in diesem Trott von zu viel Planung im Voraus stecken bleiben, wozu ein Burndown Sie zwingt.
Hören Sie auf, ein Haufen agiler Banditen zu sein und konzentrieren Sie sich stattdessen auf einen kontinuierlichen Wertfluss durch Ihr System. Wenn Sie in Ihrer Organisation von agilen Banditen überfallen werden, dann kann mein Team von Naked Agility Ihnen helfen, oder wir können Ihnen helfen, einen Berater oder Experten zu finden, der das kann. Über die unten stehenden Links können Sie ein unverbindliches Beratungsgespräch vereinbaren. Und vergessen Sie nicht zu liken und zu abonnieren, wenn Ihnen das Video gefallen hat.
Una cosa común que los equipos ágiles hacen es utilizar burndowns para averiguar cómo van las cosas a lo largo del sprint. Tengo que decir, burndowns son Agile obligatorio. La idea de los burndowns, para que un burndown se mueva de arriba a la izquierda a abajo a la derecha de una manera lineal razonable, tienes que haber planeado todo el sprint por adelantado.
Con el fin de tener un proyecto quemado o un producto quemado, moviéndose de arriba a la izquierda a abajo a la derecha, usted tiene que haber planeado todo el producto o proyecto por adelantado. Con suerte, todos podemos estar en la misma página que si estamos construyendo productos que aún no existen, estamos desarrollando productos que no existen, entonces hay demasiada variación, demasiadas sorpresas, demasiada complejidad en lo que estamos haciendo para realmente planificar los próximos seis meses de trabajo. Siempre va a cambiar más de lo que nos gustaría.
Y si nos fijamos en los datos del grupo Standish, que hacen el informe del caos, por ejemplo, se encuentra que el 65% de las cosas que construimos cambian durante la vida del producto. Y de hecho, incluso peor que eso, sólo el 30% de las características que construimos son realmente utilizadas por nuestros clientes. El resto se utiliza poco o nunca, ¿verdad? Así que unir esas dos cosas. Tenemos una enorme cantidad de incógnitas en lo que estamos haciendo. Por lo general, siempre es más del 50%. Así que sabemos menos de la mitad de lo que vamos a tener que averiguar en el camino.
Y eso significa que ser capaz de planificar por adelantado, incluso el próximo sprint de 10 días, es sólo un ridículo ejercicio de inventar cosas, ridículo ejercicio de contar una historia ficticia. La realidad es que usted debe salir de la planificación de sprint con no más de lo necesario para empezar. Así de grande debe ser tu plan para empezar el sprint. ¿Cómo de grande debe ser tu plan para tu producto? Suficiente para empezar, ¿verdad? O suficiente para convencer a alguien de que te dé el dinero. Eso es también, ya sabes, es posible que necesites más para eso. Pero la capacidad de empezar es todo lo que necesitas.
Así que tal vez salgas de la planificación del sprint con 24 horas de trabajo. Hemos planeado las próximas 24 horas porque vamos a reunirnos cada 24 horas y planificar las próximas 24 horas después de eso. Así que realmente no necesitamos más que las primeras 24 horas para empezar. Si vamos a construir un producto, realmente no necesitamos mucho más que el primer sprint para empezar. ¿Cuáles son los elementos del backlog que vamos a hacer? Tal vez durante ese sprint, podemos llegar a, ya sabes, qué tan lejos en el futuro queremos mirar, pero quieres que sea mínimo, pero suficiente.
Quieres tener menos cosas que gestionar, menos cosas en estas cosas. Es por eso que los burndowns son una de las razones por las que no se puede saber lo que está pasando. Esta es la parte de que sea para bandidos. Es que si yo planifico todo el sprint, ¿no? Y tengo, digamos que tengo cinco desarrolladores trabajando en mi producto, y tengo cinco historias que entran en el backlog, y cada una de esas cinco historias tiene 10 tareas que voy a escribir como parte de mi plan.
¿Cuántas por persona? ¿Cuántas tareas tengo al final? Tengo muchas, muchas, muchas tareas. ¿Qué pasa el segundo día del sprint cuando te das cuenta de que tu plan no era tan bueno y el 50% de él tiene que cambiar porque has descubierto algo nuevo? Se vuelve obsoleto. La razón de su desactualización es que ninguno de sus desarrolladores, que quieren centrarse en la entrega de las cosas debido a la presión para entregar el producto, entregar el valor, y sin embargo tienen que editar o gestionar estos cientos de cosas en el Sprint backlog, ¿verdad? No las tengas ahí. Usted no los necesita.
Todo lo que necesitas es un plan justo a tiempo, justo lo suficiente, ya sea para el sprint o ajustar a tiempo el plan justo lo suficiente para su producto con el fin de empezar a empezar y empezar a desarrollar su producto para no quedarse atascado en la rutina de demasiada planificación por adelantado, que es lo que un burndown te obliga a hacer. Deja de ser un puñado de bandidos ágiles y céntrate en cambio en el flujo continuo de valor a través de tu sistema.
Si usted está siendo emboscado por bandidos ágiles en su organización, entonces mi equipo en Naked Agility puede ayudar, o podemos ayudarle a encontrar un consultor o experto que pueda. Puede concertar una consulta sin compromiso a través de los siguientes enlaces. Y no se olvide de gustar y suscribirse si te gustó el video.
Les équipes Agile utilisent couramment des bilans pour déterminer comment les choses se déroulent au cours du sprint. Je dois dire que les burndowns sont obligatoires dans la méthode Agile. Pour qu’un burndown se déplace d’en haut à gauche vers en bas à droite de manière linéaire et raisonnable, il faut avoir planifié tout le sprint à l’avance.
Pour qu’un projet ou un produit soit brûlé, en passant du haut à gauche au bas à droite, il faut avoir planifié l’ensemble du produit ou du projet en amont. Si nous construisons des produits qui n’existent pas encore, si nous développons des produits qui n’existent pas encore, alors il y a trop de variations, trop de surprises, trop de complexité dans ce que nous faisons pour vraiment planifier le travail des six prochains mois. Il y aura toujours plus de changements que nous ne le souhaiterions.
Si nous examinons les données du groupe Standish, qui rédige le rapport sur le chaos, par exemple, nous constatons que 65 % des choses que nous construisons changent au cours de la durée de vie du produit. Et en fait, pire encore, seulement 30 % des fonctionnalités que nous créons sont réellement utilisées par nos clients. Le reste n’est que peu ou pas utilisé, n’est-ce pas ? Ces deux éléments se rejoignent donc. Nous avons une quantité massive d’inconnues dans ce que nous faisons. En général, c’est toujours plus de 50 %. Nous connaissons donc moins de la moitié de ce que nous allons devoir découvrir en cours de route.
Cela signifie qu’être capable de planifier à l’avance, même le prochain sprint de 10 jours, n’est qu’un exercice ridicule d’invention, un exercice ridicule de narration d’une histoire fictive. La réalité est que vous devriez sortir de la planification du sprint avec pas plus que ce qui est nécessaire pour démarrer. C’est la taille que doit avoir votre plan pour démarrer le sprint. Quelle doit être la taille de votre plan pour votre produit ? Assez pour démarrer, n’est-ce pas ? Ou assez pour convaincre quelqu’un de vous donner de l’argent. Il se peut que vous ayez besoin de plus pour cela. Mais la capacité de démarrer est tout ce dont vous avez besoin.
Ainsi, vous sortez peut-être de la planification du sprint avec 24 heures de travail. Nous avons planifié les 24 prochaines heures parce que nous allons nous réunir toutes les 24 heures et planifier les 24 heures suivantes. Nous n’avons donc pas besoin de plus que les premières 24 heures pour commencer. Si nous voulons construire un produit, nous n’avons pas besoin de beaucoup plus que le premier sprint pour commencer. Quels sont les éléments du carnet de commandes que nous allons réaliser ? Au cours de ce sprint, nous pourrons peut-être déterminer jusqu’où nous voulons aller dans l’avenir, mais il faut que ce soit minimal, mais suffisant.
Vous voulez avoir moins de choses à gérer, moins de choses dans ces choses. C’est la raison pour laquelle les burndowns sont l’une des raisons pour lesquelles on ne peut pas savoir ce qui se passe. C’est l’aspect banditisme qui fait que c’est pour les bandits. C’est que si je planifie tout le sprint, n’est-ce pas ? Disons que j’ai cinq développeurs qui travaillent sur mon produit, que j’ai cinq histoires qui arrivent dans le backlog, et que chacune de ces cinq histoires a dix tâches que je vais écrire dans mon plan.
Combien de tâches par personne ? Combien de tâches me reste-t-il à la fin ? J’ai beaucoup, beaucoup, beaucoup, beaucoup de tâches. Que se passe-t-il le deuxième jour du sprint lorsque vous vous rendez compte que votre plan n’était pas très bon et que 50 % de celui-ci doit être modifié parce que vous avez découvert quelque chose de nouveau ? Il devient obsolète. La raison est qu’aucun de vos développeurs ne veut se concentrer sur la livraison du produit, car nous sommes sous pression pour livrer la valeur. Pourtant, ils doivent éditer ou gérer les nombreuses tâches du carnet de commandes du sprint, n’est-ce pas ? Ne les mettez pas là. Vous n’en avez pas besoin.
Tout ce dont vous avez besoin, c’est d’un plan juste à temps, juste assez pour le sprint ou d’un plan juste assez pour votre produit afin de pouvoir commencer à développer votre produit, alors ne restez pas coincé dans cette ornière de trop de planification à l’avance, ce qu’un burndown vous oblige à faire. Cessez d’être une bande de bandits agiles et concentrez-vous plutôt sur le flux continu de valeur à travers votre système.
Si vous êtes pris en embuscade par des bandits agiles dans votre organisation, mon équipe de Naked Agility peut vous aider, ou nous pouvons vous aider à trouver un consultant ou un expert qui peut le faire. Vous pouvez organiser une consultation sans engagement en utilisant les liens ci-dessous. Et n’oubliez pas d’aimer et de vous abonner si vous avez apprécié la vidéo.
ã¢ã¸ã£ã¤ã«ãã¼ ã ããã ãããã¨ã¯ã ãã¼ã³ã㦠ã³ã使 ã£ã¦ã¹ã㪠ã³ãå
¨ä½ã®ç¶æ³ ãææ¡ ãããã¨ã ã ãã¼ã³ ãã¦ã³ã¯ã¢ ã¸ã£ã¤ã« ã§ã¯å¿
é ã ã ãã¼ã³ ãã¦ã³ã®å
¨ ä½çãªè ãæ¹ã¨ãã¦ã ãã¼ã³ãã¦ã³ ãå·¦ä¸ ããå³ä¸ã¸ ã¨åççãªç·å½¢ ã§ç§»åã ãããã«ã¯ã ã¹ããªã³ ãå
¨ä½ãåã㣠ã¦è¨ç»ã㦠ããå¿
è¦ãããã ãã¼ã³ãã¦ã³ã ãããã ã¸ã§ã¯ãã製 åãå·¦ ä¸ããå³ä¸ ã«ç§»åã ããããã«ã¯ã 製åããã ã¸ã§ã¯ ãå
¨ä½ãå ãã£ã¦è¨ç»ã ãªãã ã°ãããªãã åå¨ã㪠ã製åãä½ãã åå¨ã ãã製åãé çºãã¦ã ãã®ã§ããã°ã 次ã®å
ã¶æåã® ä»äºãè¨ ç»ããã«ã¯ã 多ããããã ããã ãããããã ç§ãã¡ã æã以ä¸ã«ã 常ã«å¤åã ããã®ãªã®ã ã ããã°ã ã¹ã¿ã³ãã£ãã· ã¥ã»ã° ã«ã¼ãã®ãªãª ã¹ã»ã¬ ãã¼ãã®ã ããªãã¼ ã¿ãè¦ãã¨ã ç§ãã¡ãä½ã ãã®ã® å
äºï¼
ã¯ã 製å寿 å½ã®éã«å¤å ããã㨠ããããã¾ãã ããã« æªããã¨ã«ã ç§ãã¡ãæ§ç¯ ããæ© è½ã®ãã¡ã ããã顧客ã«ä½¿ãã ããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããã
Powszechną rzeczą, którą robią zespoły Agile, jest używanie burndowns, aby dowiedzieć się, jak sprawy mają się w trakcie sprintu. Muszę powiedzieć, że burndowns są obowiązkowe w Agile. Cała idea burndownów polega na tym, że aby burndown przesuwał się od lewego górnego rogu do prawego dolnego rogu w rozsądny liniowy sposób, musisz wcześniej zaplanować cały sprint.
Aby spalić projekt lub produkt, przesuwając się od lewego górnego rogu do prawego dolnego rogu, trzeba wcześniej zaplanować cały produkt lub projekt. Miejmy nadzieję, że wszyscy zgodzimy się co do tego, że jeśli tworzymy produkty, które jeszcze nie istnieją, rozwijamy produkty, które jeszcze nie istnieją, to istnieje zbyt duża zmienność, zbyt wiele niespodzianek, zbyt duża złożoność tego, co robimy, aby naprawdę zaplanować pracę na następne sześć miesięcy. To zawsze będzie się zmieniać bardziej, niż byśmy chcieli.
A jeśli spojrzymy na dane z grupy Standish, która przygotowuje na przykład raport chaosu, okaże się, że 65% rzeczy, które budujemy, zmienia się w trakcie życia produktu. Co gorsza, tylko 30% funkcji, które tworzymy, jest faktycznie wykorzystywanych przez naszych klientów. Reszta jest używana rzadko, jeśli w ogóle, prawda? Tak więc te dwie rzeczy łączą się ze sobą. Mamy ogromną ilość niewiadomych w tym, co robimy. Zwykle jest to ponad 50%. Wiemy więc mniej niż połowę tego, co będziemy musieli wymyślić po drodze.
Oznacza to, że planowanie z wyprzedzeniem, nawet kolejnego 10-dniowego sprintu, jest po prostu śmiesznym ćwiczeniem w wymyślaniu rzeczy, śmiesznym ćwiczeniem w opowiadaniu fikcyjnej historii. Rzeczywistość jest taka, że powinieneś wyjść z planowania sprintu z nie więcej niż jest to potrzebne do rozpoczęcia pracy. Tak duży powinien być plan na początek sprintu. Jak duży powinien być plan dla produktu? Wystarczająco, aby zacząć, prawda? Lub wystarczająco dużo, aby przekonać kogoś, by dał ci pieniądze. Do tego też możesz potrzebować więcej. Ale zdolność do rozpoczęcia to wszystko, czego potrzebujesz.
Możesz więc wyjść z planowania sprintu z 24 godzinami pracy. Zaplanowaliśmy następne 24 godziny, ponieważ będziemy spotykać się co 24 godziny i planować kolejne 24 godziny. Więc tak naprawdę nie potrzebujemy więcej niż pierwsze 24 godziny, aby zacząć. Jeśli zamierzamy zbudować produkt, tak naprawdę nie potrzebujemy więcej niż pierwszego sprintu, aby zacząć. Jakie elementy zaległości zamierzamy wykonać? Być może podczas tego sprintu będziemy w stanie wymyślić, jak daleko w przyszłość chcemy spojrzeć, ale chcemy, aby była ona minimalna, ale wystarczająca.
Chcesz mieć mniej rzeczy do zarządzania, mniej rzeczy w tych rzeczach. Właśnie dlatego burndowns są jednym z powodów, dla których nie można powiedzieć, co się dzieje. To jest ta bandycka część tego, że jest dla bandytów. Chodzi o to, że jeśli zaplanuję cały sprint, prawda? I mam, powiedzmy, pięciu programistów pracujących nad moim produktem, i mam pięć historyjek wchodzących do backlogu, a każda z tych pięciu historyjek ma 10 zadań, które zamierzam zapisać jako część mojego planu. Ile zadań przypada na osobę, prawda? Ile zadań mam na koniec? Mam wiele, wiele, wiele i wiele zadań.
Co się dzieje w drugim dniu sprintu, kiedy okazuje się, że twój plan nie był taki świetny i 50% z niego trzeba zmienić, ponieważ odkryłeś coś nowego? Plan przestaje być aktualny. Powodem tego jest brak skupienia programistów na dostarczaniu rzeczy, ponieważ jesteśmy pod presją dostarczenia produktu i wartości, mimo że muszą jeszcze edytować lub zarządzać setkami rzeczy w rejestrze sprintu, prawda? Ich tam nie ma. Nie potrzebujesz ich. Wszystko, czego potrzebujesz, to plan just-in-time, just-enough albo dla sprintu, albo dostosowany w czasie, wystarczający plan dla twojego produktu, aby zacząć i rozwijać swój produkt, więc nie utknij w tej koleinie zbytniego planowania z góry, do czego zmusza cię burndown.
Przestań być bandą zwinnych bandytów i zamiast tego skup się na ciągłym przepływie wartości przez system. Jeśli w Twojej organizacji grasują bandyci Agile, to mój zespół w Naked Agility może Ci pomóc, lub możemy pomóc Ci znaleźć konsultanta lub eksperta, który może to zrobić. Możesz umówić się na niezobowiązującą konsultację, korzystając z poniższych linków. I nie zapomnij polubić i zasubskrybować, jeśli podobał Ci się ten film.
Обычно Agile-команды используют сводки, чтобы выяснить, как идут дела в течение спринта. Должен сказать, что сводки обязательный элемент Agile. Вся идея сводок заключается в том, что для того, чтобы сводка двигалась от верхнего левого угла к нижнему правому в разумной линейной манере, вы должны были заранее спланировать весь спринт. Чтобы проект сгорел или продукт сгорел, двигаясь от левого верхнего края к правому нижнему, вы должны были спланировать весь продукт или проект заранее.
Надеюсь, все будем на одной волне: если создаём продукты, которых ещё нет, разрабатываем продукты, которых ещё нет, то в том, что делаем, слишком много разброса, слишком много сюрпризов, слишком много сложности, чтобы действительно планировать работу на ближайшие шесть месяцев. Она всегда будет меняться чаще, чем хотелось бы.
И если посмотрим на данные группы Standish, которые составляют отчёт о хаосе, то обнаружим, что 65% вещей, которые создаём, меняются в течение жизни продукта. И, что ещё хуже, только 30% функций, которые создаём, действительно используются нашими клиентами. Остальные используются редко, если вообще используются, верно? Таким образом, эти две вещи объединяются.
У нас огромное количество неизвестных в том, что делаем. Обычно это всегда больше 50%. То есть знаем меньше половины того, что предстоит выяснить по ходу дела. А это значит, что возможность заранее планировать даже следующий 10-дневный спринт нелепое упражнение в рассказывавании выдуманной истории. Реальность такова, что вы должны выходить из планирования спринта, имея только необходимое для начала работы.
Вот насколько должен быть ваш план, чтобы начинать спринт. Насколько должен быть план для вашего продукта? Достаточным для начала работы, верно? Или достаточно, чтобы убедить кого-то дать вам деньги. Для этого тоже, знаете ли, может понадобиться больше. Но способность начать - это всё, что вам нужно. Так что, возможно, вы выйдете из планирования спринта с 24 часами работы.
Мы спланировали следующие 24 часа, потому что мы будем собираться каждые 24 часа и планировать следующие 24 часа после этого. Так что нам не нужно больше, чем первые 24 часа, чтобы начинать работу. Если создаём продукт, нам нужен только первый спринт.
Какие пункты бэклога делаем? Возможно, во время спринта придумываем, как далеко заглянуть в будущее, но хотим, чтобы оно было минимальным, но достаточным. Хотим иметь меньше вещей, которыми нужно управлять, меньше вещей в этих вещах. Поэтому срывы - это часть бандитизма для бандитов.
Если я планирую весь спринт, верно? И у меня есть, допустим, пять разработчиков, которые работают над моим продуктом, и у меня есть пять историй, которые попадают в бэклог, и у каждой из этих пяти историй есть 10 задач, которые я собираюсь записать как часть моего плана. Сколько их приходит на одного человека, верно? Сколько задач у меня будет в конце? У меня много, много, много и много задач.
Что происходит на второй день спринта, когда вы понимаете, что ваш план был не так уж хорош и 50% его нужно изменить, потому что вы придумали что-то новое. Он устаревает. Причина его устаревания заключается в том, что никто из ваших разработчиков не хочет сосредоточиться на создании продукта, потому что мы находимся под давлением, чтобы представить продукт, представить ценность, и всё же им нужно идти и редактировать или управлять этими сотнями вещей, которые находятся в бэклоге спринта, верно? Не держите их там. Они вам не нужны.
Всё, что вам нужно, - это своевременный, достаточный план либо для спринта, либо своевременный, достаточный план для вашего продукта, чтобы начинать разработку продукта, чтобы не застрять в этой колее слишком большого планирования наперёд, что и заставляет вас делать burndown. Перестаньте быть кучкой agile-бандитов и вместо этого сосредоточьтесь на непрерывном потоке ценности через вашу систему.
Если в вашей организации Agile-бандиты устроили засады, моя команда в Naked Agility может помочь, или мы можем помочь вам найти консультанта или эксперта, который сможет это сделать. Вы можете назначить консультацию без обязательств, воспользовавшись ссылками ниже. И не забудьте поставить лайк и подписаться, если вам понравилось это видео.
