The Pitfalls of Routine Agile Questions: Avoiding the Ghosts of Agile Past

Published on
4 minute read

In the world of Agile, we often hear about the famous “three questions” used during the daily Scrum or retrospective sessions:

  • What did I do yesterday?

  • What am I doing today?

  • What’s blocking me?

These questions are a staple in Agile ceremonies, providing a framework for team discussions. But here’s the reality: while there’s nothing inherently wrong with these questions, when they become the sole purpose of your meetings, it leads to dysfunctional behavior. This blog explores how these Agile routines can quickly turn into “ghosts of Agile past” and why focusing on value is a better approach.

The Ghosts of Agile Past: The Danger of Routine Questions 👻

You’ve probably seen it before: a Scrum team gathers for the daily Scrum or a retrospective, and the meeting turns into a checklist of the three questions. Each team member goes into autopilot, simply answering the questions without giving it much thought.

The problem arises when these three questions become the primary focus of the meeting. Here’s what often happens:

  • Team members mechanically answer the questions without reflection.

  • The Scrum Master (or worse, the project manager) jots down the answers to update a project plan.

  • The real purpose of the daily Scrum – to focus on progress towards the sprint goal – gets lost.

⚠️ Warning: When your Agile ceremonies become rote procedures, your team risks losing sight of the real goal: delivering value.

Shifting Focus to Value and Outcomes 🎯

So, how do we steer away from these ghosts of the past? By shifting the focus to value. Rather than rigidly following the three questions, Scrum teams should emphasize the progress toward delivering value.

Here’s how you can do it:

  • Focus on the sprint goal: What is the most critical value we need to deliver, and how are we progressing toward that?

  • Skip the unnecessary updates: If Bob has been working on the same task for three days, there’s no need to hear the same update every day.

  • Collaborate on blockers: If several people are working on the same task, only one person needs to provide the update. What matters is the progress the team is making as a group.

Key Takeaways 📝

  • Focus on value, not individual updates.

  • Reduce redundancy: one update per group working on the same item.

  • Use daily Scrums to monitor progress toward the sprint goal.

Enhancing Meeting Efficiency: Ban the Banana Peel 🍌

A fun analogy that many Agile practitioners use is the banana peel visual. Imagine a Scrum board with sticky notes representing work items. Next to each note is a banana peel. The longer the peel sits, the browner it gets, and the more fruit flies gather around it. The same goes for tasks that stay stuck on your board: the longer they linger, the harder they are to complete.

Here’s why this happens:

  • Work items that are stuck for too long are more likely to stay stuck.

  • Tasks become exponentially harder to finish as they age.

  • Without clear guidelines, tasks may sit until the end of the sprint, at which point they are either incomplete or deprioritized.

This visual might seem silly, but it highlights a crucial point: if your team doesn’t actively manage tasks that have been on the board for too long, those items become bottlenecks.

How to Avoid Task Bottlenecks 🚧

  • Use metrics like work item aging to track how long tasks have been on the board.

  • Establish clear rules for handling old tasks: don’t let them rot!

  • Review which tasks haven’t moved during the daily Scrum and decide as a team how to tackle them.

Overcoming Outdated Agile Practices 🚀

Agile practices, like anything else, evolve over time. The three questions served their purpose in the past, but as teams and workflows become more sophisticated, sticking to these routines can hinder your team’s progress.

Here’s how you can overcome the ghosts of Agile past:

  • Focus on value delivery: Make sure your daily Scrums and retrospectives are centered on delivering value, not just answering routine questions.

  • Involve the whole team: Ensure that the team is collectively working toward a common goal and not just providing individual status updates.

  • Adapt and evolve: Don’t be afraid to modify your Agile ceremonies if they no longer serve the team’s needs.

Conclusion: Exorcise the Ghosts of Agile Past 👻

If your Agile practices are haunted by the ghosts of the past, it’s time to rethink your approach. The three questions may have been helpful once, but now it’s time to focus on value delivery and continuous improvement.

Remember:

  • Rote routines can lead to dysfunctional behavior.

  • Keep the focus on progress towards goals and value.

  • Manage old tasks before they become bottlenecks.

If your team is struggling with outdated practices, don’t let them haunt you. Reach out to a Scrum trainer or Agile coach who can help exorcise those phantoms. We’d be happy to assist you on your journey towards a more effective Agile process.

One of the ghosts of agile past is dogma. We’ve all run into those dogmatic folks that try and pursue an idea irrelevant of the data and the experience of the people around them. We need to kick those folks to the curb. I usually, I can be— not dogmatic is the wrong word— almost 100% of the time when I’m working with teams, I’m pragmatic. But I can also be pedantic if I’m in a training situation. Whatever it is I’m training, if I’m teaching you that thing, I’m going to be specific about what things are called and what they mean based on what they’re called, whether that’s Scrum or continuous delivery or C or whatever it is. There are specific meanings for the nouns that have been defined within the context of the thing that we’re learning, and we need to understand what they are, what the impact is, and how they engage with each other in the real world with teams.

We need to be pragmatic. We need to understand that people call things different things than we’re expecting. They have different knowledge and skills; they’ve come from different places where they use things in different ways, and we need to work within the bounds of what it is we’ve got. So one of those ghosts of agile past is dogma. Oh, there’s been some dogmatic things I’ve seen. The worst one was told to me by a good friend and my boss, Steven Borg, about a Scrum Master who had just been fired from their job in Washington State because they had been adamant that if the team weren’t standing up during the daily standup, then they weren’t doing Scrum, and you have to be standing up in order to do Scrum. But that team had specifically decided that they wanted to sit down because they had a disabled team member in a wheelchair, and they didn’t want to be towering over that person.

That is the right thing. That is the very definition of a Scrum team, of being respectful to each other, of openness, respect, and courage to do the things that they think are valuable. And one of those was, “Let’s all sit down so that we can be at the same level and work together.” This dogmatic Scrum Master got themselves fired for cause. I think anyone who is dogmatic— and dogmatic is where, see, dogma has this relationship to religion. It’s really about believing something in spite of the evidence to the contrary. That’s what I think about dogma, right? So that team was told that if they’re not standing up, they’re not agile, when in fact they were demonstrating agility and sitting down, and the other person was just following.

And it’s not even the letter of the law because there’s no stand-up in Scrum, right? But the letter of their understanding of the law in order to just enforce that rather than working with people within the context and learning more. And that’s where dogma differs from just being pedantic, right? Being pedantic is sometimes valuable within the context of training, but being pragmatic is the way most Scrum Masters and agile coaches should be. Don’t be dogmatic; be pragmatic and try and get rid of one of those ghosts of agile past.

If you are being haunted by this ghost of agile past, we can help you exercise it or help you find a coach, consultant, or trainer who can. Don’t let this phantom undermine the effectiveness of your value delivery, and the longer it lingers, the more it will damage your team’s progress. So email me at martink@agility.com 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.

Einer der Geister der Vergangenheit von Agile ist das Dogma. Wir alle kennen diese dogmatischen Leute, die versuchen, eine Idee zu verfolgen, ohne Rücksicht auf die Daten und die Erfahrungen der Menschen um sie herum. Wir müssen diese Leute in die Schranken weisen.

Normalerweise bin ich das falsche Wort, wenn ich mit Teams arbeite. Aber ich kann auch pedantisch sein, wenn ich mich in einer Trainingssituation befinde. Was auch immer ich ausbilde, wenn ich es Ihnen beibringe, werde ich sehr genau sein. Ob es nun Scrum oder Continuous Delivery oder C-Sharp oder was auch immer ist, es gibt spezifische Bedeutungen für die Substantive, die im Kontext der Sache, die wir lernen, definiert worden sind. Und wir müssen verstehen, was sie sind, welche Auswirkungen sie haben und wie sie miteinander zusammenhängen.

In der realen Welt mit Teams müssen wir pragmatisch sein. Wir müssen verstehen, dass die Leute Dinge anders nennen, als wir es erwarten, dass sie andere Kenntnisse und Fähigkeiten haben, dass sie von anderen Orten kommen, wo sie Dinge auf andere Weise verwenden, und dass wir innerhalb der Grenzen dessen arbeiten müssen, was wir haben. Einer dieser Geister der Vergangenheit von Agile ist das Dogma. Oh, ich habe einige dogmatische Dinge erlebt. Das Schlimmste hat mir ein guter Freund und mein Chef, Stephen Borg, über einen Scrum Master erzählt, der gerade von seinem Job im Bundesstaat Washington gefeuert wurde, weil er darauf beharrte, dass das Team kein Scrum macht, wenn es beim täglichen Stand-up nicht aufsteht, und dass man stehen muss, um Scrum zu machen, aber dieses Team hatte ausdrücklich beschlossen, sich hinzusetzen, weil es ein behindertes Teammitglied im Rollstuhl hatte und diese Person nicht überragen wollte.

Das ist das Richtige, das ist die eigentliche Definition eines Scrum-Teams, dass man respektvoll miteinander umgeht, dass man offen ist, dass man Respekt hat und den Mut, die Dinge zu tun, die man für wertvoll hält. Und dieser dogmatische Scrum Master wurde aus gutem Grund gefeuert, und ich denke, dass jeder, der dogmatisch ist, und dogmatisch ist, wo du bist, mmm, siehst du, Dogma hat diese Beziehung zur Religion. Es geht wirklich darum, etwas zu glauben, obwohl es Beweise für das Gegenteil gibt. Das ist es, was ich über Dogmen denke, richtig? Diesem Team wurde also gesagt, dass sie nicht agil sind, wenn sie nicht aufstehen, obwohl sie in Wirklichkeit Agilität bewiesen und sich hingesetzt haben und die andere Person einfach gefolgt ist. Und das ist nicht einmal der Wortlaut des Gesetzes, denn es gibt kein “Stand up and Scrum”, richtig?

Und das ist der Unterschied zwischen Dogma und Pedanterie, ich kann das Wort nicht einmal aussprechen, aber Pedanterie ist manchmal im Trainingskontext wertvoll, aber Pragmatismus ist die Art und Weise, wie die meisten Scrum Master und agilen Trainer sein sollten. Seien Sie nicht dogmatisch, seien Sie pragmatisch und versuchen Sie, einen dieser Geister der agilen Vergangenheit loszuwerden. Wenn Sie von diesem agilen Gespenst heimgesucht werden, können wir Ihnen helfen, es loszuwerden oder Ihnen bei der Suche nach einem Coach, Berater oder Trainer behilflich sein. Lassen Sie nicht zu, dass dieses Gespenst die Effektivität Ihrer Wertschöpfung beeinträchtigt. Und je länger es anhält, desto stärker wird es den Fortschritt Ihres Teams behindern.

Schicken Sie mir also eine E-Mail, martin at nkdagility.com, und wir können 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.

Uno de los fantasmas del pasado de Agile es el dogma. Todos nos hemos topado con esos dogmáticos que intentan perseguir una idea sin tener en cuenta los datos y la experiencia de la gente que les rodea. Tenemos que echar a esa gente a la calle.

Yo suelo ser pragmático, no dogmático, casi el 100% de las veces que trabajo con equipos. Pero también puedo ser pedante si estoy en una situación de formación. Sea lo que sea lo que estoy entrenando, si te estoy enseñando esa cosa, voy a ser específico sobre cómo se llaman las cosas y lo que significan en función de lo que se llaman, ya sea Scrum o Entrega Continua o C-sharp o lo que sea, hay significados específicos para los nombres que se han definido en el contexto de la cosa que estamos aprendiendo. Y tenemos que entender lo que son, cuál es el impacto, y cómo se relacionan entre sí.

En el mundo real, con los equipos, tenemos que ser pragmáticos. Tenemos que entender que la gente llama a las cosas de forma diferente a la que nosotros esperamos, que tienen conocimientos y habilidades diferentes, que vienen de lugares diferentes en los que utilizan las cosas de formas diferentes y que tenemos que trabajar dentro de los límites de lo que tenemos.

Uno de esos fantasmas del pasado de Agile es el dogma. Oh, he visto algunas cosas dogmáticas. El peor me lo contó un buen amigo y mi jefe, Stephen Borg, sobre un scrum master que acababa de ser despedido de su trabajo en el estado de Washington porque había sido inflexible en que si el equipo no estaba de pie durante el stand up diario entonces no estaban haciendo scrum y hay que estar de pie para hacer scrum, pero ese equipo había decidido específicamente que querían sentarse porque tenían un miembro del equipo discapacitado en silla de ruedas y no querían estar por encima de esa persona.

Eso es lo correcto, que es la definición misma de un equipo de scrum, de ser respetuoso con los demás, de la apertura, el respeto y el coraje para hacer las cosas que ellos piensan que son valiosas. Uno de ellos era: vamos a sentarnos todos para que podamos estar en el mismo nivel y trabajar juntos. Y este maestro de scrum dogmático se despidió por causa y creo que cualquiera que sea dogmático y dogmático es donde está. Ver dogma tiene esta relación con la religión. Se trata de creer en algo a pesar de la evidencia contraria. Eso es lo que pienso sobre el dogma, ¿verdad?

Así que ese equipo se le dijo que si no están de pie, que no son ágiles, cuando en realidad estaban demostrando agilidad al sentarse y la otra persona sólo estaba siguiendo. Y ni siquiera es la letra de la ley porque no hay stand up en scrum, ¿verdad? Pero la letra de su comprensión de la ley con el fin de simplemente hacer cumplir que en lugar de trabajar con la gente dentro del contexto y aprender más. Y ahí es donde el dogma difiere de sólo ser pedante. Derecho, pedantería, pedante, ni siquiera puedo decir esa palabra, pero ser pedante es a veces valiosa en el contexto de la formación, pero ser pragmático es la forma en que la mayoría de los maestros scrum y entrenadores ágiles deben ser. No seas dogmático, sé pragmático e intenta deshacerte de uno de esos fantasmas del pasado ágil.

Si te persigue este fantasma del pasado ágil, podemos ayudarte a ejercitarlo o ayudarte a encontrar un coach, consultor o formador que pueda hacerlo. No dejes que este fantasma socave la eficacia de tu entrega de valor. Y cuanto más tiempo persista, más perjudicará el progreso de tu equipo.

Así que envíame un correo electrónico, martin at nkdagility.com y podremos ayudarte a llegar al fondo del asunto. Si desea hablar con nosotros sobre sus necesidades o su situación particular, llámenos o visítenos en nakedagility.com. También tenemos nuestras clases públicas de inmersión y tradicionales en nuestro sitio web y nos encantaría saber de usted.

L’un des fantômes du passé de l’Agile est le dogme. Nous avons tous rencontré ces personnes dogmatiques qui tentent de poursuivre une idée sans tenir compte des données et de l’expérience des personnes qui les entourent. Nous devons mettre ces personnes au pied du mur. En général, je peux être, non pas dogmatique est le mauvais mot, presque 100 % du temps lorsque je travaille avec des équipes, je suis pragmatique. Mais je peux aussi être pédant si je suis dans une situation de formation. Quel que soit l’objet de la formation, si je vous enseigne cette chose, je vais être précis sur le nom des choses et ce qu’elles représentent.

Que ce soit Scrum ou Continuous Delivery ou C-sharp ou autre, il y a des significations spécifiques pour les noms qui ont été définis dans le contexte de la chose que nous apprenons. Nous devons comprendre ce qu’ils sont, quel est leur impact et comment ils s’articulent les uns avec les autres. Dans le monde réel des équipes, nous devons être pragmatiques. Nous devons comprendre que les gens appellent les choses différemment de ce à quoi nous nous attendons, qu’ils ont des connaissances et des compétences différentes, qu’ils viennent d’endroits différents où ils utilisent les choses de différentes manières et que nous devons travailler dans les limites de ce que nous avons. L’un des fantômes du passé de l’Agile est donc le dogme.

Oh, il y a eu des choses dogmatiques que j’ai vues. La pire m’a été racontée par un bon ami et mon patron, Stephen Borg, à propos d’un scrum master qui venait d’être licencié de son travail dans l’état de Washington parce qu’il avait été catégorique sur le fait que si l’équipe n’était pas debout pendant la réunion quotidienne, alors elle ne faisait pas de scrum et qu’il faut être debout pour faire du scrum, mais que cette équipe avait spécifiquement décidé de s’asseoir parce qu’elle avait un membre handicapé dans un fauteuil roulant et qu’elle ne voulait pas le surplomber.

C’est la bonne chose à faire, c’est la définition même d’une équipe scrum qui se respecte mutuellement, qui est ouverte, respectueuse et qui a le courage de faire les choses qu’elle pense être utiles. L’une d’entre elles était de s’asseoir pour que nous puissions être au même niveau et travailler ensemble. Et ce chef de mêlée dogmatique s’est fait virer pour un motif valable et je pense que toute personne qui est dogmatique et dogmatique c’est là où vous êtes, mmm voyez le dogme a cette relation avec la religion. Il s’agit en fait de croire quelque chose en dépit des preuves du contraire. C’est ce que je pense du dogme, n’est-ce pas ?

On a donc dit à cette équipe que si elle n’était pas debout, elle n’était pas agile, alors qu’en fait elle faisait preuve d’agilité en s’asseyant et que l’autre personne ne faisait que suivre. Et il ne s’agit même pas de la lettre de la loi, car il n’y a pas de position debout et de scrum, n’est-ce pas ? C’est là que le dogme diffère de la pédanterie, je ne peux même pas dire ce mot, mais la pédanterie est parfois utile dans le contexte de la formation, mais la pragmatique est la façon dont la plupart des maîtres de mêlée et des coachs agiles devraient être. Ne soyez pas dogmatique, soyez pragmatique et essayez de vous débarrasser d’un de ces fantômes du passé agile.

Si vous êtes hanté par ce fantôme du passé agile, nous pouvons vous aider à l’exorciser ou à trouver un coach, un consultant ou un formateur capable de le faire. Ne laissez pas ce fantôme saper l’efficacité de votre production de valeur. Et plus il perdurera, plus il nuira aux progrès de votre équipe. Envoyez-moi un courriel, martin at nkdagility.com, et nous pourrons vous aider à aller au fond des choses. Si vous souhaitez discuter de vos besoins ou de votre situation, n’hésitez pas à nous appeler ou à nous rendre visite sur nakedagility.com. Nous présentons également nos cours publics immersifs et traditionnels sur notre site web et nous serions ravis d’avoir de vos nouvelles.

Jednym z duchów przeszłości Agile jest dogmat. Wszyscy natknęliśmy się na tych dogmatycznych ludzi, którzy próbują realizować ideę bez względu na dane i doświadczenie ludzi wokół nich. Musimy wykopać tych ludzi na krawężnik. Zazwyczaj nie jestem dogmatyczny, to złe słowo, prawie w 100% przypadków, kiedy pracuję z zespołami, jestem pragmatyczny. Ale mogę też być pedantyczny, jeśli jestem w sytuacji szkoleniowej. Niezależnie od tego, co trenuję, jeśli uczę cię tej rzeczy, zamierzam być konkretny.

Niezależnie od tego, czy jest to Scrum, Continuous Delivery, C-sharp czy cokolwiek innego, istnieją konkretne znaczenia rzeczowników, które zostały zdefiniowane w kontekście rzeczy, której się uczymy. I musimy zrozumieć, czym one są, jaki jest ich wpływ i jak się ze sobą łączą. W prawdziwym świecie z zespołami musimy być pragmatyczni. Musimy zrozumieć, że ludzie nazywają rzeczy inaczej niż się spodziewamy, mają inną wiedzę i umiejętności, pochodzą z różnych miejsc, w których używają rzeczy na różne sposoby i musimy pracować w granicach tego, co mamy.

Jednym z duchów przeszłości Agile jest dogmat. Widziałem kilka dogmatycznych rzeczy. Najgorsza z nich została mi opowiedziana przez dobrego przyjaciela i mojego szefa, Stephena Borga, o scrum masterze, który właśnie został zwolniony z pracy w stanie Waszyngton, ponieważ był nieugięty, że jeśli zespół nie wstaje podczas codziennego wstawania, to nie robi scruma, a musisz stać, aby robić scrum, ale ten zespół specjalnie zdecydował, że chce usiąść, ponieważ mieli niepełnosprawnego członka zespołu na wózku inwalidzkim i nie chcieli górować nad tą osobą.

To jest właściwa rzecz, która jest samą definicją zespołu scrumowego, polegającą na wzajemnym szacunku, otwartości, szacunku i odwadze do robienia rzeczy, które uważają za wartościowe. Jednym z nich było usiądźmy wszyscy, abyśmy mogli być na tym samym poziomie i pracować razem. I ten dogmatyczny mistrz scruma został zwolniony z tego powodu i myślę, że każdy, kto jest dogmatyczny i dogmatyczny jest tam, gdzie jesteś. Mmm, zobacz, dogmat ma ten związek z religią. Tak naprawdę chodzi o wiarę w coś pomimo dowodów na coś przeciwnego. To właśnie myślę o dogmacie, prawda?

Tak więc temu zespołowi powiedziano, że jeśli nie wstają, to nie są zwinni, podczas gdy w rzeczywistości demonstrowali zwinność i siadali, a druga osoba po prostu podążała za nimi. I nie chodzi tu nawet o literę prawa, ponieważ nie ma wstawania i scruma, prawda? Ale litera ich rozumienia prawa, aby po prostu je egzekwować, zamiast pracować z ludźmi w kontekście i uczyć się więcej, i tym właśnie różni się dogmat od bycia pedantycznym, pedantycznym pedantem, nie mogę nawet wypowiedzieć tego słowa, ale bycie pedantycznym jest czasami cenne w kontekście szkolenia, ale bycie pragmatycznym jest sposobem, w jaki większość scrum masterów i zwinnych trenerów powinna być.

Nie bądź dogmatyczny, bądź pragmatyczny i spróbuj pozbyć się jednego z tych duchów zwinnej przeszłości. Jeśli prześladuje cię ten duch przeszłości Agile, możemy pomóc ci go ćwiczyć lub pomóc ci znaleźć trenera, konsultanta lub szkoleniowca, który to potrafi. Nie pozwól, aby to widmo podkopało skuteczność dostarczania wartości. Im dłużej to trwa, tym bardziej szkodzi postępom zespołu. Napisz do mnie, martin at nkdagility.com, a pomożemy Ci dotrzeć do sedna sprawy. Jeśli chcesz porozmawiać o swoich unikalnych potrzebach lub sytuacji, zadzwoń lub odwiedź nas na nakedagility.com. Na naszej stronie internetowej znajdują się również nasze wciągające i tradycyjne zajęcia publiczne.

Um dos fantasmas do passado do Agile é o dogma. Todos nós já nos deparamos com pessoas dogmáticas que tentam seguir uma ideia sem levar em conta os dados e a experiência das pessoas ao seu redor. Precisamos chutar essas pessoas para o meio-fio. Normalmente, eu posso ser pragmático, não dogmático é a palavra errada, quase 100% do tempo quando estou trabalhando com equipes. Mas também posso ser pedante se estiver em uma situação de treinamento. Seja lá o que for que eu esteja treinando, se eu estiver ensinando aquilo, serei específico sobre como as coisas são chamadas e o que significam com base no que são chamadas, seja Scrum ou Entrega Contínua ou C-sharp ou o que quer que seja, há significados específicos para os substantivos que foram definidos no contexto do que estamos aprendendo. E precisamos entender quais são eles, qual é o impacto e como eles se relacionam entre si. No mundo real, com as equipes, precisamos ser pragmáticos. Precisamos entender que as pessoas chamam as coisas de forma diferente do que esperamos, têm conhecimentos e habilidades diferentes, vêm de lugares diferentes onde usam as coisas de formas diferentes e precisamos trabalhar dentro dos limites do que temos. Portanto, um dos fantasmas do passado do Agile é o dogma. Já vi algumas coisas dogmáticas. A pior delas me foi contada por um bom amigo e meu chefe, Stephen Borg, sobre um scrum master que tinha acabado de ser demitido de seu emprego no estado de Washington porque ele tinha sido inflexível ao dizer que se a equipe não estivesse de pé durante a reunião diária, então eles não estavam fazendo scrum e você tem que estar de pé para fazer scrum, mas essa equipe tinha especificamente decidido que queria se sentar porque eles tinham um membro da equipe com deficiência em uma cadeira de rodas e eles não queriam estar acima dessa pessoa. Essa é a coisa certa, é a própria definição de uma equipe de scrum, que respeita uns aos outros, é aberta, respeitosa e corajosa para fazer as coisas que considera valiosas. Uma delas era: vamos todos nos sentar para que possamos estar no mesmo nível e trabalhar juntos. E esse scrum master dogmático foi demitido por justa causa, e acho que qualquer pessoa que seja dogmática, e dogmática é aquela em que você vê que o dogma tem essa relação com a religião. Trata-se realmente de acreditar em algo apesar das evidências em contrário. É isso que eu penso sobre dogma, certo? Então, essa equipe foi informada de que, se não estiver em pé, não é ágil, quando na verdade estava demonstrando agilidade e se sentando, e a outra pessoa estava apenas seguindo. E não é nem mesmo a letra da lei, porque não existe stand up e scrum, certo? Mas a letra do seu entendimento da lei, a fim de apenas impor isso, em vez de trabalhar com as pessoas dentro do contexto e aprender mais, e é aí que o dogma difere de apenas ser pedante, pedantismo, pedante, não posso nem dizer essa palavra, mas ser pedante às vezes é valioso dentro do contexto do treinamento, mas ser pragmático é a maneira como a maioria dos scrum masters e agile coaches deve ser. Não seja dogmático, seja pragmático, seja pragmático. Não seja dogmático, seja pragmático e tente se livrar de um desses fantasmas do passado ágil. Se você estiver sendo assombrado por esse fantasma do passado ágil, podemos ajudá-lo a exercitá-lo ou a encontrar um coach, consultor ou instrutor que possa fazê-lo. Não deixe que esse fantasma prejudique a eficácia de sua entrega de valor. E quanto mais ele persistir, mais prejudicará o progresso da sua equipe. Portanto, envie um e-mail para mim, martin at nkdagility.com, para que possamos ajudá-lo a chegar ao fundo da questão. Se quiser conversar sobre suas necessidades ou 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 receber seu contato.

Один из призраков прошлого Agile. Мы все сталкивались с догматиками, которые пытаются преследовать идею, не считаясь с данными и опытом окружающих их людей. Нам нужно выгнать таких людей на обучение. Обычно я могу быть не догматиком почти в 100 % случаях, когда я работаю с командами, я прагматик. Но я также могу быть педантичным, если нахожусь в ситуации обучения. Чем бы я ни обучался, если я учу вас чему-то, я буду точно знать, как называются вещи и что они означают, исходя из того, как они называются, будь то Scrum, Continuous Delivery или C-sharp, или что бы это ни было, есть конкретные значения сущностных, которые были определены в контексте того, что мы изучаем. И нам нужно понять, что это такое, каково их влияние и как они взаимодействуют друг с другом.

В реальном мире с командами нам нужно быть прагматичными. Мы должны понимать, что люди называют вещи иначе, чем мы ожидаем, у них разные знания и навыки, они приехали из разных мест, где используют вещи по-разному, и нам нужно работать в рамках того, что у нас есть. Так что один из призраков прошлого Agile. Я видел несколько догматических вещей. Худшую из них мне рассказал мой хороший друг и босс Стивен Борг о скрам-мастере, которого только что уволили с работы в штате Вашингтон, потому что он был непредклонен: если команда не встает во время ежедневного вставания, значит, она не занимается скрамом, а для того, чтобы заниматься скрамом, нужно стоять, но эта команда специально решила сесть, потому что у них есть член команды-инвалид в инвалидном кресле, и они не хотят возвышаться над этим человеком.

Это правильно, это самое определение скрам-команды — открытость, уважение и смелость делать вещи, которые они считают ценными. Одна из них — давайте все сядем, чтобы мы могли быть на одном уровне и работать вместе. И этот догматичный scrum-мастер уволил себя за причину, и я думаю, что любой, кто догматичен, а догматичность что догма имеет отношение к религии. Это действительно вера во что-то, несмотря на доказательства обратного. Вот что я думаю о догме, верно? Так вот, этой команде сказали, что если они не стоят, то они не ловкие, хотя на самом деле они демонстрировали ловкость и приседали, а другой человек просто следовал за ними.

И дело даже не в букве закона, потому что нет никаких stand up и scrum, верно? Но это буква их понимания закона для того, чтобы просто обеспечить его соблюдение, вместо того чтобы работать с людьми в контексте и узнавать больше, и в этом догме отличается от просто педантичности, педантичности педанта, я даже не могу произнести это слово, но педантичность иногда ценна в контексте обучения, но быть прагматиком — это то, каким должно быть большинство скрам-мастеров и agile-тренеров. Не будьте догматиками, будьте прагматиками и постарайтесь избавиться от одного из этих призраков agile-прошлого.

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

È¿‡åŽ»æ•æ·çš„幽灵之一就是教条。
我们都遇到过那些教条主义者,他们试图追求
一种与数据和周围人的经验无关的想法。
我们需要把这些人一脚踢弍。
æ‘通常不是教条主义者,在与团队合作时,我凑乎一零零
%都是务实的。
但如果是在培训场合,我也会很迂腐。
不管我在培训什么,如果我在教你那个东西,我就会很具体地
不管是Scrum还是Continuous Delivery或者C。
æ‘们需要了解它们是什么,有什
么影响,以及它们是如何相互影响的。
在现实世界的团队中,我们需要务实。
我们需要明白,人们对事物的称呼与我们的预
期不同,他们拥有不同的知识和技能,他们来自不同的地方
,他们使用事物的方式也不同,我们需要在我们所掌握的
范围内开展工作。
因此,过去敏捷的幽灵之一就是教条。
æ‘见过一些教条主义的东西。
最糟糕的一次是我的一个好朋友兼老板斯蒊芬的站立过程中没
有站起来,那么他们就没有在做scrum,你必须站起
暗能做scrum,但那个团队特别决定他们要坐下,因为他们有一
个坐轮椅皚疾团队战员,他们不想高高在上。
这才是正确的,这才是Scrum团队的定义,即相互尊重,
开放,
尊重并勇于做他们认为有价值的事情。
æ‘认为任何一个教条主义的人都会被炒鱿鱼,教条主义
是指教条与宗教的关系。
它是指不顾相反的证据而相信某事这就是我对教
条的看法,对吗?所以那支队伍被告知,如果他们不站起来,
他们就不敏捷,而事实上他们是在展示敏捷和坐下来,而另一
个人只是跟在后面。
这甚至不是法律条文的规定,因为没有站立和Scrum,
对吗?这就是教条与迂腐的区别所在,迂腐,我
甚至说
不出这个词,但迂腐有时在培训中很有价值,但务实才是
大多数Scrum大师和敏捷教
练应该采取皚方式。
不要教条,要务实,试着摆脱敏捷过去的幽灵。
如果你袝敏捷过去的幽灵纠缠,我们可以帮你摆
脱它,斖者帮你找到能够摆脱它的教练,
顾问或培训师。
不要让这个幽灵破坏你价值交付的有效性。
它存在的时间越长,对团队进步的损害就越大。
请给我发电子邮件,mart inatnk dagility.
com,我们可以帮你找出问题的根源。
如果您想就自己的独特需求或情况进行讨论,请拨打电话
斖访问我们的网站nake dagility.
com。
æ‘们的网站上还有我们的沉浸式和传统公开课,我们很乐意
存到您的意见。

Scrum Master People and Process Agile Frameworks Agile Project Management Agile Philosophy Pragmatic Thinking Software Development Personal Agile Values and Principles Scrum Values

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

MacDonald Humfrey (Automation) Ltd. Logo
Higher Education Statistics Agency Logo

NIT A/S

Genus Breeding Ltd Logo
SuperControl Logo
Hubtel Ghana Logo
Slaughter and May Logo
Lean SA Logo
Freadom Logo
Trayport Logo
Epic Games Logo
Graham & Brown Logo
Schlumberger Logo
ProgramUtvikling Logo
Capita Secure Information Solutions Ltd Logo
Flowmaster (a Mentor Graphics Company) Logo
Bistech Logo
Milliman Logo
Washington Department of Transport Logo
Nottingham County Council Logo
Ghana Police Service Logo
Washington Department of Enterprise Services Logo
Royal Air Force Logo
Department of Work and Pensions (UK) Logo
Teleplan Logo
Philips Logo
Lockheed Martin Logo
DFDS Logo
Jack Links Logo
Xceptor - Process and Data Automation Logo